小白科普：分布式和集群

一、分布式

 

小明的公司有3个系统： 系统A、系统B和系统C ，这三个系统所作的业务不一样，被部署在3个独立的机器上运行， 他们之间互相调用（固然是跨域网络的）， 通力合做完成公司的业务流程。

将不一样的业务分布在不一样的地方， 这就构成了一个分布式的系统，如今问题来了， 系统A是整个分布式系统的“脸面”， 用户直接访问，用户量访问大的时候要么是速度巨慢，要么直接挂掉， 怎么办？ 

 

因为系统A只有一份， 因此会引发单点失败。

 

二、集群（Cluster）

 

小明的公司不差钱，就多买几台机器吧， 小明把系统A一会儿部署了好几份（例以下图的3个服务器），每一份都是系统A的一个实例， 对外提供一样的服务，这样能睡个安稳觉了，不怕其中一个坏掉了，我还有另外2个呢。  

 

这3个服务器上的系统就组成了一个集群。

但是对用户来讲，一会儿出现这么系统A ，每一个系统的IP地址都不同，  到底访问哪个？ 

 

若是全部人都访问服务器1.1 ，那服务器1.1 会被累死， 剩下的三个闲死，成了浪费钱的摆设。

 

三、负载均衡（Load Balancer）

 

小明要尽量的让3个机器上的系统A 工做均衡一些， 好比有3万个请求，那就让3个服务器各处理1万个（固然，这是理想情况）， 这叫负载均衡。  

 

很明显，这个负载均衡的工做最好独立出来， 放到独立的服务器上 （例如Ngnix）：

后来小明发现， 这个负载均衡的服务器虽然工做内容很简单，就是拿到请求，分发请求，可是它仍是有可能挂掉啊， 单点失败仍是会出现。

 

没办法，只好把负载均衡也搞成一个集群， 不过和系统A的集群有两点不一样：

 

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

2. 同一时刻，咱们只让一个负载均衡的机器工做， 另一个原地待命。 若是工做的那个挂掉了，待命的那个就顶上去。

四、弹性

 

若是这3个系统A的实例仍是知足不了大量的请求，那就再加服务器！ 

 

双11来了，用户量是平时的10倍， 小明向领导申请费用又买了几十台服务器，一会儿把系统A部署了几十份。  但是双11事后， 流量一会儿降下来了，那几十个服务器用不上了，也变成了摆设！

 

被领导批评之后，小明决定尝试一下云计算，  在云端能够轻松的建立、删除虚拟的服务器， 那样就能够轻松地随着用户的请求动态的增减服务器了。  双11来了就建立虚拟服务器，等到双11过去了就把不用的关掉， 免得浪费钱。 

 

因而小明的系统具有了必定的弹性。

 

五、失效转移

 

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

 

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

 

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

 

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

 

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

 

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

 

怎么办？  

 

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

 

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

小明据说Redis 不错， 那就用Redis来保存吧 ！

（完） Java架构交流群：860170416