mysql log bin redis_基于Canal同步MySQL Binlog到Redis踩到的坑

你的名字 2022-10-27 00:30 214阅读 0赞

![2ff34e647e2e3cdfd8dca593e17d9b0a.png][]

方案引入

分布式缓存Redis为保证我们系统的流畅提供了可靠的保证，但是随着系统规模的扩大，缓存的大规模使用，缓存的治理势在必行，因此我们引用了Canal中间件。通过Canal伪装成MySQL的Slave来消费MySQL的Binlog日志，然后将这些日志分发到RabbitMQ的不同队列中(同一个交换器，不同队列，队列名以数据库表名区分)，最后由RabbitMQ的消费者来更新缓存。除了这套架构，我们还约定业务代码中尽量不进行缓存写操作，只需写数据库，然后让这套系统自动同步缓存。如此一来，便可统一缓存的写处理逻辑。

方案实施如何在缓存未命中情况下回写缓存

在业务代码中，如果从缓存中未读到数据，但是在数据中读到数据，此时不直接去写缓存，而是交由消息队列去处理(保证时序性)。考虑如下场景，业务代码1数据库写入一条新的记录，系统开始自动去同步缓存(同步有延迟，未完成同步)

业务代码2此时读缓存，因缓存未同步完成，又去数据库读，读到该条记录

业务代码3直接去数据库更新该条记录(同步有延迟，未完成同步)

步骤1和步骤3相继同步缓存完成

业务代码2写缓存成功

该场景下，业务代码2的缓存覆盖了业务代码3的缓存，这时候缓存数据和数据库数据是不一致的。因此，我们将同一个消息队列的消息分为两类，又Binlog日志产生的消息和缓存未命中回写缓存的消息。如果是第一类消息，直接执行写缓存操作；如果是第二类消息，调用Redis的setnx原子操作，即只能缓存不存在的情况才能执行写操作。因为Binlog日志的时序性，我们只要保证Binlog日志转换而来的消息的生产者和消费者的时序性，即可保证缓存和数据库的一致性。如何保证缓存同步消息的生产者和消费者的时序性生产者的时序性由Canal保证，为了做到串行消费Binlog，Canal采用冷备的方式实现HA(无论是Canal Server还是Canal Client)

消息队列可以通过串行消费消息来保证时序性(RabbitMQ设置队列Exclusive属性为true)

如何降低缓存同步的延迟

为了保证消息的串行消费，无法通过添加RabbitMQ Consumer的方式来提供消费速率。为了防止消费速度低于生产速度产生消息积压而导致缓存同步延迟，我们避免在消费端处理重业务，只处理轻量级的缓存写操作，如果确实要处理重业务，要不异步处理，要不转发到其他消息队列处理。如何验证该方案的性能及可靠性

为了验证该方案的可行性，我们从生产导出一天的Binlog日志，然后将这一天的Binlog全部导入压测数据由此产生大量的消息。我们发现，单个消息队列中的消息生产速率大概在1000条/s，而消费速率几乎与生产速率保持相同的水平(实际上消费速率上限应该是大于生产速率，MySQL，Canal，或者RabbitMQ的写性能才要低于Redis的写性能)，并且日志导入过程几乎没有发现任何的错误日志。在日志导入结束后，我们抽样验证MySQL和Redis数据的一致性，未发现不一致数据。

方案踩的坑

场景一：业务1写入一条新记录到数据库中，然后同步该记录到缓存

业务2读取缓存数据(此时是业务1写入的缓存)

业务3更新了数据库中该记录的状态

业务2根据缓存取到的数据，更新后写入到数据库中(覆盖了业务3更新的状态)

在该场景下，业务2不应该从缓存中读数据，而应该从数据库读数据，因为业务2要进行写库操作。

场景二

若业务代码大量读取历史数据时，因为缓存数据已经过期，从数据库中读取的数据会回写到Redis缓存，导致Redis缓存内存被历史数据占用。正常情况下，我们都会设置Redis最大允许使用内存，并配合数据淘汰机制，保证Redis内存不够时可以写数据成功。目前，线上设置内存淘汰机制为allkeys-lru，当大量历史数据回写缓存时，会将一些重要的缓存数据清理，导致业务逻辑错误。

针对场景二，有几种解决方案：设置maxmemory-policy为volatile-ttl或者volatile-lru，然后根据数据重要程度对不同的缓存设置不同的过期时间。

对历史数据的读取，直接从数据库读取

将数据库行对象回写缓存时，考虑该对象的创建时间和过期时间两个，如果两个变量累加和大于当前时间，则不应该回写缓存。

场景二不仅仅针对我们设计的缓存同步方案，任何缓存回写机制都要考虑该场景。

[2ff34e647e2e3cdfd8dca593e17d9b0a.png]: /images/20221024/6cfe3a2ffe6f46eba1373e0ad7e497b3.png