一、Redis的分布式构造解读

首先redis采纳去中心化的设计这个了解是不到位的。redis分布式的模式，具备主从和集群两种，redis社区的集群计划redis cluster采纳的是去中心化设计。咱们先看看redis的演化过程：

上图是规范的Redis主从模式，只有Master接管写入申请，并将写入的数据复制给一个或多个Slave，这就造成了良好的读写拆散机制，多个Slave就能够分担读操作。所以redis主从是规范的分布式中心化思维。

因为redis的利用场景大多是极高并发的内存I/O，因而上图的主从模式下Master既要承当写入，又要承当对内各个节点复制，Master的资源耗费很大，而且随着slave节点越多，这个问题越显著，因而，redis又造成主从的一个变种模式：

上图是redis主从拓扑构造的一种树形构造，这个拓扑构造的益处在于Master不须要给有数多的slave节点进行复制数据了，交给处于下一层节点的Slave来解决。这样就能将Master的工作耗费尽量从复制中抽身。

可问题是像这种高并发的业务场景，Master始终是一个隐患，因为它接受着所有的写操作，一旦解体，若没有HA解决方案，集群整体就不可用了。因而redis社区推出的集群计划，其实就是解决主的压力，很天然地就思考到应用集群的分布式无核心模式。

上图中，右边是集群的核心模式，左边就是redis cluster应用的无核心模式。

redis cluster一些细节：redis无核心采纳虚构槽概念，这是独立于物理节点的，往往很容易将这块混同，虚构槽有0～16383个，redis的数据进行key的hash计算（具体公式网上很多），确定这笔数据是进入哪个槽位，而物理节点负责哪些虚构槽，这是由咱们指定的。

例如：当1个G的数据依照一条条带有key的记录写入redis cluster的时候，那么集群的各个节点只有承受到数据，就计算此条记录应该归哪个槽哪个节点，归本节点就写入与槽位映射的数据，不归本人的，就反馈客户端真正须要写入的节点，客户端再向记录所属节点发动二次申请，这就实现了1个G的数据在集群中的分片。

咱们先不管redis cluster更多的优劣问题，单从下面的演变能够看到redis的主从构造向cluster演变的过程，其实就是去核心的过程，就是为了让多客户端多业务申请并发性能能够失去更好负载。另外为了高牢靠HA，每个节点也能够在演变成master/slave的主从模式部署，即使是主节点宕掉，salve也会顶替上来。HA的毛病是节点数量又减少了一倍。

redis与rocketmq最大的不同，redis更并重在线联机业务的高并发解决，而后者是海量积压数据流的大吞吐接管和生产。因而其抉择分布式架构的目标也不同。当然这不代表着肯定是中心化就不适宜高并发，例如LSM-Tree代表的oceanbase作为集中式解决的特点，就很好的做到了在线联机业务的高并发写入，以及高速的热点数据（最近工夫）查找。

另外，因为redis cluster作为分布式中每个节点都是对等的，那么就肯定会存在集群治理上的一致性危险，因为在生产环境中各种异常情况都很特地，就会导致不同节点对集群的认可状态不统一，所以这时候手动染指调整每个节点在集群中状态状况就会增多。

二、Kafka和RocketMQ的分布式解读

咱们先看看比rocketmq更让人熟知的大师兄Kafka，解读一下Kafka集群的分布式特点。

Kafka的集群治理来自zookeeper集群，Broker的注册发现，Broker Controller的选举都是由zookeeper来帮助实现，然而Controller其实也不在音讯解决时做什么事件，只是在创立分区、分区再均衡等方面对其余节点做领导性工作。

Kafka真正起作用的还是分区leader和分区follower。例如：一个topic会被分成4个分区，3个正本，那么一共4*3=12个分区正本，若有4个broker，那么每个broker就会以一主两从，搁置三个分区的模式均匀分布。

Kafka的分区关系就是上图这个通信模式，生产者（Product）从任意节点获取Meta信息，找到broker中的leader分区正本，会向外面写调配好的数据，leader会向集群中其余broker的follower分区正本复制一份。

在这种分区构造关系下，其实每个broker都具备了topic分区数据申请拜访以及正本复制的Master能力。所以你问我kafka是不是核心模式，下来再说。

咱们再看看kafka的阿里兄弟rocketmq

rocketmq的架构曾经不应用zookeeper集群作为服务的注册发现了

