中心化的设计思想很简单，分布式集群中的节点器按照角色分工，大体上分为两种角色：Leader和Worker。Leader通常负责分发任务并监督Worker，让Worker一直在执行任务；如果Leader发现某个Worker因意外状况不能正常执行任务，则将该Worker从Worker队列去除，并将其任务分给其他Worker。基于容器技术的微服务架构Kubernetes就恰好采用了这一设计思路。
即充分相信每个Worker，Leader只负责任务的生成而不再指派任务，由每个Worker自发领任务，从而避免让个别Worker执行的任务过多，并鼓励能者多劳。
但我们难以同时安排两个Leader以避免单点问题。为了解决这个问题，大多数中心化系统都采用了主备两个Leader的设计方案，可以是热备或者冷备，也可以是自动切换或者手动切换，而且越来越多的新系统都具备了自动选举切换Leader的能力，以提升系统的可用性
去中心化设计中最难解决的一个问题是“脑裂”问题，这种情况的发生概率很低，但影响很大。脑裂指一个集群由于网络的故障，被分为至少两个彼此无法通信的单独集群，此时如果两个集群各自工作，则可能会产生严重的数据冲突和错误。一般的设计思路是，当集群判断发生了脑裂问题时，规模较小的集群就“自杀”或者拒绝服务。
总之，分布式系统中重要的理论和设计都是建立在分布式系统不可靠这一基础上的，因为系统不可靠，所以我们需要增加一些额外的复杂设计和功能，来确保由于分布式系统的不可靠导致系统不可用性的概率降到最低
分布式集群的一致性是在分布式系统里“无法绕开的一块巨石”。实际上，由于分布式系统的不可靠性，通常只要保证集群中超过半数的节点（N/2+1）正常并达到一致性即可
但比较特别的是在这个场景里，集群中的其他节点都是Leader的追随者——Follower。客户端发送给Leader的所有指令，Follower都复制一遍。这听起来很简单，但在一个分布式环境下实际上很难实现。
Raft算法把分布式集群的一致性问题抽象成一个特殊的状态机模型——ReplicatedState Machine，如下图所示
目前最终一致性基本成为越来越多的分布式系统所遵循的一个设计目标
由于ZooKeeper集群的实现采用了一致性算法，所以它成为一个非常可靠的、强一致性的、没有单点故障的分布式数据存储系统。但它的目标不是提供简单的数据存储功能，而是成为分布式集群中不可或缺的基础设施
1）提供集群的集中化的配置管理功能
2）需要提供简单可靠的集群节点动态发现机制
3）需要实现简单可靠的节点Leader选举机制
4）需要提供分布式锁
ZooKeeper的数据结构可以被认为是模仿UNIX文件系统而设计的，
每个ZNode都可以通过其路径（Path）唯一标识
ZooKeeper中的ZNode有一个ACL访问权限列表，用来决定当前操作API的用户是否有权限操作此节点，这对于多个系统使用同一套ZooKeeper或者不同的ZNode树被不同的子系统使用来说，提供了必要的安全保障机制。ZooKeeper除了提供了针对ZNode的标准增删改查的API接口，还提供了监听ZNode变化的实时通知接口——Watch接口，
此外，ZNode是有生命周期的，这取决于节点的类型，节点可以分为如下几类。● 持久节点（PERSISTENT）：节点在创建后就一直存在，直到有删除操作来主动删除这个节点。● 临时节点（EPHEMERAL）：临时节点的生命周期和创建这个节点的客户端会话绑定，也就是说，如果客户端会话失效（客户端宕机或下线），这个节点就被自动删除。● 时序节点（SEQUENTIAL）：在创建子节点时可以设置这个属性，这样在创建节点的过程中，ZooKeeper就会自动为给定的节点名加上一个数字后缀，作为新的节点名。这个数字后缀的范围是整型的最大值。● 临时性时序节点（EPHEMERAL_SEQUENTIAL）：同时具备临时节点与时序节点的特性，主要用于分布式锁的实现。