“鸡蛋不能放一个篮子里”，如何确保千亿数据万无一失？

副本机制（Replication），是指分布式系统在多个节点间保存有相同数据的冗余，即副本（Replica/copy）。当出现某一个节点的数据丢失时，可以从副本上读取到数据。数据副本是分布式系统中解决数据丢失问题的唯一手段。
合适的做法并非以机器作为副本单位，而是将数据划分为合理的数据段，以数据段为副本的单位。在实际操作中，会尽量保持每个数据段的大小相等，并控制在一定范围内。这些数据段有多种称呼，如segment，fragment，chunk，partition，region等。数据段的大小通常会控制在一个合理的范围内（例如几十MB到几GB），并且尽量保持均等。这些数据段的划分方式与之前讨论的数据分布策略紧密相关
对于哈希分布的方式，每个哈希分桶后的余数可以作为一个数据段。为了控制数据段的大小，通常会使分桶的数量大于集群规模。例如，如果有3台服务器和10G的数据，为了使每个数据段的大小约为100M，可以在哈希后取模100，这将产生1000个数据段，每台服务器可以负责333个数据段。
对于按数据范围分布的方式，可以将每个数据区间作为一个数据段，并控制数据区间中数据的大小。对于按数据量分布的方式，可以自然地将每个数据块作为一个数据段。
对于一致性哈希分布的方式，常见的做法是将一致性哈希环分为若干等长的分区，分区的数量通常远大于节点的数量。假设哈希函数是均匀的，那么每个分区中的数据可以作为一个数据段。
一旦数据被划分为数据段，系统便以数据段为单位进行副本的创建、放置和管理。这样，副本的分布与物理机器不再是硬性绑定，一台机器可以承载来自不同数据段的多个副本，有利于资源利用和故障恢复。副本的放置策略通常会考虑机架感知（Rack Awareness）、可用区感知（Availability Zone Awareness）等，以避免单点故障导致所有副本同时失效。

领导-追随者副本机制
如何保障多个副本在不同节点上的一致性是分布式系统的一个核心问题。最常见的解决方案就是采用领导-追随者（Leader-Follower）的副本机制，也称为主从复制（Master-Slave）或主备复制（Primary-Backup）。该机制通过明确角色分工和数据同步策略，在保证数据一致性的同时，兼顾系统的可用性和性能。
1）副本角色划分：副本分为领导者副本（Leader Replica）和追随者副本（Follower Replica）。所有客户端的写请求必须由Leader处理，Leader首先将数据写入其本地存储的副本中，同时将数据变更记录到预写日志（Write-Ahead Log, WAL）中。Follower被动地从Leader处复制数据变更。它们通过拉取（Pull）或由Leader推送（Push）的方式，从Leader的日志中获取变更记录，并按照相同的顺序在本地应用这些变更，以保持与Leader的数据同步。
2）读写分离与一致性权衡：客户端可以从Leader或Follower读取数据。然而，由于Follower的数据更新存在延迟，读取Follower时可能无法保证强一致性（Strong Consistency），只能提供最终一致性（Eventual Consistency）。为了满足不同场景的需求，系统通常允许客户端根据一致性要求选择读取源：强一致性读取直接访问Leader，而最终一致性读取可以访问Follower以减轻Leader的负载。

3）数据分布与副本组管理：数据通过分布算法（如一致性哈希）被路由到一个副本组（Replica Group）。每个副本组包含一个数据段的多个副本（典型数量为3个或5个），这些副本通常分布在不同的物理节点、机架甚至数据中心。其中一个副本被选为Leader，负责处理所有写请求并将变更同步到其他Follower副本。

4）故障切换与数据一致性保障：当Leader节点发生故障时候，需要进行副本切换。切换副本的难点在于，如何确定节点的状态以及发现原Leader节点异常，另外需保证新切换的Leader节点的副本数据与原Leader节点保持一致。
典型系统包括： Google Bigtable, Apache HBase, Apache Kafka, MongoDB (Replica Set模式), MySQL 主从复制等。

多主多从副本机制
在多主复制（或称无主（Leaderless）/去中心化）模型中，逻辑上所有副本节点地位平等，多个（甚至所有）副本都可以接收和处理写请求。节点间通过分布式一致性协议（如Quorum、向量时钟等）进行数据同步和冲突解决。
这种架构具有较高的可用性，任何一个节点的故障通常不会影响写服务的可用性，只要仍有足够数量的节点在线。客户端可以将写请求发送到地理位置最近或响应最快的节点。然而，去中心化副本机制也存在一定的局限性，主要体现在其协议复杂度较高，节点间需要频繁同步数据和协调状态，因此在数据一致性达成效率和系统整体性能方面，通常较中心化副本机制有所降低。
尽管没有单一固定的Leader，但在某些操作（如成员变更、模式变更）或特定一致性协议（如Raft、Paxos的变种应用于数据层面）中，可能仍需要临时的领导者选举或协调者角色。
典型系统包括： Amazon DynamoDB, Apache Cassandra, Riak, CouchDB。

未完待续
很高兴与你相遇！如果你喜欢本文内容，记得关注哦！！！