redis 公网 安全_携程Redis跨IDC多向同步实践

一、前言

跨DC（数据中心）的数据同步是企业提升容灾实力的必备手段。随着携程业务向海外发展的速度越来越快，应用架构能够快速全球部署的能力也愈发重要。对于服务而言，我们可以尽量做到无状态的部署架构，来达到灵活拓展，快速部署的目的，比如 server-less。

然而，对于业务应用来讲，大量的业务逻辑是有状态的，仅仅做到服务的灵活拓展还不够，需要数据也拥有多站点共享的能力。

携程在一年前已经可以实现 Redis 单向跨区域同步，从上海将数据复制到美国加州，德国法兰克福，以及新加坡等众多海外站点，延迟稳定在 180ms左右，支持单个Redis 5MB/s 的传输带宽。

关于跨公网传输以及跨区域单向复制，详情参考这篇文章：携程Redis海外机房数据同步实践。

但是，技术人的目标就是不断突破自己。在Redis出海同步一年之后，业务上有了新的需求：能否在每个站点都可以独立地写入和读取，所有数据中心之间互相同步，而跨区域复制的一致性等问题，也可以由底层存储来解决？

单向同步的 Redis 固然可以解决问题，然而，大量的海外数据需要先回流上海，再从上海同步至各个数据中心，这一来一去, 不仅给业务开发带来了额外的复杂性和代码的冗余性，也给数据本身的时效性以及跨区域传输的费用带来了问题（携程的数据回源需要走专线，而 Redis 同步通过公网传输，由携程的框架中间件 - XPipe 来解决跨公网传输的安全和不稳定性因素）。[1]

二、技术选型

所以，我们需要的是一个分布式的Redis存储，能够实现跨区域多向同步。面对大型分布式系统，不免要讨论CAP理论，在跨区域多活的场景下如何取舍？

显然P（网络分区）是首要考虑因素。其次，跨区域部署就是为了提高可用性，而且对于常见的一致性协议，不管是2PC、Paxos还是raft，在此场景下都要做跨区域同步更新，不仅会降低用户体验，在网络分区的时候还会影响可用性。

对于Redis这种毫秒级相应的数据库，应用希望能够在每个站点都可以“如丝般顺滑”地使用，因此C必定被排在最后。

那是不是C无法被满足了呢？事实并非如此，退而求其次，最终一致也是一种选择。经过调研，我们决定选用“强最终一致性”的理论模型来满足一致性的需求。[2]

关于“最终一致性”(Eventually Consistency) 和“强最终一致性”(Strong Eventually Consistency)，大家可以参考 wiki 百科给出的释义：

(Strong Eventually Consistency) Whereas eventual consistency is only a liveness guarantee (updates will be observed eventually), strong eventual consistency (SEC) adds the safety guarantee that any two nodes that have received the same (unordered) set of updates will be in the same state. If, furthermore, the system is monotonic, the application will never suffer rollbacks.

三、问题

有了目标，自然是开始计划和设计，那么在开始之前有什么问题呢？

3.1 跨数据中心双向同步共同的问题

各种数据库在设计双向数据同步时，均会遇到的问题：

1）复制回源：A -> B -> A

数据从 A 复制到 B，B 收到数据后，再回源复制给 A 的问题。

2）环形复制：A -> B -> C -> A

我们可以通过标记来解决上一问题，然而系统引入更多节点之后，A 发送到 B 的数据，可能通过 C 再次回到 A。

3）数据一致性

网络传输具有延迟性和不稳定性，多节点的并发写入会造成数据不一致的问题。

4）同步时延（鉴于是跨国