python分布式服务系统框架_聊聊分布式系统架构

一、分布式系统的经典基础理论

1、分布式系统设计的两大思路：中心化和去中心化中心化：中心化的设计思想在自然界和人类生活中是如此的普遍和自然，它的设计思想也很简单，分布式集群中的节点按照角色分工，可以分为两种角色--“领导”和“干活的”，中心化的一个思路就是“领导”通常分发任务并监督“干活的”，谁空闲了就给它安排任务，谁病倒了就一脚踢出去，然后把它的任务分给其他人；中心化的另一个思路是领导只负责生成任务而不再指派任务，由每个“干活的”自发去领任务。

去中心化：全球IP互联网就是一个典型的去中心化的分布式控制架构，联网的任意设备宕机都只会影响很小范围的功能。去中心化设计通常没有“领导”和“干活的”，角色一样，地位平等，因此不存在单点故障。实际上，完全意义的去中心化分布式系统并不多见，很多看起来是去中心化但工作机制采用了中心化设计思想的分布式系统正在不断涌现，在这种架构下，集群中的领导是动态选择出来的，而不是人为预先指定的，而且在集群发生故障的情况下，集群的成员会自发举行会议选举新的领导。典型案例如：zookeeper、以及Go语言实现的Etcd。

2、分布式系统的一致性原理在说明一致性原理之前，可以先了解一下cap理论和base理论，具体见《事务与柔性事务》中的说明。

对于多副本的一致性处理，通常有几种方法：同步更新--即写操作需要等待两个节点都更新成功才返回，这样的话如果一旦发生网络分区故障，写操作便不可用，牺牲了A。异步更新--即写操作直接返回，不需要等待节点更新成功，节点异步地去更新数据，这种方式，牺牲了C来保证A。折衷--只要保证集群中超过半数的节点正常并达到一致性即可满足要求，此时读操作只要比较副本集数据的修改时间或者版本号即可选出最新的，所以系统是强一致性的。如果允许“数据一致性存在延迟时间”，则是最终一致性。

如Cassandra中的折衷型方案QUORUM，只要超过半数的节点更新成功便返回，读取时返回多数副本的一致的值。然后，对于不一致的副本，可以通过read repair的方式解决。read repair：读取某条数据时，查询所有副本中的这条数据，比较数据与大多数副本的最新数据是否一致，若否，则进行一致性修复。此种情况是强一致性的。

又如Redis的master-slave模式，更新成功一个节点即返回，其他节点异步地去备份数据。这种方式只保证了最终一致性。最终一致性：相比于数据时刻保持一致的强一