把全量的数据都放在 Redis 集群里面，处理读请求的时候，干脆只读 Redis，不去读数据库。这样就完全没有“缓存穿透”的风险了。
数据库和缓存同步
- 启动一个更新缓存的服务，接收数据库变更的 MQ 消息，然后更新 Redis 中缓存的数据。
唯一需要担心的一个问题是，如果丢消息了怎么办？因为现在消息是缓存数据的唯一来源，一旦出现丢消息，缓存里缺失的那条数据永远不会被补上。所以，必须保证整个消息链条的可靠性，不过好在现在的 MQ 集群，比如像 Kafka 或者 RocketMQ，它都有高可用和高可靠的保证机制，只要你正确配置好，是可以满足数据可靠性要求的。
- 使用 Binlog 实时更新 Redis 缓存
数据更新服务只负责处理业务逻辑，更新 MySQL，完全不用管如何去更新缓存。负责更新缓存的服务，把自己伪装成一个 MySQL 的从节点，从 MySQL 接收 Binlog，解析 Binlog 之后，可以得到实时的数据变更信息，然后根据这个变更信息去更新 Redis 缓存。
在整个缓存更新链路上，减少了一个收发 MQ 的环节，从 MySQL 更新到 Redis 更新的时延更短，出现故障的可能性也更低，所以很多大厂更青睐于这种方案。
缺点：解析binlog比较复杂
开源方案：canal
写不放在Redis中有几个原因：
- Redis不是可靠的存储，存在丢数据的风险；
- Redis不支持事务；
- Redis的查询能力太弱，没法满足各种各样的业务需求。
此文章为3月Day17学习笔记，内容来源于极客时间《后端存储实战课》
