Redis缓存和数据库读写操作时一致性的保证方案详解

在分布式系统中，Redis作为高性能缓存被广泛用于减轻数据库压力，但缓存与数据库是两个独立存储组件，读写操作的时序差异、网络延迟、服务异常等问题，极易导致两者数据不一致，进而引发业务异常（如查询到旧数据、数据超卖等）。本文将从读写操作场景出发，详解各类一致性保证方案，分析其优缺点、实现逻辑及生产级适配场景，帮助开发者根据业务需求选择最优方案。

核心前提：Redis缓存与数据库一致性的核心目标是「最终一致性」（多数业务场景可接受），强一致性需付出极高性能代价，仅适用于金融、支付等核心场景。所有方案均需基于Redis与数据库的正常通信、缓存过期机制正常生效为基础。

一、核心痛点分析（一致性问题的产生场景）

一致性问题的本质是「缓存操作」与「数据库操作」的时序、原子性无法保证，常见产生场景如下：

写操作异常：先更新缓存、再更新数据库，数据库更新失败，导致缓存存旧数据、数据库存新数据；或先更新数据库、再更新缓存，缓存更新失败，导致数据库存新数据、缓存存旧数据。
读操作异常：缓存未命中时，高并发读请求穿透到数据库，同时多线程更新缓存，导致缓存写入脏数据；缓存过期瞬间，大量读请求穿透，引发数据库压力激增，同时可能出现数据不一致。
服务/网络异常：更新数据库或缓存时，服务宕机、网络中断，导致其中一个操作未执行，出现数据分歧；主从架构下，数据库主从同步延迟，缓存更新基于主库数据，从库查询出现不一致。
缓存淘汰/过期：缓存因内存溢出被淘汰、过期时间设置不合理，导致读请求穿透到数据库，若此时数据库数据已更新，缓存重新加载后数据一致，但若加载过程中数据再次变更，会出现短暂不一致。

二、读操作一致性保证方案（优先避免穿透、脏读）

读操作的核心需求是「避免读取到脏数据、减少缓存穿透」，需结合缓存查询时序、双重校验、锁机制实现，以下是3种生产级方案，按易用性和性能排序。

方案1：缓存优先+双重校验（基础方案，适配大部分读多写少场景）

1.1 核心逻辑

遵循「先查缓存，缓存未命中则查数据库，查询后更新缓存」的基础时序，新增「双重校验」机制，避免高并发下缓存写入脏数据，同时结合缓存过期时间，保证最终一致性。

核心流程：读请求 → 查Redis缓存 → 缓存命中 → 返回数据；缓存未命中 → 加本地锁 → 再次查缓存（避免多线程重复穿透） → 仍未命中 → 查数据库 → 更新Redis缓存（设过期时间） → 释放锁 → 返回数据。

1.2 Java代码实现（Spring Boot + RedisTemplate）

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import org.springframework.util.StringUtils;
import java.util.concurrent.TimeUnit;@Service
public class CacheReadService {private final StringRedisTemplate stringRedisTemplate;// 本地锁，避免同一进程内多线程并发穿透private final Object localLock = new Object();public CacheReadService(StringRedisTemplate stringRedisTemplate) {this.stringRedisTemplate = stringRedisTemplate;}/*** 缓存优先+双重校验，保证读操作一致性* @param cacheKey Redis缓存key* @param dbKey 数据库查询标识（如商品ID）* @return 一致的数据*/public String readWithDoubleCheck(String cacheKey, Long dbKey) {// 第一次校验：查询缓存，命中直接返回String cacheData = stringRedisTemplate.opsForValue().get(cacheKey);if (StringUtils.hasText(cacheData)) {return cacheData;}// 加本地锁，拦截同一进程内多线程synchronized (localLock) {// 第二次校验：再次查询缓存，避免其他线程已更新缓存cacheData = stringRedisTemplate.opsForValue().get(cacheKey);if (StringUtils.hasText(cacheData)) {return cacheData;}// 缓存未命中，查询数据库String dbData = queryDataFromDb(dbKey);if (StringUtils.hasText(dbData)) {// 更新缓存，设置过期时间（避免缓存雪崩，保证最终一致性）stringRedisTemplate.opsForValue().set(cacheKey, dbData, 300, TimeUnit.SECONDS);}return dbData;}}// 模拟数据库查询（实际替换为DAO层方法）private String queryDataFromDb(Long dbKey) {// 模拟数据库查询耗时try {Thread.sleep(500);} catch (InterruptedException e) {Thread.currentThread().interrupt();}// 模拟返回数据库数据return "数据ID：" + dbKey + "，内容：最新数据";}
}

