中心化和去中心化：

分布式的架构中，同一个服务会部署若干服务节点，在面对具体服务请求时，怎么决定由哪个节点来提供服务，根据实现方案分为中心化和去中心化两种方式。

中心化
在开源中间件codis的集群组网中，应用对缓存节点的访问都通过codis的proxy代理，由代理来决定数据存储到哪个节点上：

这种分布式的组网架构就是中心化的组网，由统一的中心codis-proxy进行调度。我司使用的zk/dubbo架构也属于中心化的组网，zk作为服务的注册中心。
去中心化
开源中间件redis的集群模式组网中（非我司使用的哨兵模式），没有中心节点，所有节点处于对等地位：

这种分布式的组网架构中，由节点间两两相互进行状态确认，根据算法集体决策出服务的提供方。

节点规模的因素
去中心化中，每个节点需要与其它所有节点进行状态确认，节点部署规模小的情况下，整个过程还算快捷。但当节点规模超大时，节点间交互过程会随节点数指数增长，整个过程会复杂漫长而不可控。

中心化的组网架构中，服务统一进行管理，管理逻辑相对简单和稳定，特别适用于大规模节点部署的情况。

中心节点单点故障的风险
中心化的设计存在的最大问题是中心节点的安危问题，如果中心节点出了问题，整个集群就奔溃了。为了解决这个问题，大多数中心化系统都采用了主备两个“中心节点”的设计方案，例如图3中两台codis-proxy本身采用的是负荷分担方式；

中心化带来的性能影响
中心化的设计中，对服务的访问往往需要先经过中心节点，会带来额外的该问路径，造成额外的性能开销，例如codis和redis底层存储节点都一样，但是不同组网架构中，coides性能明显差于redis的集群模式。

换存类型	Value长度	SET速率（条/s）	GET速率（条/s）
redis	100	32449	38013
	500	29743	36855
	1000	24245	33395
codis	100	18524	18709
	500	17481	18368
	1000	15523	16981

没有绝对的去中心化
实际上，完全意义的真正去中心化的分布式系统并不多见。相反，外部开来去中心化单工作机制采用了中心化设计思想的分布式系统正在不断涌出。在这种架构下，集群中的领导是被动态选择出来的，而不是认为预先置顶的，而且集群发生故障的情况下，集群的成员会自发的举行“会议”选举新的“领导”主持工作。最典型的案例就是ZooKeeper。

脑裂问题
去中心化设计里最难解决的一个问题是“脑裂”问题，这种情况的发生概率很低，但影响很大。脑裂指一个集群犹豫网络的故障，被分为至少两个彼此无法通信的单独集群，此时如果两个集群都各自工作，则可能会产生严重的数据冲突何错误。一般的设计思路是，当集群半段发生了脑裂问题是，规模较小的集群就“自杀”或者拒绝服务。