服务端应用多级缓存架构方案-Toy模板网

这篇具有很好参考价值的文章主要介绍了服务端应用多级缓存架构方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一：场景

20w的QPS的场景下，服务端架构应如何设计？

二：常规解决方案

可使用分布式缓存来抗，比如redis集群，6主6从，主提供读写，从作为备，不提供读写服务。1台平均抗3w并发，还可以抗住，如果QPS达到100w,通过增加redis集群中的机器数量，可以扩展缓存的容量和并发读写能力。同时，缓存数据对于应用来讲都是共享的，主从架构，实现高可用。

三：如何解决缓存热点（热key）问题

但是如果出现缓存热点，比如10w流量来自同一个key，打到同一个redis实例，那么就有可能出现CPU被打满，这种增加redis集群数量解决不了问题。

本地缓存可以解决热key问题，主要原因是本地缓存可以避免redis单台缓存服务器的高负载。通过复制多份缓存副本，将请求分散到多个缓存服务器上，可以减轻缓存热点导致的单台缓存服务器压力。此外，本地内存缓存也具有更快的访问速度，因为数据存储在应用程序的内存中，无需跨网络传输数据。

四：通用多级缓存方案

请求优先打到应用本地缓存，本地缓存不存在，再去r2m(redis)集群拉取，同时缓存到本地

服务端应用多级缓存架构方案

五：多级缓存同步方案

1 运营后台保存数据，写入r2m缓存，同时通过redis的发布订阅功能发布消息

2 本地应用集群作为消息订阅者，接受消息后，删除本地缓存，C端流量请求打过来的时候，如果本地缓存不存在，则将r2m中缓存加载到本地缓存。

3 定时任务是防止极端情况下，r2m缓存失效，将数据重新加载到r2m缓存。

服务端应用多级缓存架构方案

六：缓存同步组件选型

采用redis的发布订阅。

Redis的发布订阅模式是推模式。在Redis中，SUBSCRIBE命令用于订阅一个或多个频道，以便在有消息发布到这些频道时接收通知。PUBLISH命令用于向一个或多个频道发布消息。当有消息发布到某个频道时，所有订阅该频道的客户端都会收到该消息。在推模式下，每个频道维护一个客户端列表，发送消息时遍历该列表将消息推送给所有订阅者。拉模式则相反，发送者将消息放到一个邮箱中，所有订阅这个邮箱的客户端可以在任意时刻去收取。确保所有客户端都成功收取完整的邮件后，才删除该邮件。

Redis的发布订阅是异步的。当有消息发布到某个频道时，Redis会异步地将消息推送给所有订阅该频道的客户端。这意味着，客户端不会阻塞等待消息，而是继续执行其他任务，直到需要接收消息时才会去获取。这种异步方式可以提高系统的并发性和效率。