一般情况下,Redis用来实现应用和数据库之间读操作的缓存层,主要目的是减少数据库IO,还可以提升数据的IO性能。
Redis的整体架构是:当应用程序需要去读取某个数据的时候,首先会先尝试去Redis里面加载,如果命中就直接返回。如果没有命中,就从数据库查询,查询到数据后再把这个数据缓存到Redis里面。在这样一个架构中,会出现一个问题,就是一份数据同时保存在数据库和Redis里面,当数据发生变化的时候,需要同时更新Redis和Mysql,由于更新是有先后顺序的,并且它不像Mysql中的多表事务操作,可以满足ACID特性,所以就会出现数据一致性
问题。在这种情况下,能够选择的方法只有几种:
- 先更新数据库,再更新缓存。如果缓存更新失败,就会导致数据库和Redis中的数据不一致。
- 先删除缓存,再更新数据库。理想情况是应用下次访问Redis的时候,发现Redis里面的数据是空的,就从数据库加载保存到Redis里面,那么数据是一致的。但是在极端情况下,由于删除Redis和更新数据库这两个操作并不是原子的,所以这个过程如果有其他线程来访问,还是会存在数据不一致的问题。
- 如果需要在极端情况下仍然保证Redis和Mysql的数据一致性,就只能采用
最终一致性
方案。比如基于RocketMQ的可靠性消息通信,来实现最终一致性:1. 更新数据库的数据;2. 更新Redis的数据;3. 失败的请求写入MQ事务消息;4. 异步重试,确保成功。还可以直接通过Canal组件,监控Mysql中binlog日志,把更新后的数据同步到Redis里面。因为这里是基于最终一致性来实现的,如果业务场景不能接受数据的短期不一致,那就不能使用这个方案来做。