分布式Redis：水平拆分、主备复制、断点续传、故障转移- 《深入分布式缓存：从原理到实践》读书笔记

前言

本文主要内容：

来源于《深入分布式缓存：从原理到实践》第八章 分布式Redis的读书笔记。

数据存储系统的挑战和Redis的应对策略

Redis作为数据存储系统，无论数据存储在内存中还是持久化到本地，作为单实例节点，在实际应用中总会面临如下挑战：

• 数据量伸缩：单实例Redis存储的key-value对的数量受限于单机的内存和磁盘容量。长期运行的生产环境中，随着数据不断地加入，存储容量会达到瓶颈。虽然Redis提供了key的过期机制，在作为缓存使用时通过淘汰过期的数据可以达到控制容量的目的。但当Redis作为NoSQL数据库时，业务数据长期有效使得淘汰机制不再适用。
• 访问量伸缩：单实例Redis单线程地运行，吞吐量受限于单次请求处理的平均时耗。当业务数据集面临超过单实例处理能力的高吞吐量需求时，如何提升处理能力成为难点。
• 单点故障。Redis持久化机制一定程度上缓解了宕机/重启带来的业务数据丢失问题，但当单实例所在的物理节点发生不可恢复故障时，如何保证业务数据不丢以及如何在故障期间迅速地恢复对应业务数据的可用性也成为单点结构的挑战。

上述问题对于数据存储系统而言是通用的，基于分布式的解决方案如下：

• 水平拆分：分布式环境下，节点分为不同的分组，每个分组处理业务数据的一个子集，分组之间的数据无交集。数据无交集的特性使得水平拆分解决了数据量瓶颈，随着分组的增加，单个分组承载的数据子集更小，即通过增加分组来伸缩数据量。同时水平拆分也也解决了访问量瓶颈，业务数据全集的请求被分摊到了不同分组，随着分组数的增加，数据全集的总吞吐量也增加，访问量的伸缩性得以实现。
• 主备复制：同一份业务数据存在多个副本，对数据的每次访问根据一定规则分发到某一个或多个副本上执行。通过W+R>N的读写配置可以做到读取数据内容的实时性。随着N的增加，当读写访问量差不多时，业务的吞吐量相比单实例会提升到逼近2倍。但实际中，读的访问量常常远高于写的量，W=N, R=1，吞度量会随着读写比例的增加而提升。
• 故障转移：当业务数据所在的节点故障时，这部分业务数据转移到其他节点上进行，使得故障节点在恢复期间，对应的业务数据仍然可用。显然，为了支撑故障转移，业务数据需要保持多个副本，位于不同的节点上。

水平拆分（sharding）

水平拆分（sharding）为了解决数据量和访问量增