20w 的 QPS 的场景下，服务端架构应如何设计？
可使用分布式缓存来抗，比如 redis 集群，6 主 6 从，主提供读写，从作为备，不提供读写服务。1 台平均抗 3w 并发，还可以抗住，如果 QPS 达到 100w,通过增加 redis 集群中的机器数量，可以扩展缓存的容量和并发读写能力。同时，缓存数据对于应用来讲都是共享的，主从架构，实现高可用。
但是如果出现缓存热点，比如 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 实现。
作者：京东科技 张石磊
来源：京东云开发者社区
