负载均衡，过载保护 简介
听完陈硕的Load Blance 负载均衡课程
恍然大悟，
负载均衡 类型一般分为2种：
1.基于 connect （简单点）
对于每个connect 进行负载
2.基于 request （复杂点，可以对不同的任务进行区分。 比如报警，关机，损坏 等重要信息）
对于request 每个请求 进行负载
第一种有一些弊端， 比如connect 可能会遭遇DDOS攻击， 导致平均连接数都非常高，但是没有计算任务。 或者 内存，CPU，IO 某个任务超时，会出现长时间 等待。
第二种可以处理优先级， 会好一点。
---------------------------------------------------
client
proxy server A，B，C，D, E (ABC过载保护）
business server 1~100 （40~70 过载保护）
Tips: 实际上还可能是分布式的，需要根据延迟，地区选择proxy server => business server ,
(若本地出现问题，或者高负载，则选择邻近proxy server =》 business server ) 直接选择 最低延迟的也行。
client 优先选择本地proxy server ，
proxy server 优先选择本地 business server
----------------------------------------
关于负载均衡方式：
1. client 直接 连接多个business server 0~10 ，
- 得到所有的business server CPU状态 ，IO（网络IO状态，硬盘IO状态），内存状态。
- 选取 (最近, 延迟最低) 资源最空闲的server 进行业务
2. client proxy
- client 连接 proxy server A,B，C 得到某个，或者所有 business server 状态
- clinet 从proxy server 得到某个最优值后，连接 business server 5
3. 混合模式
- client 通过随机数，选择proxy server D （若该proxy 不在线，或出现问题，则继续随机 选择）
注意：一般随机数的获取是通过时间 取模，同一个时间的client 随机数都是一样的，所以随机要自己实现下，把MAC地址，PID进程ID ，等信息加上去。
比如AA:BB:CC:DD:EE:FF 通过时间取模得到 4，就是DD， DD 的值 模 proxy server 的数量（221 mod 5 = 1 ， 那就选第二台proxy server），
- proxy server D， 得到的 business server 71（延迟最低， 负载中等。 最优先是地区和延迟，）。
关于proxy server 和 business server 返回的状态信息，
--------------------
过载，或掉线异常
- client 连接proxy server 中， 未返回
- proxy server 连接business server 中， 未返回
- client 连接business server 中， 未返回
- client 已经发送 业务到 business server，但是未回应，是否发送成功（断线）
- client 已经发送 业务到 business server，且已回应，发送成功。 但是 business server 没有返回业务数据。（SQL 查询较忙，或者SQL 挂了）
---------------------
监控server 和 日志server (DB)
需要设计的更加严谨，任意机器掉线都不影响业务。
发过来信息，记录日志DB， server 返回信息，记录DB。
需要有个内存server 来保留日志ID，方便查询日志DB，
client 也是有DB，
- 还未发送放到table A
- 发送成功 放到table B ,
- 发送失败放到table C,
中间的负载均衡，可以部署 2级。
-------------------------------
1.代理要验证client 合法性，合法则更新Business Server到client， 所以BS 肯定是合法的， BSIP 不必泄露可随便更新。 （可以代理数据， 也可以通过代理告诉client Business Server 地址）
2.有些是协议前4bytes 是包长度
3. 提供lib +header给客户，客户不需要写 连接（重连，断线）的业务代码，只需要调用就行。 （不需要给IP ，协议， 也不需要更新， 可以自动更新）
涉及NAT
4.TCP 半关闭 状态，CLOSE_WAIT, 是调用SHUT_DOWN(), 说明不发送，但是可以还可以接收网络上的(剩余)数据， 完整关闭需要close()
5. server 何时关闭Connect()，这个不是GC 垃圾回收的问题， 是所有服务 都会面对的问题， 客户何时离开？ 一般用超时 踢掉。
6.TCP可靠性？ 网络层（路由，交换机）接收到数据，但是 业务层不一定， 所以 数据包要做校验。
7.为什么用GO,现在OS 启动进程几百，几千个，一个进程也只可以启动几百线程， 而go rountine 可以启动几万，几十万个。
8. 多线程 和 EVENT 用哪个？ 简单的话，用多线程。 EVENT 的话，复杂度会增加太多。
所以能用多线程解决 就用多线程。
EVENT如果会用 就用EVENT。
结论：具体看业务，选择。 （多线程 简单会更好维护）
