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