微信图片_20190228170131.png

研究了负载均衡 终于实现了 在本地创建3个虚拟机 其中一个作为负载均衡 两个作为web端.
加上之前的mysql独写分离, 负载均衡。 接下来研究下容灾备份,消息队列等等 相信可以越来越接近架构

负载均衡的几种常用方式

1、轮询(默认)

每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

upstream backserver {
    server 192.168.0.14;
    server 192.168.0.15;
}

2、weight

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的
情况。

upstream backserver {
    server 192.168.0.14 weight=3;
    server 192.168.0.15 weight=7;
}

权重越高,在被访问的概率越大,如上例,分别是30%,70%。

3、ip_hash

上述方式存在一个问题就是说,在负载均衡系统中,假如用户在某台服务器上登录了,那么该用户第二次请求的时候,因为我们是负载均衡系统,每次请求都会重新定位到服务器集群中的某一个,那么已经登录某一个服务器的用户再重新定位到另一个服务器,其登录信息将会丢失,这样显然是不妥的。
我们可以采用ip_hash指令解决这个问题,如果客户已经访问了某个服务器,当用户再次访问时,会将该请求通过哈希算法,自动定位到该服务器。
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

upstream backserver {
    ip_hash;
    server 192.168.0.14:88;
    server 192.168.0.15:80;
}

4、fair(第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配。

upstream backserver {
    server server1;
    server server2;
    fair;
}

5、url_hash(第三方)

按访问url的hash结果来分配请求,使每个url定向到同一个(对应的)后端服务器,后端服务器为缓存时比较有效。

upstream backserver {
    server squid1:3128;
    server squid2:3128;
    hash $request_uri;
    hash_method crc32;
}

学了一段时间爬虫之后才知道 所见即所得的道理。
关于爬行过程中所需要的IP池搭建大致想法

1 找几个大型的免费代理网站
2 爬下IP,并存入redis。 给每个IP一个权重 权重越高越有用。
3 一个爬取IP存入redis, 一个随机返回ip 一个检查IP是否可用 主要这三大接口。

若是嫌得麻烦可以直接买

个人比较熟悉github来管理代码
看项目整体规模大小来确定项目分支
一般来说 git 分支分为:
master - hotfix - develop - feature - release

master (生产环境)

hotfix (热更新环境, 也可做为预发布环境进行测试 一般正对master进行更新)

develop (开发环境)

hotfix 与 master 代码并行。 develop中代码更新至 hotfix-> 交付给测试。

feature 是为了某个自己的功能而拉取的分支

release 为了即将上线前,允许改变的东西 更新到hotfix 。

回滚

$ git reset --hard HEAD^ 回退到上个版本
$ git reset --hard HEAD~3 回退到前3次提交之前,以此类推,回退到n次提交之前
$ git reset --hard commit_id 退到/进到 指定commit的sha码

git push origin HEAD --force 强制推送

最近在做微信授权登陆中
1366 Incorrect string value: 'xF0x9Fx98x84xF0x9F...' for column 'nickname' at row 1
提示报错

我遇到的原因是 微信用户名含有 表情符号 而表情符号 4字节 而utf8编码是 3字节 多了一个字节无法存储,所以报错。
解决办法是
1 采用 utf8mb4 编码 即可
我采用php 链接数据库时设置的编码就是utf8mb4 数据库字段表也是 utf8mb4

假设场景:
在双11当天00:00 1000个用户同时打开了淘宝首页。 假设淘宝网页中 首页的请求是 10个。
全部人打开的网页 到 加载完毕的 时间为 1秒。

那么 在这1s内的

TPS为 1000个

QPS为 10*1000个

并发量为 1000个

响应时间为 1秒 (响应时间是指系统对请求作出响应的时间 一般指平均时间)

吞吐量为 1100010 (1s1000并发10请求)

其中 TPS为一次事务的完整发生过程

QPS为 每秒的响应请求数 单服务器最大吞吐能力。

吞吐量 是指系统在单位时间内处理请求的数量

一个系统吞吐量的要素

一个系统中的 单个 请求(reqeust) 对系统的资源暂用量越小, 系统的吞吐量就越高。反之越低。

目前对其他的 IO, CPU运行这些其实个人还是懵懂的

至于一些外部接口(像腾讯登陆之类的 暂时还不需要考虑到那种程度吧)