一、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 架构的思维。让零碎体现得更符合实际需要，也更为灵便牢靠。但集群对资源需要不少。

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

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

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