干货 | 携程Redis跨IDC多向同步实践

最新推荐文章于 2024-07-22 03:23:13 发布

携程技术

最新推荐文章于 2024-07-22 03:23:13 发布

阅读量5.5k

点赞数 1

本文链接：https://blog.csdn.net/ctrip_tech/article/details/101041484

版权

本文介绍了携程在Redis跨数据中心双向同步的问题和解决方案，探讨了CRDT（Conflict-Free Replicated Data Type）在解决一致性问题上的应用。文章详细阐述了Redis面临的挑战，包括复制回源、环形复制、数据一致性等问题，以及Redis原生模型的限制。最终，携程选择了基于CRDT的强最终一致性理论模型，通过操作和状态基同步方式，实现Redis的多向同步。文章还讨论了CRDT的Register数据结构在Redis中的实现，包括LWW Register和OR-Set的应用。

摘要由CSDN通过智能技术生成

作者简介

祝辰，携程框架架构研发部资深研发工程师，主要负责Redis跨站点容灾方面的工作, 目前致力于研究分布式系统中的一致性问题以及相关理论和解决方案。此前曾就职于EMC混合云部门。对底层技术比较感兴趣，乐于研究操作系统和各种数据库的实现思路。

一、前言

跨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.