1、背景

现有的业务场景下，都会涉及到数据库以及缓存双写的问题，⽆论是先删除缓存，再更新数据，或者先更新数据，再删除缓存，都⽆法保证数据的⼀致性。本身他们就不是⼀个数据源，⽆法通过代码上的谁先谁后去保证顺序

2、数据⼀致性⽅案设计

⾸先我们对于所有的DB操作都不去添加具体的删除缓存的操作，⽽是通过canal监听binlog的⽅式，待数据确认已提交到数据库后，通过监听的变化，解析出对应的数据后，过滤掉⾮增删改的binlog，然后通过常量类配置的需要处理数据⼀致性的相关表以及关键字段和缓存前缀key，进⾏组装出需要进⾏删除的缓存key。并且通过mq的ack机制来保证 缓存⼀定会被删除掉。

3、数据⼀致性⽅案流程图

4、关键代码

4.1、 处理数据⼀致性的消息队列⼊⼝

@Slf4j
@Component
public class CookbookConsistencyListener implements
MessageListenerConcurrently {
@Autowired
private RedisCache redisCache;
/**
* 处理mysql的binlog变化，处理对应的需要清理的缓存key
* @param list
* @param consumeConcurrentlyContext
* @return
*/
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> list,
ConsumeConcurrentlyContext consumeConcurrentlyContext) {
try {
for (MessageExt messageExt : list) {
String msg = new String(messageExt.getBody());
// 解析binlog数据模型，并过滤掉查询
BinlogDataDTO binlogData = buildBinlogData(msg);
// 获取binlog的模型，获取本次变化的表名称，在本地配置常量类⾥⾯匹配对
应的缓存key前缀以及缓存标识字段，⾮配置的表不进⾏处理
String cacheKey = filterConsistencyTable(binlogData);
// 删除该key的缓存
deleteCacheKey(cacheKey);
}
} catch (Exception e) {
log.error("consume error, 缓存清理失败", e);
// 本次消费失败，下次重新消费
return ConsumeConcurrentlyStatus.RECONSUME_LATER;
}
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
}

4.2、数据⼀致性配置的常量信息

public enum ConsistencyTableEnum {
/**
* 商品表缓存配置
*/
SKU_INFO ("sku_info", RedisKeyConstants.GOODS_INFO_PREFIX,"id");
/**
* 配置相关的表名称
*/
private final String tableName;
/**
* 缓存的前缀key
*/
private final String cacheKey;
/**
* 缓存的标识字段
*/
private final String cacheField;
}