前段时间，在和朋友讨论和研究缓存的使用，一直对缓存的使用搞的不太清楚，所以这次把和朋友讨论过缓存系统的设计的相关问题总结总结。

　　对于一个电商系统，缓存是重要组成部分，提升系统性能的主要方式之一就是缓存。它可以挡掉大部分的数据库访问的冲击，如果没有它，系统很可能会因为数据库不可用导致整个系统崩溃。

　　但是缓存带来了另外一些棘手的问题： 数据的一致性和实时性。

　　例如，数据库中的数据状态已经改变，但是在页面上看到的仍然是缓存的旧值，直到缓冲时间失效之后，才能重新更新缓存。这个问题怎么解决？

　　还有就是，缓存数据本身都是保持在内存中的，那么什么数据可以放缓存，什么数据不可以，这是系统设计之初必须考虑的问题。

　　什么数据可以放缓存？

　　　　1，不需要实时更新但是又极其消耗数据库的数据。比如网站首页的商品销售的排行榜，热搜商品等等，这些数据基本上都是一天统计一次，用户不会关注其是否是实时的。

　　　　2，需要实时更新，但是更新频率不高的数据。比如一个用户的订单列表，他肯定希望能够实时看到自己下的订单，但是大部分用户不会频繁下单（炒信用之类的除外）。

　　　　3，每次获取这些数据都经过复杂的处理逻辑，比如生成报表。

　　什么数据不应该使用缓存？

　　　　实际上，在电商系统中，大部分数据都是可以缓存的，不能使用缓存的数据很少。这类数据包括比如涉及到钱、密钥、业务关键性核心数据等。总之，如果你发现，系统里面的大部分数据都不能使用缓存，这说明架构本身出了问题。

　　如何解决一致性和实时性的问题？

　　　　保证一致性和实时性的办法就是：一旦数据库更新了，就必须把原来的缓存更新。

　　说一说我们的缓存方案：

　　　　我们目前的缓存系统：Redis（主从）+ RabbitMQ + 缓存清理服务组成，具体如下图：

　　　　缓存清理作业订阅 RabbitMQ消息队列，一有数据更新进入队列，就将数据重新更新到Redis缓存服务器。

　　　　当然，有些朋友的方案，是数据库更新完成之后，立马去更新相关缓存数据。这样就不需要MQ 和 缓存清理作业。不过，这同时也增加了系统的耦合性。具体得看自己的业务场景和平台大小。

电商总结（七）缓存系统