为什么需要缓存
存储如 mysql 通常支持完整的 ACID 特性，因为可靠性，持久性等因素，性能普遍不高，高并发的查询会给 mysql 带来压力，造成数据库系统的不稳定，同时也容易产生延迟。根据局部性原理，80% 请求会落到 20% 的热点数据上，在读多写少场景，增加一层缓存有助提升系统吞吐量和健壮性。
引入缓存后所出现的问题
存储的数据随着时间可能会发生变化，而缓存中的数据就会不一致。具体能容忍的不一致时间，需要具体业务具体分析，但是通常的业务，都需要做到最终一致。
Redis 作为 Mysql 缓存
在我个人接触的开发中，通常会使用 mysql 作为数据存储，而 redis 作为缓存，加速和保护mysql。但是，当 mysql 数据更新之后，就需要考虑 redis 怎样去保持数据的同步。强一致性同步维护成本太高，如果追求强一致，那么没必要用缓存了，直接用 mysql 即可。通常考虑的，都是最终一致性。
常用解决方案
方案一（缓存过期时间控制）
通过设置缓存key的过期时间，mysql 更新时，redis 不同步更新，延时更新。这种方式实现简单，需要根据不同的业务需求设置合理的过期时间，但并不能完全规避问题，如果在设置的过期时间范围内数据发生了更新，则会在此期间产生很多长期的脏数据。
优点：
- 开发成本低，易于实现；
- 维护管理成本低，出问题的概率会比较小。
缺点：
- 完全依赖过期时间，时间太短缓存频繁失效，失去意义，时间过长易有长时间更新延迟（数据不一致）
方案二（同步更新缓存）
在方案一的基础上扩展，通过设置缓存key的过期时间兜底，并且，在更新 mysql 时，同时更新 redis。
优点：
- 相对方案一，更新延迟更小。
缺点：
- 如果更新 mysql 成功，更新 redis 却失败，就退化到了方案一；
- 增加耦合度，因同步更新 redis，造成业务与缓存代码的紧密耦合，如果因 redis 更新异常而导致正常业务不能进行则得不偿失。
- 在高并发场景，业务 server 需要和 mysql，redis 同时进行连接。这样是损耗双倍的连接资源，容易造成连接数过多的问题。
方案三（异步更新缓存）
针对方案二进行优化，引入中间件，如消息队列，将同步更新 redis 的方式改为异步更新。将 redis 更新操作交给消息队列去完成，完成业务和缓存操作代码的解耦，由消息队列保证可靠性，再搭建一个消费服务，来异步更新 redis。
优点：
引入消息队列中间件，实现了逻辑上的解耦；
消息队列可以用一个句柄，很多消息队列客户端还支持本地缓存发送，有效解决了方案二连接数过多的问题；
消息队列本身具有可靠性，通过手动提交等手段，可以至少一次消费到redis。
缺点：
- 依旧解决不了时序性问题，如果多台业务服务器分别处理针对同一行数据的两条请求，举个栗子，a = 1；a = 5;，如果mysql中是第一条先执行，而进入kafka的顺序是第二条先执行，那么数据就会产生不一致。
- 引入了消息队列中间件，增加了服务的复杂度，同时要增加服务来消费消息，成本较高。
方案四（订阅 binlog 来更新 redis）
通过订阅 binlog 来更新 redis，把我们搭建的消费服务，作为 mysql 的一个slave，订阅 binlog，解析出更新内容，再更新到 redis。
优点：
- 在mysql压力不大情况下，延迟较低；
- 和业务完全解耦；
- 解决了时序性问题。
缺点：
- 要单独搭建一个同步服务，并且引入binlog同步机制，成本较大。
总结
方案选型
- 首先确认产品上对延迟性的要求，如果要求极高，且数据有可能变化，不建议用缓存。
- 通常来说，方案1就够了，因为能用缓存方案，通常是读多写少场景，同时业务上对延迟具有一定的包容性。方案1没有开发成本，其实比较实用。
- 如果想增加更新时的即时性，就选择方案2，不过没必要做重试保证之类的。
- 方案3，方案4针对于对延时要求比较高业务，一个是推模式，一个是拉模式，而方案4具备更强的可靠性，既然都愿意花功夫做处理消息的逻辑，不如一步到位，用方案4。
小结
任何事物都存在多面性，缓存虽好但不是万能的，不能滥用。没有完美的方案，只有最适合的方案。不论在技术选型还是在架构设计上，都需要考虑实际业务场景和具体需求。那些看似高大上完美的方案，增加了项目的复杂度和维护难度的同时，也增加了开发难度和增大经费资源开销，并不是每个项目都适合。脱离实际纸上谈兵都是空谈。