分布式系统基础

大多数系统最初都会从单台服务器开始，因为它简单，易于构建和管理。在低规模下，一台机器就可以处理请求、执行逻辑并存储数据，而不会带来太多复杂性。

随着使用量增长，这种模式会逐渐失效。流量增加会导致更高的延迟和资源耗尽，而更大的数据集会拖慢查询速度，并给存储系统带来压力。

可靠性也会成为一个重大问题。如果那台服务器发生故障，整个系统就会下线。对于需要持续可用的系统来说，这是不可接受的。

为了克服这些限制，系统会将工作分布到多台机器上。它不再依赖单台服务器，而是共享工作负载，从而实现可扩展性和容错能力——但同时也带来了协调和一致性方面的新挑战。

在分布式系统中，多台服务器协同工作来处理请求、存储数据并执行逻辑。每台服务器都是一台独立的机器，通常运行在不同的位置，但从用户的角度看，它们共同组成一个单一系统。

与单机系统不同，这些节点不共享内存。相反，它们通过网络发送消息进行通信，这会带来延迟以及故障的可能性。

因此，协调变得至关重要。即使在物理上彼此分离，节点也必须就共享状态达成一致，例如数据值或系统决策。

关键挑战在于：如何让这组独立的机器在面对延迟、故障以及网络中的部分可见性时，仍然作为一个系统保持一致且可靠地运行。

复制是分布式系统中的一项核心技术，同一份数据会存储在多台机器上。通常，一个节点作为主节点，负责处理写入；其他节点作为副本，接收数据的拷贝。

这种架构提高了可靠性。如果主节点或任何副本发生故障，系统仍然可以使用剩余节点继续运行，从而减少停机时间。

复制还可以提升性能，尤其适用于读多写少的系统。与其把所有读取请求都发送到单台机器，不如将请求分散到多个副本上。

不过，复制也会带来复杂性。更新必须传播到各个节点，而同步延迟可能会导致副本之间出现暂时的不一致。

在分布式系统中，机器通过网络进行通信，而网络本身并不可靠。连接可能中断，消息可能延迟，系统的整个部分也可能变得无法访问。

当节点被分成彼此无法通信的多个组时，就会发生网络分区。例如，由于网络故障，Server A 可能无法访问 Server B，尽管它们都仍在运行。

这带来了一个根本性的挑战：分区两侧都可能继续独立处理请求，从而可能导致状态冲突。

分区容错性意味着系统被设计为即使在这些故障发生时也能继续运行，并接受节点之间的协调可能会暂时无法实现。

在分布式系统中，数据通常会复制到多台机器上，这就带来了保持这些数据同步的问题。一致性定义了这些副本在任意时刻的对齐程度。

在强一致性下，一旦发生写入，所有后续读取——无论命中哪个节点——都会立即返回更新后的值。这需要节点之间进行紧密协调。

在最终一致性下，更新会随着时间传播。写入之后，某些节点可能会暂时返回旧数据，但所有节点最终都会收敛到相同的状态。

这种权衡是不可避免的。强制严格一致性的系统通常会牺牲性能或可用性，尤其是在网络延迟或故障发生时。

CAP 定理描述了分布式系统中的一个硬性约束：当发生网络分区时，你无法同时保持完美的一致性和完全的可用性。

一致性需要节点之间进行协调。为了让每次读取都返回最新写入，节点必须就当前状态达成一致，这可能需要等待跨网络通信。

另一方面，可用性优先考虑响应能力。即使某些节点无法访问，系统仍会继续处理请求，这可能导致返回过期或不一致的数据。

分区容错性是不可避免的，因为在任何真实系统中，网络故障都会发生。这迫使系统在分区期间做出权衡：要么延迟响应以保持一致性，要么立即响应并接受暂时的不一致。

在分布式系统中，多个节点独立运行，但许多操作需要它们以协调的方式执行。如果没有协调，节点可能会做出冲突的决策，从而导致数据不一致或系统故障。

领导者选举是一种常见模式，其中会选出一个节点来做决策或处理关键任务。这可以防止多个节点同时执行相同的操作。

分布式锁确保在同一时间只有一个节点可以访问或修改共享资源，这类似于单机并发中的锁，但它是在网络中实现的。

共识算法更进一步，即使在发生故障的情况下，也允许节点就某个值或决策达成一致。ZooKeeper、etcd 和 Consul 等工具提供了这些协调机制，因此工程师不必从零实现它们。

一旦系统变成分布式系统，它就必须通过网络运行，而网络本身就是不可靠的。消息可能会延迟、丢失，或者乱序到达，这使得简单操作都更难推理。

数据一致性也会成为一个挑战。由于复制，在任何给定时刻，不同节点可能持有同一数据的不同版本，尤其是在高负载或网络延迟较高时。

节点之间的协调又增加了一层难度。要确保多台机器就共享状态达成一致，或者按正确顺序执行任务，需要复杂的协议和谨慎的设计。

这些挑战不是边缘情况——它们是根本性的。设计能够在这些问题存在时仍然保持正确和可靠的系统，正是分布式系统工程要解决的核心问题。