【缓存】关于缓存的一些使用场景及建议

标签：取数据   mic   loading   不同   通过   mamicode   导致   软件   通知   

缓存，是互联网分层架构中，非常重要的一个部分，通常用它来降低数据库压力，提升系统整体性能，缩短访问时间。
有架构师说“缓存是万金油，哪里有问题，加个缓存，就能优化”，缓存的滥用，可能会导致一些错误用法。
缓存，你真的用对了么？

一、以下介绍几种缓存误用的场景：

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出问题不会将流量压力全部打回到数据库；

【缓存】关于缓存的一些使用场景及建议

标签：取数据   mic   loading   不同   通过   mamicode   导致   软件   通知   

原文地址：https://www.cnblogs.com/zhaochunxue/p/13287744.html