基于常见的中间件(Mysql、ElasticSearch、Zookeeper、Kafka、Redis)等分布式集群设计的机制，自己总结了在在集群设计过程中需要考虑的通用问题。
节点通信机制
主节点的增加、删除、通信机制。
路由算法
即数据路由到哪个节点的策略机制。在集群内有多个节点，数据该路由到哪个节点存储，也可以看作是，请求应该转发到哪个节点执行。
常见算法：
- 一致性hash算法
- hash算法
- 取余算法
- 指定分区算法
数据一致性算法与同步机制
分布式多节点(主从、主备、主副本)中，数据在多节点中的一致性问题。一般都是采用分布式一致性算法来实现，简单列举下：
强一致性算法：
● 说明：保证系统改变提交以后，立即改变节点的数据状态
● 算法：
○ Paxos
○ Raft
○ ZAB
弱一致性算法：
● 说明：也叫最终一致性，系统不保证改变提交以后立即改变集群的状态，但是随着时间的推移最终状态是一致的。
● 算法：
○ DNS系统
○ Gossip协议
当数据在主节点已写入后，如何同步到其他的副本/从节点中。是过半写而后直接返回给客户端、还是全写后在返回给客户端、还是在主节点写完后，直接返回给客户端，再异步写入其他节点。
写请求机制
目前来看，大多数的中间件集群写请求都是在主节点上执行的，而后将数据同步到从节点/副本。
选主机制
集群内的某个主节点宕机后，从节点(副本)如何选主？
集群数据倾斜
在集群内，由于数据路由算法或是其它问题，导致主节点间，数据量不一致，有些主节点数据量多，而有些节点数据量少，导致集群中数据的分配不均匀。
节点动态变化
由于网络或是负载均衡的考虑等，会有动态增减主节点的情况。发生此类情况后，是否会影响到此前已存储数据的路由，这直接影响到数据的读取。
读请求负载均衡
即在主从节点(主副本)间读请求的负载均衡机制。是轮训还是指定等等，这直接影响到系统的吞吐量与数据的准确性。比如，有些从节点(副本)由于数据一致性与同步机制的影响，可能此时数据还没同步过来，而读请求路由到了此节点，那么就会出现数据取不到情况了。
数据的原子性与持久性
其实这个可以不归属于分布式、集群内，但可以提一下。在节点崩溃后，如何恢复数据？甚至是从崩溃点恢复？如何不丢失数据？
WAL机制，大多数的中间件都实现了该机制。尤其是数据库与消息中间件和非内存性的数据存储中间件。