电商总结(七)缓存系统

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

 

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

 

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

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

  还有就是,缓存数据如果没有失效的话,是会一直保持在内存中的,所以对服务器的内存也是负担,那么什么数据可以放缓存,什么数据不可以,这是系统设计之初必须考虑的问题。

 

  什么数据可以放缓存?

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

    2,需要实时更新,但是数据更新的频率不高的数据。

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

 

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

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

 

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

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

 

  说一说我们的缓存方案:

    我们目前的缓存系统:Redis(主从)+ RabbitMQ + 缓存清理服务组成,具体如下图:

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

   

 

 

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