[Day 30] Partitioning (4) - Request Routing & 结论

Request Routing

partitioning 的最後一个段落想讲的问题：如果我想写入或读取 foo 这个 key，我该连哪个节点？

我们称这个一般化的问题为 service discovery (服务发现) ，其实这个问题其实不只资料库会遇到，只要是分散式系统都会有，尤其想以 high availability (高可用性) 为目标的系统。

我们有 3 个 routing 方法回答 client 这个问题，如下图：

1. 让 client 随便连一个节点 (ex: 用 round-robin load balancer)，然後如果刚好中了就直接查该节点，要不就 forward 到对的节点，然後在 pass 该节点的结果回去。
2. 建一个 routing tier ，然後用它负责接所有想知道 partition 在哪个节点上的 request。
3. client 有能力知道他该去哪里，然後直接连该节点，这个方法需要 client 知道每个节点各被分派了哪些 partition。

Ok，现在有个新问题是，要怎麽让这 3 个 routing 方法知道节点被分派了哪些 partition？

许多分散式系统都会依赖一个协调服务像 ZookKeeper 来帮助它们追踪丛集的 metadata，如下图所示，每个节点需要跟 ZooKeeper 注册并告知它 partition 的资讯，然後由它教上面讲的 3 个 routing 方法，也就是黑色线的部份。

最常见用 ZooKeeper 来当 partition 分配管理的就是 Kafka, HBase 了，我们公司开发的数据系统也是使用 ZooKeeper 做 service discovery，只是现在会慢慢转移到 Consul 上了。

另外，Cassandra 使用了不同的方法，他们使用 gossip protocol 来传播节点中所有的丛集变化，request 来的时候会送到任一节点，然後在 forward 到对的节点 (等於图 6-7 的方法 1)，这个模型的好处就是不需要依赖一个外部的服务。

总结

我们在 Day 27 讲了为什麽需要做 partition，然後介绍 2 个 partition 的策略：

• Key range partitioning

• Hashing partitioning

然後讲怎麽做 secondary index (Day 28)：

• Document-partitoin index
• Term-partitoin index

最後就是 Day 29 的 rebalancing 和今天的 routing 啦！

铁人心得

完成了这本书 Design Data Intensive Applications 的一半章节书摘了，这本书真心推荐给工程师看，很多策略都需要在你了解这些概念後才能针对各公司不同的资料特性做最适合的设定，所以里头不会告诉你该选哪个策略，好的概念放诸四海皆准，这本书能让你掌握这些概念，希望明年能把後 6 章写完啦，感谢各位。