共计 1358 个字符，预计需要花费 4 分钟才能阅读完成。
一：场景
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 实现。
作者：京东科技 张石磊
起源：京东云开发者社区