分布式和集群

Posted 2020-11-04 jokermo

版权声明：本文为博主原创文章，未经博主允许不得转载。http://www.cnblogs.com/joker/

1.分布式

某公司有三个不同的系统，分别运行在三个不同的独立的服务器上，处理不同的业务。但是互相协调共同完成公司业务。将不同的业务分布到不同的地方，这就构成了分布式系统。

用户对系统A的访问量过大时，会导致系统A运行缓慢，甚至挂掉。由于系统A只有一份，所以会引起单点失败。

2.集群

现在公司购买了几台服务器，将系统A一下子部署到三台服务器上，每一份都是系统A的一个实例，对外提供同样的服务。这样就不怕一个忽然挂掉了。这就是系统A 的集群。

可是对用户来说，一下子出现这么系统A ，每个系统的IP地址都不一样，  到底访问哪一个？ 

如果所有人都访问服务器1.1 ，那服务器1.1 会被累死， 剩下的两个闲死，成了浪费钱的摆设。

 3.复杂均衡

尽可能让三个机器上的处理均衡，比如有3万个对系统A的请求，每个各处理1万个，这就是负载均衡。

将负载均衡设计成一个集群

1.  这个新的集群中虽然有两个机器，但我们可以用某种办法，让这个集群对外只提供一个IP地址， 也就是说用户看到的好像只有一个机器。

2. 同一时刻，我们只让一个负载均衡的机器工作， 另外一个原地待命。 如果工作的那个挂掉了，待命的那个就顶上去。

4.弹性

因为不同时间访问量不同，比如双十一的访问量是平时的10倍。不可能为此另外购买服务器，因为平时用不到太浪费。所以可以在云端创建删除虚拟的服务器。

5.失效转移

上面的系统看起来很美好，但是做了一个不切实际的假设： 所有的服务都是无状态的。 换句话说，假设用户的两次请求直接是没有关联的。

但是现实是，大部分服务都是有状态的， 例如购物车。

用户问系统，在服务器1.1上创建了一个购物车，并向其中加入了几个商品， 然后 服务器1.1 挂掉了， 用户的后续访问就找不到服务器1.1了，这时候就要做失效转移，让另外几个服务器去接管、去处理用户的请求。

可是问题来了，在服务器1.2，1.3上有用户的购物车吗？  如果没有， 用户就会抱怨，我刚创建的购物车哪里去了？

还有更严重的，假设用户是在服务器1.1上登录的， 用户登录过的信息保存到了该服务器的session中， 现在这个服务器挂掉了， 用户的session自然也不见了，当用户被失效转移到其他服务器上的时候，其他服务器发现用户没有登录， 就把用户踢到了登录界面， 让用户再次登录！

状态， 状态，状态！ 用户的登录信息，购物车等都是状态信息，  处理不好状态的问题，集群的威力就大打折扣，无法完成真正的失效转移， 甚至无法使用。

怎么办？  

一种办法是把状态信息在集群的各个服务器之间复制，让集群的各个服务器达成一致，  谁来干这个事情？ 只能是像Websphere, Weblogic这样的应用服务器了。 

还有一种办法， 就是把状态信息集中存储在一个地方， 让集群的各个服务器都能访问到：用Redis保存。

注：参考公众号《码农翻身》