一：场景

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会异步地将音讯推送给所有订阅该频道的客户端。这意味着，客户端不会阻塞期待音讯，而是继续执行其余工作，直到须要接管音讯时才会去获取。这种异步形式能够进步零碎的并发性和效率。

七：应用本地缓存注意事项

1 本地缓存占用java过程的jvm内存空间，故不能进行大数据量存储，须要进行缓存大小评估。

2 业务能承受短暂数据的不统一，更实用于读场景。

3 缓存更新策略，被动更新和被动更新，本地缓存肯定要设置有效期

4 定时工作同步缓存机制，依据业务状况思考极其状况数据失落

5 rpc调用防止本地缓存净化，可通过深拷贝解决。

6 本地缓存随着利用重启而生效，留神加载分布式缓存机会

7 redis的pub,sub模式更新缓存策略（删除本地缓存key，防止在pub,sub模式下传递大value,pub,sub模式不会长久化音讯数据，导致消费者对应redis的缓冲区超限，从而导致数据失落）,本地缓存生效时，加锁synchronized，由一个线程加载r2m缓存，防止并发更新。

备注：r2m底层由redis实现。

作者：京东科技 张石磊

起源：京东云开发者社区