消息队列与异步架构

一、集群的概念

集群的分布式系统的一个子集，它是提供同样功能的一组服务器形成的一个子系统，提供相同功能的，或者相同角色的一组服务器构建的集群。例如一组应用服务器构建了一个负载均衡集群。一组nosql数据库构建了一个nosql集群。

二、余数哈希

对服务器的个数取摩儿，得到的余数就是服务器的编号。

三、一致性哈希

先构建一个一致性哈希环，它是从0开始到2的32次方减1，也就是4字节的正整数儿的大小范围。也就是HashCode的大小范围。然后每个服务器的节点是一个字符串儿(服务器标识IP或唯一名称)，用它来取哈希值。这个取得的哈希值直接放到这个环上。当我们要查找一个key的时候，例如北京这个字符串儿要落到那个服务器上面去，这个key也是有一个哈希值的，把这个哈希值也放到这个环上来。然后沿着哈希环顺时针的查找，离它最近的服务器。那这个服务器就是它要访问的服务器，这个就是一致性哈希算法儿的描述。

这样就可以解决加了服务器之后，使用余数哈希99%找不到value的问题，使用了一致性哈希算法儿后也就1%的数据找不到。



上面这个图说明了这个算法对新增服务器后的影响。集群越大，这种影响也就会越小。



上图的这个算法儿还是有问题的，我们把服务器节点的哈希值放到这个环上。而哈希值是个随机数，随机数可以放在node1的位置也可能放到node2的位置。上图中的node0和node1很有可能就挨在一起了，这样也就导致了node0所存储的哈希值只占环山一小片儿。很可能连1%都不到，原本是线性伸缩，想要增强存储能力，分摊其它服务器的压力，想加一台机器降低负载，但加了后，node1和node3的负载仍然很高，这样达不到我们的目的。



解决这个问题的思路是我们要使用虚拟节点。



我们在计算了服务器node0的哈希值之后，不是直接将这个哈希值直接放到环上，而是把这个node0变成一组虚拟节点。比如说变成了150个或者200个虚拟节点。常规是200个，也就是把node0.0-node0.1...这种形式的哈希值放上到环儿上。

依据上面的三个node服务器也就会600个虚拟节点均匀的分布在服务器上。最后key进来找的时候，它找到node0的虚拟节点或者是node1的虚拟节点的概率是差不多的。这样的算法儿也就导致了新增服务器节点后，所有服务器的负载都差不多了，也就达到了分摊负载的目的。



四、负载均衡

1.DNS负载均衡

 像淘宝百度这种大型网站，他们都是使用了二级负载均衡。比如我们ping百度得到的是负载均衡服务器的IP地址，并不是应用服务器的IP。



2.反向代理负载均衡

实践中，这种架构适用于小型的网站，大一点儿的公司是不会使用的。通常的应用服务器的集群通常是几十台这样的规模的时候，再多的话，反向代理服务器本身就是瓶颈了。它在这里转发的是七层的http协议，http其实是比较重的网络协议，通信过程是先从客户端收集到request全部，然后再像它的后端发起http通信请求，得到全部响应后再向客户端response。

所以，当用户的请求比较多的时候，反向代理服务器本身就会成为瓶颈。

3.网络层(IP)负载均衡

在这里负载均衡服务器分发的数据包是tcp的数据包儿，所以这个数据包儿就比较小了。所以就不会对负载均衡服务器构成比较大的性能压力。

通信过程是，上图源地址请求是 10.1 目的地址是80.10，这个是记录在tcp的通信包儿里的。这个包到负载均衡服务器的时候，它会去检查这个通信包里的IP包，看目标地址，它看到的目标地址当然是自己了，然后它会选一个应用服务器，把ip包里面的目标地址直接修改成应用服务器的IP地址，源地址修改成自己的IP地址，再然后就可以直接把这个tcp包直接丢出去，好处是不需要完整的拿到http包儿的，它是拿到了一个tcp包儿之后直接修改了源地址和目的地址之后直接丢给应用服务器。



缺点: 用户的请求响应都要通过负载均衡服务器，请求的包小，响应一般比较大，它的出口带宽会成为瓶颈。比如千兆网卡，发1M的图片，一秒中可以发125张图片。

4.数据链路层(OSI第二层)负载均衡



负载均衡服务器不再修改源IP和目的IP，它修改的是网卡的mac地址， 应用服务器的IP和负载均衡服务器的IP是一样的，他们共享一个虚拟IP地址，请求发出去之后所有的应用服务器都会收到数据包，但是应用服务器收到数据包儿之后会检查Mac地址是不是自己的，是自己的就处理，不是自己的就丢弃。

应用服务器处理完了之后，因为源IP和目的IP都没有变tcp的链路还是通的，所以回复就直接回复给请求用户了。

这种负载均衡也被称为负载均衡的三角模式。