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