分布式系统的一些知识
目录
软件or软件库
SWIM && Gossip
SwIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol
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被从系统中去除
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中的活锁如何消除?
