服务端应用多级缓存架构方案
场景
- 20w的QPS的场景下，服务端架构应如何设计？
常规解决方案
- 可使用分布式缓存来抗，比如redis集群，6主6从，主提供读写，从作为备，不提供读写服务。1台平均抗3w并发，还可以抗住，如果QPS达到100w,通过增加redis集群中的机器数量，可以扩展缓存的容量和并发读写能力。同时，缓存数据对于应用来讲都是共享的，主从架构，实现高可用。
如何解决缓存热点（热key）问题
- 但是如果出现缓存热点，比如10w流量来自同一个key，打到同一个redis实例，那么就有可能出现CPU被打满，这种增加redis集群数量解决不了问题。
- 本地缓存可以解决热key问题，主要原因是本地缓存可以避免redis单台缓存服务器的高负载。通过复制多份缓存副本，将请求分散到多个缓存服务器上，可以减轻缓存热点导致的单台缓存服务器压力。此外，本地内存缓存也具有更快的访问速度，因为数据存储在应用程序的内存中，无需跨网络传输数据。
通用多级缓存方案
- 请求优先打到应用本地缓存，本地缓存不存在，再去r2m(redis)集群拉取，同时缓存到本地
多级缓存同步方案
- 运营后台保存数据，写入r2m缓存，同时通过redis的发布订阅功能发布消息
- 本地应用集群作为消息订阅者，接受消息后，删除本地缓存，C端流量请求打过来的时候，如果本地缓存不存在，则将r2m中缓存加载到本地缓存。
- 定时任务是防止极端情况下，r2m缓存失效，将数据重新加载到r2m缓存。
缓存同步组件选型
- 采用redis的发布订阅。
- Redis的发布订阅模式是推模式。在Redis中，SUBSCRIBE命令用于订阅一个或多个频道，以便在有消息发布到这些频道时接收通知。PUBLISH命令用于向一个或多个频道发布消息。当有消息发布到某个频道时，所有订阅该频道的客户端都会收到该消息。在推模式下，每个频道维护一个客户端列表，发送消息时遍历该列表将消息推送给所有订阅者。拉模式则相反，发送者将消息放到一个邮箱中，所有订阅这个邮箱的客户端可以在任意时刻去收取。确保所有客户端都成功收取完整的邮件后，才删除该邮件。
- Redis的发布订阅是异步的。当有消息发布到某个频道时，Redis会异步地将消息推送给所有订阅该频道的客户端。这意味着，客户端不会阻塞等待消息，而是继续执行其他任务，直到需要接收消息时才会去获取。这种异步方式可以提高系统的并发性和效率。
使用本地缓存注意事项
- 本地缓存占用java进程的jvm内存空间，故不能进行大数据量存储，需要进行缓存大小评估。
- 业务能接受短暂数据的不一致，更适用于读场景。
- 缓存更新策略，主动更新和被动更新，本地缓存一定要设置有效期
- 定时任务同步缓存机制，根据业务情况考虑极端情况数据丢失
- rpc调用避免本地缓存污染，可通过深拷贝解决。
- 本地缓存随着应用重启而失效，注意加载分布式缓存时机
- redis的pub,sub模式更新缓存策略（删除本地缓存key，避免在pub,sub模式下传递大value,pub,sub模式不会持久化消息数据，导致消费者对应redis的缓冲区超限，从而导致数据丢失）,本地缓存失效时，加锁synchronized，由一个线程加载r2m缓存，避免并发更新。
