用Redis怎么搞跨中心集群扩展，弹性那块其实挺关键的事情

要理解Redis的跨中心集群扩展，核心在于解决两个矛盾：一是数据如何分布在不同地点的数据中心，既保证本地访问速度，又能在某个中心出问题时还能用；二是当流量突然变化，比如搞促销时用户量暴增，或者某个中心挂了，整个系统如何能像橡皮筋一样拉长缩短，自动适应，这就是你提到的“弹性那块关键的事情”。

过去很多人会用Redis的主从复制来做跨中心，比如在A中心放主库，在B中心和C中心放它的从库，这样A中心的应用可以快速写数据，B和C中心的应用可以读本地的从库，读的速度快了，但这方法弹性不好，写操作全集中在A中心，如果A中心到B中心的网络延迟高了，所有从库同步数据都会变慢，数据不一致的时间窗口会变长，更麻烦的是，如果A中心的主库突然宕机了，你得手动在B或C中心选一个从库把它变成新的主库，这个过程又慢又容易出错，系统在此期间基本不可用,弹不起来。

现在更主流和弹性的方式是使用Redis Cluster的跨中心部署方案，或者利用像哨兵（Sentinel）结合代理层（Proxy）的自定义架构，这里主要说Redis Cluster的方式,因为它更原生也更能体现自动弹性。

Redis Cluster本身能把数据分到很多个槽（slot）上，这些槽再分配给不同的主节点，做跨中心部署时，关键策略是如何摆放这些主从节点，一个常见的、追求弹性的策略叫“两地三中心”部署，假设我们有北京、上海两个主中心，还有一个作为备份的成都中心，我们不会傻到把所有的Redis主节点都放在北京，那样上海的应用每次写数据都要跨城市，延迟太高。 Instead，我们会把数据槽和对应的主节点均匀地分布在北京和上海，一半数据的主节点在北京，另一半在上海，为北京的每个主节点，配置一个从节点放在上海；同样，为上海的每个主节点，配置一个从节点放在北京，在成都中心，再为所有主节点配置一个额外的从节点作为“冷备”或“灾备”。

这样布置后,弹性就体现在以下几个方面：

第一，日常流量分担的弹性，北京的应用访问北京的主节点，写数据很快；上海的应用访问上海的主节点，写数据也很快，读请求可以分流到本中心的从节点上，这就实现了跨中心的负载分担，任何一个中心都能独立处理大部分请求，不会被单个中心的能力限制死，当某个业务的活动主要发生在北京，导致北京数据访问量激增时，由于数据是分布式的，压力会分散到北京集群的多个主从节点上，不会压垮某一个点，如果愿意，还可以把一部分读流量引导到上海的从节点，虽然延迟高一点，但能分担压力,这也是一种弹性。

第二，故障切换的弹性，这是最关键的，假设上海整个数据中心断电了，在上海的主节点和从节点全都失联，这时，Redis Cluster的节点发现和故障转移机制就会自动触发，原本在上海的主节点负责的那部分数据，它们的从节点在哪里？根据我们的布置，这些从节点都在北京，集群会自动在北京中心的这些从节点中，选举出新的主节点，来接替上海宕机的主节点的工作，这个过程是自动的，不需要人工干预，速度很快（秒级），虽然上海中心挂了，丢失了一部分数据的本地写入能力（因为原来在上海写的数据现在需要到北京的新主节点写，延迟高了），但整个Redis集群的大部分功能依然可用，系统没有彻底瘫痪，这种快速自动的故障转移能力，就是系统面对重大故障时的“弹性”。

第三，扩容的弹性，当业务增长，需要增加Redis的容量和性能时，你可以直接向集群中添加新的节点，你觉得成都中心不能只当备份，也想分担流量，你就可以把新的Redis节点加入到成都中心，然后通过集群的重分片（reshard）命令，将一部分数据槽从北京或上海的中心迁移到成都的新节点上，这个过程可以在线进行，不影响现有服务的正常运行，数据迁移完成后，应用就可以部分流量导向成都中心,实现了容量的弹性扩展。

要实现真正的弹性，光靠Redis Cluster本身还不够，应用层也需要配合，应用端需要配置所有数据中心的Redis Cluster节点地址，这样当发生故障切换后，应用客户端能自动感知到拓扑结构的变化，将请求发送到正确的新主节点上，一些更智能的客户端或代理层（比如Envoy）还能根据延迟策略，优先将请求发往本数据中心的节点,进一步优化体验。

用Redis搞跨中心集群扩展，弹性的核心在于三点：一是通过智能的数据和节点分布策略，避免单点瓶颈，实现负载分担；二是依赖集群的自动故障检测和切换能力，快速应对数据中心级别的故障；三是支持在线平滑扩容，适应业务增长，这其中，“节点跨中心分布”和“自动化”是实现弹性的两个基石，没有合理的分布，故障时无法切换；没有自动化,靠人工响应根本谈不上弹性。

参考来源：主要思想结合了Redis官方文档中关于Redis Cluster的部署最佳实践、以及业界在微服务架构下进行多活容灾的常见模式，例如阿里巴巴在其大型电商场景中应用的双活/多活数据中心架构理念。