4.3 中登必备之复制与分区

分布式人两个重要手段：Partition 和 Replicate。面对新人时，我更愿把它们称为 “伎俩”。实是因为其宛如两板斧一样大道至简，不必故弄玄虚。

然而，一旦分布式开发者熟悉了这套模式，就会惊奇地发现，所有的分布式系统方案，本质上都是在回答这两个问题（也会惊奇地发现自己由小登向中登转变，难免有一丝淡淡的悲伤✋😭🤚）。

背景和动机

让我们暂时忘记这些手段吧，不妨先来看看技术背景是什么。前文中，我们讨论了分布式系统中混沌的环境，网络、计算随时都可能崩溃、损坏。

如果我们仍然延续单机应用的做法，会发生什么？

• 数据安全性威胁：数据只有一份，先不考虑天灾，只是这块磁盘挂点后就再无退路可言！
• 数据单机瓶颈：磁盘/内存的读写总是有上限的，那超过上限的请求，怎么抗？
• 计算单机瓶颈：CPU 的计算能力和线程数量总是有上限的，那超过上限的请求，怎么抗？

如果我们有一台能够无限扩容的单机就好了！然而事实是残酷的。有个最简单的方式是花钱请人设计系统¹！（这样我们就能把他们交付的系统当做单机用了！^_^ ）。要么只能想一些工程手段去绕开单机的瓶颈。

分布式思想是如此地朴素：

1. 单机无法满足要求，那多台机器咋样？
2. 单机磁盘容易爆炸，那我就多复制几份可否？顺便顶一下磁盘 IO 流量？
3. 单机计算不行，那我们就分开计算、最后合并结果如何？

现有常见的分布式系统便可以如下梳理：

系统	复制（Replication）核心思想	分区（Partition）核心思想
GFS - 存储	数据副本：（默认3份）跨机架存储数据块，实现容错和高可用，避免单点/机架 故障导致数据丢失	数据分区：将大文件拆分为固定大小数据块（64MB），分散存储在不同节点，突破单机存储容量限制
MapReduce - 计算	任务副本：当某个 Reduce 任务失败时，系统会在其他节点重新调度该任务（计算任务的复制）	任务分区：将输入数据分片，每个分片对应一个 Map 任务；中间结果按 Key 分区，实现并行计算和相同 Key 的聚合处理
Flink - 计算	任务副本：关键任务可配置 “备用任务（Standby Task）”，主任务故障时快速切换	任务分区：将数据流拆分为多个并行子流，通过灵活的分区策略（哈希、轮询等）分配给不同算子实例，提升计算并行度
Kafka - 消息队列	数据副本：每个分区，Leader 负责读写，Follower 同步数据并作为故障备份	数据分区：将主题拆分为多个分区，作为并行读写的基本单位，通过 Key 路由保证相同消息的有序性和集中处理

这些系统无非是将任务或者数据进行分区和复制操作。鉴于我们是分布式存储漫游指南，后续本文内容都是指存储系统视角。