听完陈硕的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。
结论：具体看业务，选择。 （多线程 简单会更好维护）