随着业务增长，有越来越多的应用使用持久化产品，持久化在一定程度上充当了数据库的角色。但依然会有很多业务出于数据安全、数据容灾或业务需求方面的考虑，在使用持久化存储产品的同时，也将数据存在于后端数据源，因此如何保证两个系统的数据一致性就成了必须要考虑的问题。针对于此，个人回访了部分有后端数据源的应用，结合前些时间段每周回访的应用使用场景，归纳了常用的三种一致性保证方法及典型案例，仅供需要的应用参考。
一.补偿机制
一致性程度：★★★★★
适用于对数据的实时性和一致性要求较高的应用。这种方式的一致性主要通过补偿来完成，因此需要有专门的补偿逻辑来尽量减少一致性给应用带来的影响。采用双写或外部工具同步的方式。若后端数据源成功，tair失败，则通过补偿机制在接受时间范围内进行retry。
优点：可以尽可能地保证数据的实时性和一致性。
缺点：处理逻辑较为复杂，需要有专门的补偿逻辑来处理。
典型案例：
1.xx服务器端：
xx需要存储对应的好友信息，这部分数据会双写到mysql和tair中，同时建立单独的检测线程。若mysql写成功了而tair写失败，则将记录失败的数据到失败日志中，线程检测到有失败记录，则将数据从db中二次补偿到tair中，若补偿成功，则记录到成功日志中，若补偿失败，则再记录到失败日志中，然后15分钟以后继续尝试。
xx会去监控失败日志，如果有数据一直补偿不成功，则采用人工介入。具体流程如图1-1所示：
图1-1
2.xx中心：
xx中心作为交易流程的核心系统，detail, xxxx detail,xx和xx的库存查询都会调用库存中心的接口，因此对读写性能，时序性，数据完整性和一致性都有很高的要求。具体架构和处理机制如图1-2所示：
图1-2
首先，高读写qps，尤其是读，需要达到百万级别的qps，因此在架构设计上采用ldb+mdb的二级缓存。写操作先走db，再写ldb，再写mdb。读操作则先访问mdb，若mdb没有命中，则会落回到ldb上，ldb再不命中，则要穿透到db上。
同时库存中心对时序性要求很高，因此选用xx来做mysql到tair的同步，xx以mysql的binlog记录为准进行数据同步，保证了操作的时序性和数据的完整性。
库存中心主要使用tair的计数器功能，这里在保证一致性上会出现一个问题，当出现这个key在db中存在，在ldb中不存在时，incr/decr基础接口在数据不存在的时候会直接根据初始值来初始化。这样就会和db中的数据不一致。因此最新版的tair客户端提供了可设最大值和最小值的incr/decr接口，若超出了范围，则会返回错误码。利用这个特性，应用可以设置defaultValue为0或者是负数，用来判断incr/decr的这个key是否存在。
对于当db操作成功，而ldb操作失败的情况，有专门的异步线程去检测是否有ldb操作失败，若ldb失败，则重新从db中拉数据set，同时失效mdb数据。异步补偿会指数级增加间隔时间retry，对于多次尝试失败的，则通知给另外系统处理或人工介入。
注：库存中心已经更改方案，以上仅供参考。
二.定期全量或增量build
一致性程度：★★★★
适用于数据更新很少的应用。与其说是定期build的策略保证了数据的一致性，倒不如说数据本身出现不一致的几率小。部分数据更新很少的应用，则直接人肉同步。通常这类应用访问仅会落在tair上，不再落回到后端数据源。
这类的大部分应用后端存储会存放在云梯上。目前tair提供了从云梯直接dump到tair的工具，同时，tair也提供了datax的同步支持，需要的应用可以直接联系tair开发人员。
优点：逻辑简单
缺点：适用范围小，只能适用于数据更新少或对一致性要求很低的应用
典型案例：
1. namelist
面向全集团的内部应用，使用tair存储各种名单列表，每天会有定时向tair增量导数据，不定期进行全量同步。也是典型的读多写少应用，数据更新量很少。读qps大约在3w左右。由于作为底层api，对响应时间要求高，平均要求1ms左右，因此访问只落在tair上，不会再落回到后端数据源。
2. cps-api
xxx后台基础应用，提供给top淘客api访问，使用tair存储卖家是否有cps推广的信息。读多写少应用，数据由定时任务全量dump到tair中，读qps在万级别。由于mysql无法承受高qps，所以tair访问不到也不会落回到db。
三.失效机制
一致性程度：★★★
适用于把持久化存储用于缓存的应用，对实时性和一致性没有太高的要求。这种方式的一致性主要由设置的失效时间来保证，如何设置合适的失效时间是应用使用的主要考虑要点。
优点：逻辑简单，适用面较广，可适用于大部分缓存类的应用，使用tair缓存的应用也可以采用这种方式。
缺点：需要对失效时间有较好的把控，需要在数据一致性和性能之间取个平衡。
典型案例：
1.xxx业务
对直通车接入推广宝贝进行准入判断，在tair中存储用户和店铺的信息，这部分信息需要从ic和uic同步。由于用户和店铺的更新不会很频繁，因此对数据设置过期时间，过期以后再从ic等接口获取新信息，完成update。
2.xx无线后端服务
使用tair存储快捷酒店管家OTA开放平台返回的酒店数据/房态价格计划数据，由于酒店列表，房态和订单时间会有更新，因此酒店列表缓存的失效时间初始定为24小时，房态和订单的暂定失效时间为5秒，失效后重新从OTA拉取数据。数据总量不大，但读取量较大，预估后续推广后会达到万级别的读qps，房态和订单由于失效时间短，因此会有一定的写qps。