如何pick分布式系统协调框架?Eureka or Zookeeper?
刘刚 | 2020-07-10 13:13:12  149 浏览
随着互联网的快速发展,分布式的思想已经广泛应用在各个行业中了。分布式是与中心化相对的概念,中心化的思想是把关键的内容集中处理,这样的好处是提高了效率、更专注专一,坏处是如果中心系统挂了,所有的内容都没有了。
分布式的思想是把整个模块分成多个模块去处理,每个人负责一部分,这样的好处是即使某一部分没有了,其它的内容还存在,造成的损失不大,坏处是多模块协调沟通成本高。
比如在企业管理中不会把核心模块只交给某个人负责,而是培养多个人都了解此模块,这样即使核心人员离职了,企业还是可以正常运转,不会有多大影响。
而在计算机系统的世界中,分布式系统的出现是为了用便宜的、普通的机器完成单个计算机无法完成的计算存储任务,更好的利用资源处理更多的任务。
早期的时候一套应用程序全部署在一台机器上,但随着业务量的增长、用户请求的增加,该机器已经不能满足更多的计算存储任务,即使换更好的机器或者单独升级某个组件能力(比如加磁盘、加内存、换更好的CPU)也不能解决问题,这时候只能采用SOA或微服务设计、分布式模式进行部署了,在系统架构上把业务进行拆分,子业务与子业务之间通过网络进行通信,共同协调完成任务,在部署模式上把不同的子业务部署在不同的机器上,子业务扛不住业务压力时再加新的机器支撑。
在业务拆分细粒化、业务部署集群化的情况下就会带来新的问题,不过戴上CAP的帽子后,问题多多的分布式系统也能变得很可爱~
那么什么是CAP定理呢?CAP是一致性Consistency、可用性Availability、分区容错性PartitionTolerance,CAP定理是说这三个目标不能同时满足。
首先我们来看看分区容错性,在分布式系统中,大部分系统都分布在子网络内,每个子网络就是一个区,比如你的服务一台部署在北京,一台部署在上海,这就是两个区。而这两台服务器可能由于网络问题而无法通信,这就是分区容错,一般来说,由于客观原因,分区容错是不能避免的。
下图中G1和G2在不同的区,G1向G2发送消息,但由于链路坏了或其它原因,G2可能收不到。

然后我们再来看看一致性,一致性的意思就是数据必须一致。比如你位于北京区域,然后在淘宝下单买了一个商品,这时候在北京区域的订单系统服务器上有了你的订单记录,但是在上海区域的服务器系统没有获取这个信息,所以就会存在你在北京时能看到自己的订单记录,但到了上海后没有订单记录的情况(基于CDN内容分发网络原则,网络请求往最近的服务器区域发送)。如下图所示,客户端往服务器G1写了一条数据V0,G1必须要往G2服务器再写入V0这条数据,这样当客户端向G2服务器请求数据时才能获取V0这条数据的同步,如果G1没有向G2同步写数据,就会出现客户端向G2请求时数据不一致。


最后我们来看看可用性,可用性就是服务任何时候都可以用,只要客户端发起请求,服务器端就必须响应。
那么一致性和可用性为什么不能并存呢?比如为了保障G2的一致性,那么G1在写操作的时候,就必须锁定G2的读操作和写操作,只有数据同步后才能开放G2的读写,在锁定的时候,G2就必然不可用;而如果保障G2的可用性,那么G1在写操作的时候,G2就不能被锁定,数据就会不一致。因此CA只能择一,鱼和熊掌毕竟也不能兼得
选鱼方案之Zookeeper--要CP不要A
在某些业务,比如交易场景中,因为涉及到了金钱,所以必须要数据一致,有任何差错,老板就会拿刀架你脖子上了。
Zookeeper就是保障了数据一致性的方案。在Zookeeper中使用专有的ZAB原子广播协议来保障数据的一致性,在该协议中会包含三个角色Leader领导者、Follower跟随者、Observer观察者,Leader是唯一处理写请求的人;Follower是接收客户端的请求,处理读请求但不处理写请求,并且可以参加或投票Leader的选举(当Leader挂了的时候);Observer是不能参加也不能投票的Follower。
当客户端向服务器发送请求,要写入数据时,服务器会根据自己的角色和该请求的类型进行判断,如果自己是leader那么就处理该请求;如果自己是Follower,那么服务器会根据请求类型进行决策,如果是写请求,就转发给Leader,Leader会给所有的Follower都发一个提议,让大家来投票,如果超过一半的服务器都同意这个提议,那么Leader才会进行操作,从而保障了数据的一致性。
比如在我们刚刚的订单场景中,当用户在客户端发起一个商品购买请求给到订单系统服务器时,服务器集群中的Leader判断这是一个写请求,需要往数据库里插入一条某某用户已购买某某商品的记录,它会把这个记录直接放在自己的服务器的数据库里,并同步给其它的服务器也需要写入该记录。
如果客户端的请求发送给了Follower的服务器,那么它会转发给Leader,Leader就给所有的服务器都发通知,问他们是否可以写入此条记录,如果超过一半的人都表示可以操作,那么Leader、对应的服务器就会把数据写入在服务器里。

选熊掌方案之Eureka--要AP不要C
在某些业务,比如电商场景中,对于服务的可用性要求非常高,双十一的时候打不开商品的页面简直是会要了女人的命啊,当然打开了就会要了男人的命,哈哈哈,开个小玩笑。
所以在电商场景中服务的可用性是非常重要的,Eureka就是保障了服务可用性的方案。在Eureka集群中,服务器与服务器是通过Replicate来同步数据的,不区分master节点、slave节点,每个应用都指向其它应用,当某个服务器宕机时,该应用就切换到新的服务器节点执行任务,待宕机服务器恢复正常后,再将服务切回来。
如下图所示,还是以订单场景来讲解,在北京、上海、西安机房的服务器里都部署了订单服务的应用程序,但是可能西安机房断电了出了故障,从而导致西安的用户使用订单服务时就不能正常的使用了,但是因为整个大系统采用的是跨地区的高可用的集群部署模式,因此当西安的服务不可用时,用户的请求就会走到上海,由上海的机房来提供服务,同时把数据同步给到北京的服务器,但这时候就会出现一个问题:西安机房的服务器由于断电了没能提供服务,因此断电这段时间内的服务数据时没有的,就出现了北京上海西安的数据不一致的情况。在业务场景中通常采用人工校对、客服等的方式可以解决。


Zookeeper我所欲也,Eureka亦我所欲也,二者不可得兼。可用性我所欲也,一致性亦我所欲也,然二者不可得兼,同学们根据自己的业务场景选择合适的分布式协调框架即可~~



标签:
京ICP备15057271号 京公网安备11010802017390号 客服邮箱:ke@kgc.cn