分布式概述
当我们谈论分布式系统时，本质上是在探讨一个核心问题：如何通过多台机器的协同工作，来达成单台机器无法实现的目标。
这个目标可能是巨大的存储容量、极高的计算吞吐量，或是永不中断的服务。而这一切的起点，通常源于对“更大容量”的追求。
为何走向分布式：对容量的追求
单台机器（节点）的硬件能力存在物理和成本上的天花板。无论是磁盘空间、内存大小还是 CPU 算力，单点的 扩展性（Scalability）终将耗尽。分布式系统的首要目的，就是通过 横向扩展（Scale-out）来突破这一限制。我们加入更多普通的、廉价的节点，让它们协同工作，从而获得远超单机性能的聚合容量与算力。
分片（Sharding）：化整为零的艺术
为了将海量数据分布到众多节点上，我们必须对数据进行切分。分片（Sharding）就是这样一种技术，它将一个完整的大型数据集逻辑或物理地分割成更小、更易管理的部分（称为分片），并将它们分散到不同的节点上进行存储和处理。
分片策略是系统设计的基石，它直接决定了数据的分布是否均衡、查询效率的高低以及未来扩容的难易。常见策略有基于哈希值范围、基于数据主键或基于实体属性等。
副本（Replication）：容错与高可用的基石
更多的机器意味着更高的出错概率。单个节点的故障不应导致整个系统的不可用或数据丢失。为此，我们引入 副本（Replication）。
我们为每一个数据分片创建多个副本，并将它们存储在不同的物理节点上。这样，即使某个节点发生故障，其他节点上的副本依然可以继续提供服务，从而实现 容错（Fault Tolerance）和 高可用性（High Availability）。同时，将读请求分发到多个副本，也是提升系统读取吞吐量的有效手段。
共识（Consensus）：在分歧中寻求一致
一旦引入了副本，一个无法回避的问题随之而来：如何保证所有副本中的数据是完全一致的？
当客户端向系统写入新数据时，这一更新必须被正确地应用到该数据的所有副本上。而网络延迟、节点故障等因素，随时可能导致各副本的状态出现分歧。共识算法（Consensus）正是为了解决这个问题而诞生。它能在分布式网络中的多个节点之间，就某个数据的值达成一致，即使在部分节点出现故障或网络发生分区的情况下也是如此。
Paxos、Raft 等经典算法，为分布式系统提供了可靠的一致性保证，是构建强一致性存储系统的核心。
权衡的艺术：CAP 的永恒命题
然而，共识并非没有代价。为了达成一致，节点间需要进行多轮通信和协调，这会消耗额外的网络资源，并增加请求的响应延迟，从而影响系统的整体性能。
这便引出了分布式系统设计中最著名的 权衡（Trade-off）：在一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）之间无法同时满足，必须有所取舍。这就是 CAP 理论。共识算法通常倾向于保证强一致性和分区容错性（CP），而有时则会为了更高的可用性和性能，选择放松对一致性的要求（AP）。
这种对性能、资源消耗和一致性级别的选择，又会反过来影响我们最初的设计：系统该如何分片？每个分片该有多少个副本？这正体现了分布式系统设计是一个环环相扣、不断权衡的过程。
总结
分布式系统的设计始于对容量（Scalability）的追求，通过分片（Sharding）技术实现数据的分散存储。为了应对更高的故障率，我们为分片创建副本（Replication）以实现容错（Fault Tolerance）。而为了保证副本间的一致性，又需要引入共识算法（Consensus），但这会带来性能与资源上的开销，需要我们进行精心的权衡。