基于Redis来搞数据同步，怎么搭个稳当点的框架，保证数据不乱跑也不卡顿

要基于Redis搭建一个稳当的数据同步框架,核心思想就是“各司其职，留足后路”，不能把所有希望都寄托在Redis永远不出问题上，得设计成即使Redis偶尔闹点小情绪，整个系统也不至于瘫痪，数据也不会乱套，下面就从几个关键方面来聊聊怎么搭。

得明确Redis在这里扮演的角色,它不适合做永久存储的数据库，更适合作为一个高速的“中转站”或者“缓冲区”，我们的框架要围绕这个定位来设计，数据从源头产生，先快速写入Redis，然后尽快地被搬运到最终的目的地（比如MySQL、另一个远程Redis、或者数据仓库等），这样，Redis的压力小了，速度也快了。

第一，保证数据不乱跑，核心是确保顺序和幂等性。

数据乱跑通常有两种情况：一是顺序错了，比如先执行了“更新”操作，后执行了“插入”操作，结果可能插入覆盖了更新；二是同一条数据被处理了多次，造成了重复。

为了解决顺序问题,可以参考阿里云Redis的“异步复制”和“分布式消息队列”的思想（来源：阿里云Redis官方文档），虽然Redis本身有发布订阅功能，但在网络不稳定时可能丢消息，不适合严格要求顺序的场景，一个更稳妥的做法是使用Redis的List结构，采用LPUSH和BRPOP命令组合，模拟一个先进先出的队列，生产者按顺序把数据LPUSH进队列，消费者用BRPOP按顺序取出来处理，因为List是先进先出的，只要单个生产者、单个消费者，就能天然保证顺序，如果担心处理速度跟不上，可以启动多个消费者，但这时候就需要根据业务数据设计分片键，比如同一个用户的订单数据总是放到同一个List里，由同一个消费者处理，这样才能在并行处理的同时，保证单个用户的数据顺序。

为了解决重复处理的问题（幂等性），可以参考消息队列常见的“幂等性”设计（来源：分布式系统常见设计模式），可以在数据本身带上一个唯一标识，比如业务主键或者一个唯一的流水号，消费者在处理数据前，先去最终的目的地数据库查一下，这个流水号的数据是否已经处理过了，如果处理过了，就直接跳过，或者，可以在Redis里用一个Set结构来记录最近一段时间处理过的流水号，处理前先查这个Set，这样更快，但要注意给这个Set设置过期时间，避免无限膨胀。

第二，保证不卡顿，核心是做好异步、缓冲和监控。

卡顿往往发生在两个地方：一是Redis本身扛不住写入压力；二是消费者处理速度太慢，导致数据积压。

对于Redis本身,要做好容量规划和性能优化，根据数据量估算好内存大小，并留有余地，避免使用像Keys *这样的慢查询命令，如果写入量非常大，可以考虑使用Redis集群模式，将数据分片到多个节点上，分担压力，这其实就是借鉴了“Redis集群”分而治之的思想（来源：Redis官方集群方案）。

更关键的是处理速度不匹配导致的积压,我们的框架必须是“异步”的，数据生产者把数据往Redis队列里一扔，就可以立刻返回成功，不用等待数据被真正处理完，这样前端业务就不会卡顿，消费者服务在后台不停地从队列里取数据处理。

万一消费者的处理速度因为某种原因（比如调用的下游服务变慢）突然下降，而生产速度不变，队列就会越来越长，最终可能撑爆Redis内存，为了解决这个问题，必须设置“背压机制”和“监控报警”，可以监控Redis队列的长度，比如当List的长度超过某个阈值（比如5000条）时，就通过监控系统发出告警，提醒开发人员排查消费者是否出了故障，更高级一点，甚至可以动态调节生产者的速度，比如当队列过长时，让生产者暂时放缓写入或抛出异常，让业务层降级处理，这就是一种简单的背压。

第三，搭建一个稳当的双保险框架。

光有上面的还不够“稳当”，因为Redis万一宕机，内存里的数据就全丢了，所以必须有一个“双保险”的机制，这里可以结合数据库的“事务日志”思想（来源：数据库设计原理）。

一个非常稳妥的架构是“先写数据库，再更新Redis”，注意，这不是说用数据库代替Redis队列，而是用数据库为数据做一个“持久化备份”，具体流程可以是：

1. 业务应用在产生数据后,首先在一个数据库事务里，完成对主数据库的写入，并同时将需要同步的数据内容和唯一ID插入到一张专门的“同步任务表”中，这个插入操作和业务数据写入在同一个事务里，保证了只要业务数据成功，同步任务就一定被记录了下来。
2. 上述事务提交后,再尝试将数据放入Redis队列，如果这一步失败了，没关系，因为同步任务已经持久化在数据库里了。
3. 除了从Redis队列消费的常规消费者外,再启动一个“补偿任务”服务，这个服务定时扫描数据库里的“同步任务表”，找出那些已经创建了较长时间（比如超过5分钟）但状态还不是“已完成”的记录。
4. 补偿任务将这些“滞留”的数据重新投递到Redis队列，或者直接由补偿任务自己尝试处理一次。

这样一来,即使Redis宕机了一小时，重启后，不仅新的数据能正常处理，补偿任务还会把宕机期间积压在数据库里的旧数据重新捞出来同步一遍，保证了数据最终不会丢失，这就是实现了“最终一致性”。

一个稳当的基于Redis的数据同步框架需要：1）用Redis List做有序缓冲，2）设计幂等性逻辑放重复，3）异步处理解耦上下游，4）监控队列长度防积压，5）用数据库做持久化备份，配合补偿任务做双保险，这样搭建起来，数据就很难乱跑，系统也不容易卡顿了。