复制延迟案例(1)-最终一致性

2 复制延迟的案例

容忍节点故障只是使用复制的一个原因。其它原因包括：

• 可扩展性，采用多节点处理更多请求
• 低延迟，让副本在地理位置上更接近用户

主从复制要求所有写请求都主节点处理，从节点只能处理。读多写少场景，这是不错的选择：创建多个从节点，将读请求分散到所有的从节点，从而减轻主节点的负载，并允许向最近的副本发送读请求。

这种可伸缩结构下，只需添加更多从节点，就能提高读请求的服务吞吐量。但这只适于异步复制，若试图同步复制到所有从节点，则单节点故障或网络中断将使整个系统无法写入。且节点越多，故障概率越高，所以完全同步的配置很不可靠。

2.1 最终一致性

若应用正好从一个异步的从节点读取时，而该从节点落后于主节点，它可能会看到过期数据，导致数据库中不一致：由于并非所有写入都反映在从节点，若同时对主、从节点发起相同查询，可能得到不同结果。这种不一致只是暂时的状态，若停止写DB，并等待一段时间，从节点最终会赶上并与主节点保持一致。不只有NoSQL数据库是最终一致的：关系型数据库中的异步复制追随者也有相同的特性。

“最终”一词故意含糊不清，理论上，副本落后的程度无限制。正常操作中，主节点和从节点上完成写操作之间的时间延迟（复制滞后）可能不足1s，这样的滞后，在实践中通常不会导致太大影响。但若系统在接近极限情况下运行或网络存在问题，延迟可轻松超过几秒甚至几分钟。