rocketmq队列模式很大水平上与kafka十分像，然而具体操作细节上有本人的特点，更合乎高并发的，更多topic的，有程序要求的业务音讯解决，例如Topic进行了多个分片划分，分区又进行了多个Queue的划分，每个Queue只能对应一个消费者，来实现更高并发的生产端平衡负载。具体细节这就不赘述了。咱们次要还是看看rocketmq的分布式特色。

其实NameServer也就是做了一个broker的注册表，新注册broker或者异样退出broker都向对应的NameSever汇报或感知，NameServer之间是无核心的，大家通过锁注册表的形式共享信息，NameServer减少/删除所辖broker到这个注册表，并定时读取最新的集群所有broker信息。

生产者（Producet）连贯上一个NameServer，就能获取到想要的发送分区数据的brokers，消费者同理，发送生产的这个过程很相似Kafka操作topic，只是更粗疏到topic下的queue这个级别。

rocketmq还有一个特点是每个borker能够再分成主从模式，master进行队列操作，slave只做数据同步，期待master呈现故障进行替换。

rocketmq的namesever绝对于zookeeper具备更简略的构造，生产者和消费者对broker以及分区的获取必须来自namesever，只管namesever集群自身是无核心的，但整个rocketmq的brokers就是被namesever中心化治理的，但整体上product、consumer、brokers集群对这种集中管理的依赖水平其实不高，只是提供了很简略的broker元信息服务，真正的数据流还是交给各个broker本人去解决。

kafka的broker分区信息是散布在每一台broker的meta缓存外面，生产者和消费者能够在任意一台borker上获取须要操作的leader分区信息，kafka这就有点去核心的意思。然而这些meta缓存信息本质是来自zookeeper，zookeeper是必须依赖的，所以实质上Kafka仍然是中心化治理。

oceanbase分布式架构

oceanbase是LSM-Tree的一个典型实现，对于LSM-Tree能够看我的另一篇针对TiDB的答复文章中，次要对RocksDB的LSM-Tree的特色做了形容：
为什么分布式数据库这么喜爱用kv store？

作为oceanbase的架构，这次就不说太多了，就是想简略总结一下，oceanbase架构十分奇妙地融入了Lambda架构思维，但又和Lambda架构思维的关注点不同，Lambda架构关注的是计算，而oceanbase是存储。

oceanbase往往rootServer、updateServer部署在一个节点，独特承当了分布式核心的作用。

rootServer用于治理集群。

updateServer用于增量数据更新，尽量在内存中实现增量，造成最高效的近期增量数据查问，往往是当天数据。

chunkServer用于基线数据存储，理论状况往往是隔天历史数据。

mergeServer，承受客户端的SQL进行解释，并且对updateServer查问后果、不同chunkServer节点查问后果数据合并，往往是当天增量数据和隔天历史数据的查问与合并。

这与Lambda架构的速度层、批量层、服务层的思维十分相似。当客户发动查问统计申请，updateServer满足当天增量数据的实时查问统计，chunkServer节点提供基线数据的分布式查问，最终由mergeServer对updateServer当日后果和各chunkServer基线后果进行合并后，反馈给客户端，总之oceanbase架构设计是个艺术品。

总结

这篇文章次要是介绍了分布式中redis cluster去中心化治理，kafka与rocketmq中心化治理的架构特点，顺便提了一些oceanbase的架构特色。

音讯队列架构对于集中模式的依赖很轻，rocketmq也只是简略粗犷地应用了nameserver，用于broker注册发现，我认为kafka齐全能够在未来的设计勾销zookeeper，用更为去中心化的思路来设计注册和发现。

反观redis最成熟的计划还是主从，redis cluster带来的性能劣势无奈对消去中心化带来的不成熟和不牢靠问题，导致人工运维的复杂度和难度。所以redis cluster慎用！

oceanbase的架构很优雅也很艺术，抽时间好好再了解实际写一篇，oceanbase相似Google的Bigtable，Hadoop的Hbase，只是在其之上融入了Lambda架构的思维。让零碎体现得更符合实际需要，也更为灵便牢靠。但集群对资源需要不少。

我是“读字节”创作者，深刻大数据技术、解读分布式架构

返回读字节的知乎——理解更多对于大数据的常识

公众号“读字节” 分布式，大数据，软件架构的深度，业余解读