CRDT——解决最终一致问题的利器

概述

跨数据中心的数据同步是企业提升容灾能力的必备手段，对于社交、视频直播、电商以及游戏等访问规模大、业务分布广的行业，跨区域全球部署也愈发重要。
然而面对大型分布式系统, 不免要讨论CAP理论，在跨区域多活的场景下如何取舍？显然P(网络分区)是首要考虑因素。其次，跨区域部署就是为了提高可用性，而且对于常见的一致性协议，不管是2PC、Paxos还是raft，在此场景下都要做跨区域同步更新，不仅会降低用户体验，在网络分区的时候还会影响可用性，因此C必定被排在最后。那是不是C无法被满足了呢？事实并非如此，退而求其次，最终一致也是一种选择。CRDT(Conflict-Free Replicated Data Type)1是各种基础数据结构最终一致算法的理论总结，能根据一定的规则自动合并，解决冲突，达到强最终一致的效果。2012年CAP理论提出者Eric Brewer撰文回顾CAP[3]时也提到，C和A并不是完全互斥，建议大家使用CRDT来保障一致性。自从被大神打了广告，各种分布式系统和应用均开始尝试CRDT，redislabs[4]和riak[5]已经实现多种数据结构，微软的CosmosDB[6]也在azure上使用CRDT作为多活一致性的解决方案。
阿里云redis现配套推出了全球多活产品[7]，助力企业在云上部署跨区域服务，并且依据CRDT确保在全球多活的场景下，所有redis实例中数据最终一致。本篇文章我们会对CRDT进行简要介绍，下一篇文章将说明我们是如何实现CRDT的。

CRDT简介

先简单统一一下概念和名词:

• object: 可以理解为“副本”
• operation: 操作接口，由客户端调用，分为两种，读操作query和写操作update
• query: 查询操作，仅查询本地副本
• update: 更新操作，先尝试进行本地副本更新，若更新成功则将本地更新同步至远端副本
• merge: update在远端副本的合并操作

一个数据结构符合CRDT的条件是update操作和merge操作需满足交换律、结合律和幂等律，具体证明见[1]，在此不做赘述。如果update操作本身满足以上三律，merge操作仅需要对update操作进行回放即可，这种形式称为op-based CRDT，最简单的例子是集合求并集。

如果u