Routing in Distributed Systems

客户端路由 client-side routing

客户端自己决定请求发到哪个节点，例如

• 通过一致性哈希（Consistent Hashing）或某种分片规则定位到具体节点

• 通常客户端会缓存一份集群拓扑信息或元数据

代表系统：

• Cassandra

• Riak

• Kafka Producer（可以自己决定发送到哪个 partition）

优点：

• 请求路径短，直接到目标节点

• 减少跳转、中间层压力

缺点：

• 客户端实现复杂，要感知集群拓扑变化

• 拓扑变化（比如扩容）可能导致客户端缓存失效，需要有刷新机制

服务端路由 server-side routing

客户端只连接某个入口节点（称为 router、coordinator、proxy 等），再由这个节点在集群内部路由转发。

代表系统：

• MongoDB（mongos）

• TiDB（SQL 层接入）

• HBase（通过 RegionServer）

• Elasticsearch（coordinating node）

优点：

• 客户端简单，不需要关心数据分布

• 系统可以集中处理元数据、负载均衡

缺点：

• 增加一跳，可能引入性能瓶颈

• 入口节点成为潜在的热点或单点故障点（需高可用设计）

对比例子

Kafka（客户端路由）：

Kafka 的 producer 会从 broker 获取元数据，然后根据 topic 的 partition 和 key 做 hash，直接发送消息到对应的 broker。这样中间没有 proxy，性能高。

MongoDB（服务端路由）：

MongoDB 分片集群中，客户端连接 mongos，而不是直接连接 shard。mongos 是查询协调器，接收请求后根据 chunk 的分布信息，分发请求到对应 shard 上。

Redis Cluster

数据分片

• Redis Cluster 将整个 key 空间划分为 16384 个 slot（称为 哈希槽）。

• 每个 key 通过 CRC16(key) % 16384得到其 slot 编号。

• 每个节点负责其中的一部分 slot。

路由流程（客户端侧）：

1. 客户端第一次连接时 ，会从任意一个 Redis 节点获取集群拓扑信息（即所有 slot 分布在哪些节点）。

2. 计算 slot ：发送命令时，客户端根据 key 计算它属于哪个 slot。

3. 选择节点 ：根据 slot 到节点的映射，直接将命令发送到对应的节点。

如果客户端路由错了（比如映射信息过期），Redis 节点会返回：

• -MOVED ：告诉客户端该 slot 已经迁移到其他节点，客户端需更新 slot 映射表。

• -ASK ：表示 slot 正在迁移过程中，客户端暂时重定向到新节点（但不更新本地映射）。

客户端需要支持这类重试和 slot 映射更新逻辑。

Redis Cluster 节点如何管理 slot？

Redis Cluster 将 16384 个 slot 显式分配给集群中的节点。每个节点会维护一份 slot -> 节点 的映射信息，并参与集群协议，确保这个映射在整个集群中是一致的。