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 实现。
作者:京东科技 张石磊
来源:京东云开发者社区