1.3 方案优缺点

优点：实现简单、性能损耗低，本地锁减少Redis锁竞争，双重校验避免高并发穿透和脏数据，适配读多写少、对一致性要求不高（最终一致即可）的场景。
缺点：存在短暂不一致（数据库更新后，缓存未更新前，读请求会获取旧数据）；缓存更新失败时，会出现数据分歧，需依赖缓存过期机制兜底。

1.4 适用场景

商品详情查询、用户信息查询、新闻列表等读多写少、对数据实时性要求不高（允许秒级延迟）的场景。

方案2：缓存+Redis分布式锁（高并发读场景，避免分布式穿透）

2.1 核心逻辑

在方案1的基础上，将「本地锁」替换为「Redis分布式锁」，解决分布式部署（多服务实例）下，多进程并发穿透数据库的问题，同时保证分布式场景下的读操作一致性。

核心优化：缓存未命中时，先获取Redis分布式锁，再查询数据库、更新缓存，确保同一时刻只有一个服务实例能执行「查库+更缓存」操作，避免分布式环境下的脏数据写入。

2.2 Java代码实现（Spring Boot + Redisson）

import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import org.springframework.util.StringUtils;
import java.util.concurrent.TimeUnit;@Service
public class DistributedCacheReadService {private final StringRedisTemplate stringRedisTemplate;private final RedissonClient redissonClient;public DistributedCacheReadService(StringRedisTemplate stringRedisTemplate, RedissonClient redissonClient) {this.stringRedisTemplate = stringRedisTemplate;this.redissonClient = redissonClient;}/*** 缓存+Redis分布式锁，保证分布式场景下读操作一致性* @param cacheKey 缓存key* @param lockKey 分布式锁key（与缓存key对应，如"lock:cache:product:1001"）* @param dbKey 数据库查询标识* @return 一致的数据*/public String readWithDistributedLock(String cacheKey, String lockKey, Long dbKey) {// 第一次校验缓存String cacheData = stringRedisTemplate.opsForValue().get(cacheKey);if (StringUtils.hasText(cacheData)) {return cacheData;}// 获取Redis分布式锁RLock redisLock = redissonClient.getLock(lockKey);try {// 尝试获取锁：等待3秒，租赁时间10秒（启用看门狗自动续期）boolean lockSuccess = redisLock.tryLock(3, -1, TimeUnit.SECONDS);if (!lockSuccess) {// 获取锁失败，返回默认值或提示，避免阻塞return "暂时无法获取数据，请稍后重试";}// 第二次校验缓存cacheData = stringRedisTemplate.opsForValue().get(cacheKey);if (StringUtils.hasText(cacheData)) {return cacheData;}// 查库+更新缓存String dbData = queryDataFromDb(dbKey);if (StringUtils.hasText(dbData)) {stringRedisTemplate.opsForValue().set(cacheKey, dbData, 300, TimeUnit.SECONDS);}return dbData;} catch (InterruptedException e) {Thread.currentThread().interrupt();return null;} finally {// 释放锁（仅当前线程持有锁时释放）if (redisLock != null && redisLock.isHeldByCurrentThread()) {redisLock.unlock();}}}// 模拟数据库查询private String queryDataFromDb(Long dbKey) {try {Thread.sleep(500);} catch (InterruptedException e) {Thread.currentThread().interrupt();}return "数据ID：" + dbKey + "，内容：分布式场景最新数据";}
}

2.3 方案优缺点

优点：解决分布式部署下的并发穿透问题，避免多服务实例同时查库；锁粒度可控，不影响整体并发性能；结合缓存过期机制，保证最终一致性。
缺点：增加Redis锁的性能损耗（相比本地锁）；锁获取失败可能导致请求降级；仍存在短暂不一致（数据库更新后缓存未更新的间隙）。

2.4 适用场景

分布式服务、高并发读场景（如秒杀商品详情、热门接口查询），需要避免多服务实例穿透数据库的场景。

方案3：缓存预热+定时同步（高实时读场景，减少不一致窗口）

3.1 核心逻辑

通过「缓存预热」提前将数据库数据加载到缓存，避免缓存未命中的穿透问题；通过「定时同步任务」周期性将数据库数据同步到缓存，缩小缓存与数据库的不一致窗口，适用于对读数据实时性要求较高的场景。

核心流程：系统启动时缓存预热（批量加载数据库数据到Redis） → 定时任务（如每30秒）查询数据库变更数据 → 同步更新Redis缓存 → 读请求直接查询缓存，无需穿透数据库。

3.2 Java代码实现（Spring Boot + 定时任务）

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Service;
import java.util.List;
import java.util.concurrent.TimeUnit;@Service
public class CacheWarmUpAndSyncService {private final StringRedisTemplate stringRedisTemplate;private final DbDao dbDao; // 模拟DAO层，用于查询数据库public CacheWarmUpAndSyncService(StringRedisTemplate stringRedisTemplate, DbDao dbDao) {this.stringRedisTemplate = stringRedisTemplate;this.dbDao = dbDao;}/*** 系统启动时缓存预热（加载所有核心数据到Redis）*/@PostConstruct // 系统启动后执行public void cacheWarmUp() {// 模拟查询数据库核心数据（如热门商品、高频访问用户）List<DataDTO> dataList = dbDao.queryAllCoreData();for (DataDTO data : dataList) {String cacheKey = "cache:core:" + data.getId();// 缓存预热，设置过期时间（比定时同步周期长，避免缓存过期）stringRedisTemplate.opsForValue().set(cacheKey, data.getContent(), 600, TimeUnit.SECONDS);}System.out.println("缓存预热完成，加载核心数据" + dataList.size() + "条");}/*** 定时同步任务（每30秒同步一次数据库变更数据到缓存）*/@Scheduled(fixedRate = 30000) // 30秒执行一次public void syncDbToCache() {// 模拟查询数据库变更数据（如最近30秒更新的数据）List<DataDTO> updateDataList = dbDao.queryUpdateDataIn30s();for (DataDTO data : updateDataList) {String cacheKey = "cache:core:" + data.getId();// 同步更新缓存stringRedisTemplate.opsForValue().set(cacheKey, data.getContent(), 600, TimeUnit.SECONDS);}System.out.println("定时同步完成，更新数据" + updateDataList.size() + "条");}/*** 读请求直接查询缓存（无需穿透数据库）*/public String readFromCache(String cacheKey) {return stringRedisTemplate.opsForValue().get(cacheKey);}// 模拟DAO层public static class DbDao {// 模拟查询所有核心数据public List<DataDTO> queryAllCoreData() {// 实际场景中从数据库查询return List.of(new DataDTO(1L, "核心数据1"), new DataDTO(2L, "核心数据2"));}// 模拟查询最近30秒变更的数据public List<DataDTO> queryUpdateDataIn30s() {// 实际场景中通过时间戳、变更日志查询return List.of(new DataDTO(1L, "核心数据1（更新后）"));}}// 模拟数据DTOpublic static class DataDTO {private Long id;private String content;public DataDTO(Long id, String content) {this.id = id;this.content = content;}// getterpublic Long getId() { return id; }public String getContent() { return content; }}
}

3.3 方案优缺点

优点：读请求无需穿透数据库，性能极高；定时同步缩小不一致窗口，数据实时性较好；避免高并发穿透，保护数据库。
缺点：定时同步存在延迟（如30秒延迟），无法实现强一致性；缓存预热需占用系统启动时间，不适用于数据量极大的场景；需维护变更日志或时间戳，增加开发成本。

3.4 适用场景

核心数据查询、高频访问且数据变更不频繁的场景（如首页推荐数据、热门商品列表），对读数据实时性要求较高（允许秒级到分钟级延迟）。

三、写操作一致性保证方案（核心：避免读写时序导致的分歧）

写操作的核心需求是「确保数据库与缓存的数据同步」，核心矛盾是「先更缓存还是先更数据库」，以下是4种主流方案，按一致性强度、实现复杂度排序。

方案1：先更新数据库，再删除缓存（Cache-Aside Pattern，推荐基础方案）

1.1 核心逻辑

最常用、最易实现的写操作一致性方案，遵循「先更库，再删缓存」的时序，核心思路：数据库更新成功后，删除对应缓存，后续读请求会从数据库查询最新数据并重新加载缓存，保证最终一致性。

核心流程：写请求 → 开启事务 → 更新数据库 → 事务提交 → 删除Redis缓存 → 写操作完成；若数据库更新失败，事务回滚，不操作缓存，避免数据分歧。

1.2 关键优化（避免缓存删除失败）

若数据库更新成功，但缓存删除失败（如网络中断、Redis宕机），会导致数据库存新数据、缓存存旧数据，需通过「重试机制」兜底：

本地重试：删除缓存失败后，重试1-3次，间隔100ms，避免瞬时网络问题；
消息队列重试：若本地重试失败，将删除缓存的任务放入消息队列，异步重试，确保最终删除成功；
缓存过期兜底：给缓存设置合理的过期时间，即使删除失败，缓存过期后也会重新加载最新数据。

1.3 Java代码实现（Spring Boot + 事务 + 重试）

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.util.concurrent.TimeUnit;@Service
public class WriteWithDeleteCacheService {private final StringRedisTemplate stringRedisTemplate;private final DbDao dbDao;public WriteWithDeleteCacheService(StringRedisTemplate stringRedisTemplate, DbDao dbDao) {this.stringRedisTemplate = stringRedisTemplate;this.dbDao = dbDao;}/*** 先更新数据库，再删除缓存（带重试机制）* @param dataId 数据ID* @param newContent 新数据内容* @return 操作结果*/@Transactional(rollbackFor = Exception.class)public boolean updateDbThenDeleteCache(Long dataId, String newContent) {// 1. 更新数据库（事务管理，失败回滚）boolean dbUpdateSuccess = dbDao.updateData(dataId, newContent);if (!dbUpdateSuccess) {return false;}// 2. 删除对应缓存（带重试）String cacheKey = "cache:data:" + dataId;boolean deleteSuccess = deleteCacheWithRetry(cacheKey, 3, 100); // 重试3次，间隔100ms// 3. 若删除失败，可放入消息队列异步重试（此处简化，实际需集成MQ）if (!deleteSuccess) {System.out.println("缓存删除失败，放入消息队列异步重试");// mqTemplate.send("cache-delete-retry", cacheKey);}return true;}/*** 缓存删除重试机制* @param cacheKey 缓存key* @param retryCount 重试次数* @param interval 重试间隔（ms）* @return 删除是否成功*/private boolean deleteCacheWithRetry(String cacheKey, int retryCount, long interval) {for (int i = 0; i < retryCount; i++) {try {stringRedisTemplate.delete(cacheKey);return true;} catch (Exception e) {System.err.println("第" + (i+1) + "次删除缓存失败，原因：" + e.getMessage());try {Thread.sleep(interval);} catch (InterruptedException ex) {Thread.currentThread().interrupt();}}}return false;}// 模拟DAO层public static class DbDao {public boolean updateData(Long dataId, String newContent) {// 实际场景中执行数据库更新操作System.out.println("数据库更新成功，数据ID：" + dataId + "，新内容：" + newContent);return true;}}
}

1.4 方案优缺点

优点：实现简单、性能损耗低，无需复杂的分布式协调；事务保证数据库更新的原子性，删除缓存兜底机制完善，适配大部分写场景；最终一致性有保障。
缺点：存在短暂不一致窗口（数据库更新后、缓存删除前，读请求会获取旧数据）；缓存删除失败可能导致长时间不一致（需依赖重试和过期机制）。

1.5 适用场景

绝大多数业务场景（如商品库存更新、用户信息修改），对一致性要求为最终一致，无需强实时同步。

方案2：先删除缓存，再更新数据库（适用于写多读少场景）

2.1 核心逻辑

与方案1时序相反，先删除缓存，再更新数据库，核心思路：删除缓存后，读请求会穿透到数据库，获取最新更新后的数据并加载缓存，避免「先更库、再删缓存」的短暂旧数据窗口。

核心流程：写请求 → 删除Redis缓存 → 开启事务 → 更新数据库 → 事务提交 → 写操作完成；若数据库更新失败，事务回滚，无需恢复缓存（后续读请求会重新加载旧数据，避免脏数据）。

2.2 关键优化（避免缓存穿透）

先删除缓存后，若数据库更新耗时较长，高并发读请求会大量穿透到数据库，导致数据库压力激增，需通过「分布式锁」拦截：

写操作删除缓存后，加Redis分布式锁；读请求缓存未命中时，先获取锁，再查库、更缓存，确保同一时刻只有一个读请求穿透到数据库，避免数据库雪崩。

2.3 方案优缺点

优点：无「旧数据窗口」，更新后读请求不会获取旧数据；数据库更新失败无需处理缓存，避免脏数据。
缺点：写操作后，读请求会短暂穿透到数据库，需加锁保护，性能损耗高于方案1；写多读少场景下，穿透频率低，适配性较好。

2.4 适用场景

写多读少场景（如后台数据录入、日志更新），对读数据实时性要求较高，允许短暂读请求穿透的场景。

方案3：数据库事务+缓存更新（强一致性方案，适用于核心场景）

3.1 核心逻辑

通过「数据库事务+缓存更新原子性」实现强一致性，核心思路：将缓存更新与数据库更新纳入同一事务（或通过分布式事务协调），确保两者同时成功或同时失败，避免数据分歧。

核心实现：使用Spring事务的「afterCommit」回调（数据库事务提交后，再执行缓存更新），或使用分布式事务框架（如Seata），确保缓存更新与数据库更新的原子性。

3.2 Java代码实现（Spring事务+afterCommit回调）

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionSynchronization;
import org.springframework.transaction.support.TransactionSynchronizationManager;
import java.util.concurrent.TimeUnit;@Service
public class StrongConsistencyService {private final StringRedisTemplate stringRedisTemplate;private final DbDao dbDao;public StrongConsistencyService(StringRedisTemplate stringRedisTemplate, DbDao dbDao) {this.stringRedisTemplate = stringRedisTemplate;this.dbDao = dbDao;}/*** 数据库事务+缓存更新，实现强一致性* 思路：数据库事务提交后，异步更新缓存，确保两者原子性*/@Transactional(rollbackFor = Exception.class)public boolean updateWithStrongConsistency(Long dataId, String newContent) {// 1. 更新数据库boolean dbUpdateSuccess = dbDao.updateData(dataId, newContent);if (!dbUpdateSuccess) {return false;}// 2. 注册事务回调：事务提交后，异步更新缓存TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {@Overridepublic void afterCommit() {// 异步更新缓存（避免阻塞主事务）updateCacheAsync(dataId, newContent);}});return true;}/*** 异步更新缓存*/@Async // 需开启Spring异步注解（@EnableAsync）public void updateCacheAsync(Long dataId, String newContent) {String cacheKey = "cache:data:" + dataId;stringRedisTemplate.opsForValue().set(cacheKey, newContent, 300, TimeUnit.SECONDS);System.out.println("缓存异步更新成功，数据ID：" + dataId);}// 模拟DAO层public static class DbDao {public boolean updateData(Long dataId, String newContent) {System.out.println("数据库更新成功，数据ID：" + dataId + "，新内容：" + newContent);return true;}}
}

3.3 方案优缺点

优点：强一致性，确保数据库与缓存同时成功或同时失败，无数据分歧；异步更新缓存，不阻塞主事务，性能影响较小。
缺点：实现复杂，需依赖事务回调或分布式事务框架；分布式事务会增加系统复杂度和性能损耗；仅适用于核心场景。

3.4 适用场景

金融、支付、订单等核心业务场景，对数据一致性要求极高（不允许任何不一致），可接受一定性能损耗。

方案4：Canal监听binlog同步（高可用、低耦合方案）

4.1 核心逻辑

通过Canal监听数据库binlog日志，捕捉数据库的更新、删除、插入操作，异步同步到Redis缓存，实现缓存与数据库的一致性，核心思路：无需在业务代码中操作缓存，解耦业务与缓存同步逻辑，提升系统可用性。

核心流程：写请求 → 更新数据库 → 数据库生成binlog日志 → Canal监听binlog → 解析日志获取变更数据 → 异步更新/删除Redis缓存 → 完成一致性同步。

4.2 核心实现步骤

部署Canal服务，配置监听目标数据库的binlog日志（开启数据库binlog，设置为row模式）；
开发Canal客户端，监听Canal服务推送的binlog变更事件；
解析变更事件（获取表名、操作类型、变更数据），根据业务规则生成Redis缓存key；
异步更新/删除Redis缓存，实现缓存与数据库的同步。

4.3 方案优缺点

优点：业务代码与缓存同步解耦，无需在写操作中处理缓存；异步同步，不影响业务接口性能；高可用，Canal支持集群部署，避免单点故障；一致性窗口小（binlog同步延迟通常在毫秒级）。
缺点：部署和维护成本高（需部署Canal服务、客户端）；binlog解析复杂，需适配不同数据库（MySQL、PostgreSQL）；存在微小延迟（毫秒级），无法实现绝对强一致性。

4.4 适用场景

大型分布式系统、高并发读写场景，需要解耦业务与缓存同步，追求高可用和低耦合的场景（如电商平台、用户中心）。

四、混合场景一致性保证（读写结合）

实际生产中，读写操作是混合进行的，需结合读、写方案，形成完整的一致性保障体系，推荐「通用混合方案」如下：

读操作：采用「缓存优先+双重校验+Redis分布式锁」（方案2），避免分布式穿透和脏数据；
写操作：采用「先更新数据库，再删除缓存+重试机制」（方案1），保证最终一致性；
兜底机制：给所有缓存设置合理的过期时间（根据业务场景设30秒-1小时），即使缓存删除/更新失败，也能通过过期重新加载最新数据；
监控告警：监控Redis缓存命中率、缓存与数据库数据差异，当差异超过阈值或命中率过低时，及时告警排查。

五、常见问题与解决方案

5.1 缓存穿透导致的一致性问题

问题：缓存未命中、数据库也无对应数据，高并发请求持续穿透数据库，同时可能写入空缓存，导致后续请求获取空数据。

解决方案：缓存空值（数据库无数据时，缓存空字符串或特定标识，设置短期过期时间，如10秒）；结合布隆过滤器，提前拦截不存在的key，避免穿透。

5.2 缓存雪崩导致的一致性问题

问题：大量缓存同时过期或被淘汰，高并发读请求穿透到数据库，导致数据库宕机，进而无法更新缓存，出现大面积数据不一致。

解决方案：缓存过期时间加随机值（如300±50秒），避免同时过期；采用Redis集群，避免单点故障；核心数据缓存永久有效，结合定时同步更新。

5.3 主从架构下的一致性问题

问题：数据库主从同步延迟，写操作更新主库后，缓存更新基于主库数据，读请求从从库查询，出现主从数据不一致，进而导致缓存与从库数据不一致。

解决方案：写操作完成后，等待主从同步完成再更新缓存；读操作优先从主库查询（核心场景）；Canal监听主库binlog，同步更新缓存，避免依赖从库数据。

六、方案选型建议

业务场景	一致性要求	推荐方案
普通读多写少（如商品详情、用户信息）	最终一致（允许秒级延迟）	读：缓存优先+双重校验；写：先更库再删缓存+重试
分布式高并发读（如秒杀、热门接口）	最终一致（避免穿透）	读：缓存+Redis分布式锁；写：先更库再删缓存+消息队列重试
写多读少（如后台录入、日志更新）	最终一致（避免旧数据）	读：缓存优先；写：先删缓存再更库+分布式锁
核心业务（金融、支付、订单）	强一致（不允许分歧）	数据库事务+缓存更新回调；或Canal监听binlog
大型分布式系统（高可用、低耦合）	最终一致（低延迟）	Canal监听binlog同步；读：缓存优先+双重校验