缓存关于缓存的一些使用场景及建议
Posted zhaochunxue
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了缓存关于缓存的一些使用场景及建议相关的知识,希望对你有一定的参考价值。
缓存,是互联网分层架构中,非常重要的一个部分,通常用它来降低数据库压力,提升系统整体性能,缩短访问时间。
有架构师说“缓存是万金油,哪里有问题,加个缓存,就能优化”,缓存的滥用,可能会导致一些错误用法。
缓存,你真的用对了么?
一、以下介绍几种缓存误用的场景:
1、把缓存作为服务与服务之间传递数据的媒介
- 如上图:
服务1和服务2约定好key和value,通过缓存传递数据;服务1将数据写入缓存,服务2从缓存读取数据,达到两个服务通信的目的; - 存在的问题:
1、数据管道,数据通知场景,MQ更加适合
(1)MQ是互联网常见的逻辑解耦,物理解耦组件,支持1对1,1对多各种模式,非常成熟的数据通道,而cache反而会将service-A/B/C/D耦合在一起,大家要彼此协同约定key的格式,ip地址等
(2)MQ能够支持push,而cache只能拉取,不实时,有时延
(3)MQ天然支持集群,支持高可用,而cache未必
(4)MQ能支持数据落地,cache具备将数据存在内存里,具有“易失”性,当然,有些cache支持落地,但互联网技术选型的原则是,让专业的软件干专业的事情:nginx做反向代理,db做固化,cache做缓存,mq做通道
2、多个服务关联同一个缓存实例,会导致服务耦合
(1)大家要彼此协同约定key的格式,ip地址等,耦合
(2)约定好同一个key,可能会产生数据覆盖,导致数据不一致
(3)不同服务业务模式,数据量,并发量不一样,会因为一个cache相互影响,例如service-A数据量大,占用了cache的绝大部分内存,会导致service-B的热数据全部被挤出cache,导致cache失效;又例如service-A并发量高,占用了cache的绝大部分连接,会导致service-B拿不到cache的连接,从而服务异常
2、使用缓存未考虑雪崩
- 如上图:
常规的缓存玩法,服务先读缓存,缓存命中则返回缓存不命中,再读数据库 - 存在的问题:
1.如果缓存挂掉,所有的请求会压到数据库,如果未提前做容量预估,可能会把数据库压垮(在缓存恢复之前,数据库可能一直都起不来),导致系统整体不可服务。 - 如何解决:
1.提前做容量预估,如果缓存挂掉,数据库仍能扛住,才能执行上述方案;
2.保证缓存高可用性:
(1)使用高可用缓存集群,保证redis不会轻易挂掉;
(2)缓存水平切分,保证部分redis出问题不会将流量压力全部打回到数据库;
以上是关于缓存关于缓存的一些使用场景及建议的主要内容,如果未能解决你的问题,请参考以下文章
JAVA目前比较常用的缓存都有哪些? 集中式缓存与分布式缓存有何区别? 它们应用场景是?