集群
何为集群？百度上面的解释就已经够了：集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。
集群的作用：1.提高性能 2.降低成本 3.提高可扩展性 4.增强可靠性
这4点很好理解，所以从这4点作用来看我们可以把集群分为三类：1.超级计算集群 2.负载均衡集群 3.高可用集群，这三类不论在功能上及性能上都并非独立存在，在实际应用中都是互相穿插，相互之间都会担任其他两类的角色，那么为什么会被分出三类呢，主要是因为软件的功能来分的。列举几个常用的，hadoop，haproxy，keepalived都是集群软件，只是只要负责的方面不同。
白话文解说下各自的功能，超级计算集群就是有一个大数学题要去很麻烦的算，最后汇总成最终的答案返回，一个服务器的cpu是有上限的，so他的计算能力也是有上限的，有人说那我可以慢慢算，一个个来，没错，可以的，但是不是慢么，100道加减法数学题你一个人去算跟10个人各算10个那个快，都懂得，这是一个注重效率的时代，所以大数据现在才这么火，企业们纷纷上自己的hadoop平台，服务器少的算少量数据，服务器多的数据多输入点，当然了，数据量越多，得出的运算结果越符合常理，大数据技术细节不做讨论，本人也不是搞大数据的，就不在此班门弄斧了；负载均衡集群主要应用于并发较大的环境中，其实跟超级计算集群很像，这次是我单台连接并发数到达上限把持不住了，so，多叫几个兄弟一个来处理；高可用集群多用于负载均衡集群之前，也就是我们常说的负载均衡调度器们所组成的一个集群，它的作用是为了确保对后端调度的可用性，就是一个跪了另外一个上去，这个集群极为重要，若这里配置有错误或者存在问题，后端你设计的再好也没用！
从它们的功能上我们已经完全可以看出它们之间的功能并非独立，负载均衡集群本身就已经体现出了高可用性，不同之处就是他没死我也还是在干活，so，我们就写这个负载均衡集群吧。
说到负载均衡集群，第一反应就是lvs，nginx，haproxy。好的，这波你很强，看来你知道最火最流行的这三个，but，为什么要实现负载均衡集群就一定要用这些专门的负载均衡软件呢，so，北不会从这三个开始写......因为北的目标是架构师
1.链路负载均衡
南方电信，北方网通，如果你有两个服务器托管在南北两个机房，那么南方用户访问你南方服务器自然更快，反之亦然，当南方服务器出问题是，南方的用户也会转访问北方服务器，只是速度会下降，在这个过程中，经历了智能dns解析，智能dns解析有两种方式，一种是无脑记录dns来确定来源ip是哪里的然后去解析到对应线路的目标ip，另一种是对两条线路各发一个探测包来检测时间确定那个离得近，其实解析到不同服务器上时就已经达到了负载均衡的目的，南北服务器共同工作承担着南北用户的请求。但是很多人会问，你这么弄我还得两个机房啊，而且机房里不能就仅仅是两个web服务器，后端还得有，so，cdn应运而生，只能dns仅是cdn其中一项功能，cdn的出现绝对是中小型企业一个6666666的感受，cdn不在多做介绍了，了解他能为我们带来的功能就好，不用了解他是如何做到的，当然了，当你的企业有了一定规模时你就需要使用自己的cdn了，不过那时你一定也有了一个完善的技术团队。
dns负载均衡也是最简单方便的负载均衡，现在主要用于负载负载调度器之前了，通过A与CNAME的转换即可将一个域名对应多个ip多网站都在使用这种方法，但是这种方法太简单了也就没有什么可以去自行调配的选项了
2.操作系统层面负载均衡
wtf，操作系统怎么负载均衡？简明来说就是网卡，7系统前bond，7系统后team。team简单说就是bond的升级版本，可支持8块网卡同时进行绑定，模式很多大家自己去查，做bond或team都很简单，百度下都有。从网卡层面分流请求以达到接受更多请求，但是还是无法突破系统本身的限制，so，相比于负载更偏向于高可用，为了保持网卡的可用性从而保证了该服务器的可用性，但是确实可以实现一些分流的效果，比如遭受大流量攻击时。
3.集群负载均衡
这里面又分为两种，硬件与软件，硬件常用的有F5，名声很大，但是也很贵，相比之下性价比更高的有Array，北方并没有钱，而且设备贵，当时也没让我碰，wtf...
nginx，原本一个单纯善良的web服务器被玩坏了成现在的样子，名气越大，北酱反而越觉得别扭，请问你会用nginx作为web服务器使用过么？好吧，就事论事吧
haproxy，专门的负载均衡软件，北酱最爱的web负载
lvs，集成到了内核当中，章文嵩博士研发，6到飞起，给国人长脸
最重要的区别，什么安装配置比较简单这特么也算优点，真是醉了，这三个哪个安装配置不简单？
nginx，工作在7层，对网络依赖性较弱，附带还可以缓存一波，正则比haproxy好
haproxy，4/7层皆可负载，并发数及效率比nginx强
lvs，工作在4层，无流量产生，无流量产生，无流量产生，比上面两个能扛，资源占用率低，模式多调度算法多
so，再次从他们的特点来分析他们的优缺点吧
nginx(Tengine不讨论)单纯工作于7层，配置的时候要加端口号哦，它这里可以对端口进行检测来确认后端服务器是否可用，并且在出现问题时会自行切换处理，生产环境并发量大概是3W(官方说是10W，嘛，都懂得，不吹牛逼点没人用啊，哈哈哈哈，梗~)，正则支持较好，其实很多人正则用的并不好，也就是只能简单匹配下页面url(比如北酱......)，但是这样是可以确实做到动静分离了，我萌都知道大型架构服务服务器跟文件文件服务器肯定是分开的，最重要的就是缓存一波这个波了~haproxy跟lvs都没有这个功能，别小看这小小的缓存，它可以为你的架构带来极大的性能提升，用nginx做反向代理不开缓存功能就是在卖萌，but，在生产环境中还真有不少人不开这层缓存，有日志好查错出事了可以拯救世界，还有nginx平滑重启让人很舒服；nginx的缺点也很明显，他仅支持http，https跟邮件协议，but，在日常使用中这就已经完全够用了，刚才说了它是对端口进行检查，无法直接针对url(Tengine可以)，缓存了不该缓存的会让感觉到bi了poi
haproxy，他的工作位于4/7层就已经够亮了，拥有8种算法也比较完全，支持根据url健康检查，该有的都有啦，需要注意的一点就是static-rr才是简单的轮询，而roundrobin可以在运行时更改后端权重并生效；缺点就是不如nginx的一些地方，比较明显的就是不带缓存，平滑重启时还是会重启进程
lvs，负载能力最强，稳定性最高，4种模式支持各类场景，10种调度算法总有你喜欢的，对资源占用率小，几乎可以做任何负载均衡。缺点也很明显，无正则无法动静分离，对网络依赖强，需要机器较多，dr模式配置vip繁琐，nat模式调度器瓶颈，tun模式成本高，full-nat模式难度较大，单独安装不带后端健康检查功能，后端要是还有windows维护起来简直感觉bi了poi，出了错误不好排查。
10种算法
轮叫调度（Round Robin）(简称rr)
调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2.加权轮叫（Weighted Round Robin）（简称wrr)
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3.最少链接（Least Connections）(LC)
调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。
4.加权最少链接（Weighted Least Connections）(WLC)
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5.基于局部性的最少链接（Locality-Based Least Connections）(LBLC)
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近 使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接” 的原则选出一个可用的服务器，将请求发送到该服务器。
6.带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）(LBLCR)
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器 组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台 服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程 度。
7.目标地址散列（Destination Hashing）(DH)
“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
8.源地址散列（Source Hashing）(SH)
“源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
9.最短的期望的延迟（Shortest Expected Delay Scheduling SED）(SED)
基于wlc算法。这个必须举例来说了
ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算
A(1+1)/1
B(1+2)/2
C(1+3)/3
根据运算结果，把连接交给C
10.最少队列调度（Never Queue Scheduling NQ）(NQ)
无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要在进行sed运算
4种模式，nat，dr，tun的资料太多了，大家也应该都很会了，so，来写full-nat吧~看这个名字就知道跟nat有着不可描述的关系
我们列举下nat模式下所需要做的操作以及访问流程和瓶颈吧
Director需要双网卡，一个对外，一个对内
Realserver的网关都得指向Director的内网ip
Director跟Realserver肯定连在一个交换机上喽，不然网关指过来就没什么卵用了
客户A访问Director的外网ip(客户不知道Realserver，只认域名，域名解析后只能是你Director的外网ip)，此时包内容为A请求Director
Director发现我是目标地址，会将此请求通过dnat将访问的目标变成后端的某台Realserver的内网ip，此时包内容为A请求Realserver
Realserver收包后发现目标地址也确实是自己，那么处理此请求返回给客户，此时包内容为Realserver返回A
but,此时就出现了一个问题，一开始的包是A请求Director，现在变成了Realserver返回A，A肯定不会接受这个包，so，Realserver指向网关就变得有意义了，Realserver回包必须又经过Director
Director收到这个包后又会做一次snat将这个包的发送者变成自己，此时包内容为Director返回A，怎么辨认包？有个session表
A发现这个包就是跟我刚才发的包对应的，接受。ok，完事，完美，一切都显的那么的高大上，无懈可击
这里面的核心明显是Realserver的网关都指回Director的内网ip，否则包回不来无法snat，那么我萌交换机连交换机多弄些机器，所有机器都指向Director不就完事了么，no，就算你加交换机服务器那么这个集群最多可以容纳多少机器，还不依然是一个网段，那么我再来一个同样的集群，我靠，机智如你啊，but，核心的问题并不在此，而在于无论进出都必须经过Director，一般情况下Director在Realserver有22台左右时就会Boom Shakalaka！
full-nat的出现自然是要解决nat的问题喽，但是，北方一直无法理解的是full-nat是否解决了单台Director瓶颈问题......也请大神指导下，北酱觉得木有
Director需要双网卡，一个对外，一个对内
Realserver网关随意，只要能跟Director内网通讯即可，过了多少个路由器无所谓
即full-nat内部就是你内部网络架构本身，不需要去做别的什么
客户A访问Director的外网ip，此时包内容为A请求Director
Director发现我是目标地址，会将此请求通过dnat将访问的目标变成后端的某台Realserver的内网ip，并且做snat将请求者变为自己内网ip，此时包内容为Director请求Realserver
Director与Realserver之间本身就是你内部网络可通讯，包可以传递
Realserver收包后发现目标地址也确实是自己，那么处理此请求返回给Director，此时包内容为Realserver返回Director
Director收到这个包后会做一次snat将这个包的发送者变成自己，并做一次dnat将目标地址变回A，此时包内容为Director返回A
不用在同一网断里，服务器之间只要互通即可，前端的Director再做ospf，Realserver还是那些，只需要部署好Director即可，其中还增加了安全层面的东西。but，不是那么简单的，full-nat还木有编译到内核当中，需要自己去编译，so，线上环境整改需谨慎，很可能gg思密达，还有full-nat是4种模式中性能最差的，dr是最好的，而且对于大部分企业来看，dr是一个正确的选择。
通过消息队列来达到负载均衡的效果
不是只有web相关的负载均衡才是负载均衡，web也是只是提供的服务之一，再去看看集群的定义跟作用吧，不要被困在一个圆圈中
生产者将消息投放到队列当中，消费者去获取此消息执行完成，返回(课定义是否返回，当然持续化什么也都可以定义)，多个消费者去取同一队列中的任务，效率自然高了(当然怎么个取法也是可以定义的)，这样就可以做到最少连接的意思，简单的任务快速处理后再次来取，复杂的任务就去处理完后再继续这期间其他服务器也还是在消费队列，通过共享队列这种方式来分散了任务，这也达到了负载均衡
