分布式系统的一些知识

Tags: 系统设计 

目录

软件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中的活锁如何消除?


系统设计

  1. 各大云厂商的 API 设计风格
  2. Google 是如何实践 RESTful API 设计的?
  3. Netflix 的异地多活设计: Active-Active for Multi-Regional Resiliency
  4. Facebook 的缓存系统实践经验《Scaling Memcache at Facebook》
  5. 多机数据系统的正确性与一致性
  6. 《大型网站技术架构: 核心原理与案例分析》阅读摘录
  7. 《分布式金融架构课》阅读笔记2: 线性一致的分布式数据系统的实现过程
  8. 《分布式金融架构课》阅读笔记1: 单机&多机并发/多副本读写正确性和一致性
  9. 《消息队列高手课》阅读笔记: Rabbit/Rocket/Kafka/模型/消息事务/保序等
  10. 《消息队列高手课》阅读笔记: Rabbit/Rocket/Kafka/模型/消息事务/保序等
  11. 《Redis核心技术与实践》阅读笔记: 数据类型/存储开销/Rehash/案例等
  12. 《Redis核心技术与实践》阅读笔记: 数据类型/存储开销/Rehash/案例等
  13. 《高并发系统设计40问》阅读笔记: 数据库/缓存/消息队列/分布式服务
  14. 《高并发系统设计40问》阅读笔记: 数据库/缓存/消息队列/分布式服务
  15. 《MySQL实战45讲》阅读笔记: 索引类型/数据可靠性/事务/间隙锁/临时表等
  16. 系统性能分析方法论: 统计图谱工具
  17. 张磊《深入剖析Kubernetes》专栏的阅读笔记
  18. 代理服务软件haproxy、nginx、envoy对比,以及开源的API网关项目对比
  19. 蓝绿部署、金丝雀发布(灰度发布)、A/B测试的准确定义
  20. 阿里巴巴的应用限流和服务降级是怎样实现的?|如何打造平台稳定能力
  21. 陈皓《左耳听风》专栏的阅读笔记(持续更新)
  22. 好雨云帮,一款不错的国产开源PaaS
  23. 怎样为软件的不同版本命名?
  24. 怎样选择开源项目的license?
  25. Glusterfs的架构
  26. 怎样设计一个企业级的PaaS平台?
  27. 几种常见的LDAP系统
  28. DNS SRV介绍(一种用DNS做服务发现的方法)
  29. DNS,DNS-Domain Name System
  30. 思科的网络设备
  31. 虚拟化技术汇总
  32. 认证与授权系统的汇总
  33. 高可用实现方法汇总
  34. 编译器汇总
  35. Linux系统的优化方法
  36. CentOS7的一些变化
  37. 分布式系统的一些知识
  38. 计算机编程语言的特性汇总
  39. 网络通信的一些基础知识
  40. PCIE总线的一些知识
  41. 操作系统的API
  42. 网卡的一些知识
  43. Linux系统的构建过程
  44. 数据结构与算法
  45. CPU的相关知识

推荐阅读

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

友情链接:  李佶澳的博客  系统软件  程序语言  运营经验  关注方向  水库文集  网文收藏  网络课程  发现知识星球  百度搜索 谷歌搜索