分布式系统的一些知识

目录

软件or软件库

tooz

SWIM && Gossip

SwIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol

Gossip

SWIM是一种无中心的分布式协议,各个结点之间通过p2p的方式交流信息,实现数据的最终一致性。Gossip基于SWIM, 加快了信息的传播速度,缩短了达到最终一致性需要的时间。

Serf是Gossip的开源实现。

SWIM特别适用于系统中的每个结点都需要感知到整个系统的状态的情形。

当系统中新增结点时:

1. 新结点连接到系统中的一个结点
2. 新结点从所连接的结点上获取整个系统的状态信息
3. 新结点向系统中有限个结点发布自己的加入的信息
4. 系统中的结点接收到新结点的加入信息后,各自再次向系统中有限个结点发送这个新结点的加入信息,依次传递

当系统中有结点失联时:

1. 系统中所有的结点定时与系统中其他有限个结点进行通信
2. 结点A发现结点B没有响应自己的通信请求
3. 结点A委托系统中有限个结点,请求他们探查结点B的状态
4. 结点A发现它委托的结点都没能探测到B的存在,于是A向系统中的有限个结点发布B已经失联的消息,该消息在系统中一层层的传播起来
5. 经过了一定时间后,系统中的结点都没能收到结点B证实自身存在的消息,结点B被从系统中去除

Serf的几个使用场景

Web Server 与 Load Balance:

                      +------------------+     +------------------+
                      | LB1   +----------|     | LB2   +----------|
                      |       |  Gossip  |     |       |  Gossip  |
                      +-------+------+---+     +-------+------+---+
                                     |                        |
                                     +------------------------+
                                     |
         +------------------+        |      +------------------+ 
         | Web1  +----------|        |      | Web1  +----------| 
         |       |  Gossip  |        |      |       |  Gossip  | 
         +-------+----+-----+        |      +-------+----+-----+ 
                      |              |                   |
                      +--------------+-------------------+


1. LB1、LB2、Web1、Web2通过Gossip协议组成一个系统
2. 系统的状态通过Gossip协议在成员间扩散
3. 当LB1或者LB2,发现系统中的WebX成员发生变化时,自行调整代理策略

Redis:

              +---------------------+      +---------------------+       +---------------------+  
              | Redis1   +----------|      | Redis2   +----------|       | Manager  +----------|  
              | Master   |  Gossip  |      | Master   |  Gossip  |       |          |  Gossip  |  
              +----------+----+-----+      +----------+----+-----+       +----------+----+-----+  
                              |                            |                             |
                              |                            +-----------------------------+
                              |                            |
     +---------------------+  |   +---------------------+  |   +---------------------+ 
     | Redis1   +----------|  |   | Redis2   +----------|  |   | Redis2   +----------| 
     | Slave    |  Gossip  |  |   | Slave    |  Gossip  |  |   | Slave    |  Gossip  | 
     +----------+----+-----+  |   +----------+----+-----+  |   +----------+----+-----+ 
                     |        |                   |        |                   |
                     +--------+-------------------+--------+-------------------+


1. RedisX通过Gossip协议组成一个系统
2. 系统的状态通过Gossip协议在成员间扩散
3. Manager发现系统中有结点被删除时,重新调整系统内结点的关系,或者向系统中添加新的结点。

CAP – 待细化

无法设计一种分布式协议,使得同时完全具备CAP三个属性:

Consistency(一致性):  这里指的是强一致性。
Availiablity(可用性): 系统在出现异常时可以提供服务。
Tolerance to the partition of network(分区容忍): 系统可以对网络分区这种异常情况进行容错处理。

假设存在两个副本, 当网络分区时,客户端只能访问到其中一个副本:

1. 如果要保证强一致性,这时候客户端就不能够修改副本(可用性不能满足)。
2. 如果要客户端依然能够修改副本,那么强一致性不能满足。

Paxos – 待完善

A1 A3 A4同时发起了投票请求,请求自己为主持人, 分别发送1-1、1-3、1-4,1-代表第1轮投票。

A1-A5接收到这些请求的顺序不同,结果如下(按照接收的先后从上到下排列):

发起人             发起人   发起人
 A1        A2        A3       A4       A5
1-1       1-1       1-3      1-4      1-3
1-3       1-3       1-1      1-1      1-4
1-4       1-4       1-4      1-3      1-1

三个发起人同时发起了投票,

如果发起人都不肯让步, A2和A5的态度将决定哪一个发起人当选
	- 如果A2和A5选择一致,主持人被选举出来   <结束>
	- 如果A2和A5选择不一致,三个发起人都无法当选
		- 进入第2轮投票
			- 如果发起人还是坚守第1轮的选择,会导致第1的情形重演,一直无法选举成功  <死循环>
			- 如果发起人推举同一个人作为主持人, 主持人被选举出来   <结束>

Paxos中的活锁如何消除?

作者微信

推荐阅读

Copyright @2011-2019 All rights reserved. 转载请添加原文连接,合作请加微信lijiaocn或者发送邮件: [email protected],备注网站合作

友情链接:  李佶澳的博客  小鸟笔记  软件手册  编程手册  运营手册  爱马影视  网络课程  奇技淫巧  课程文档  精选文章  发现知识星球  百度搜索 谷歌搜索