Redis 是目前最流行的KV缓存数据库,它简单易用,安全稳定,在互联网行业有着非常广泛的应用。
本文主要给大家分享一下 Redis 在单数据多源超高并发访问下的解决思路和方案。
前言
Redis 主要解决两个问题:
当遇到日活千万,同时百万在线的业务场景时,前端访问直接加载到后台数据库的话,可能顺间压垮底层数据库,导致业务停摆。又或者随着查询条件变多,结合条件复杂化,查询结果的响应时间也无法得到保证,导致用户体验下降,用户流失。为了解决高并发,低延迟的业务场景, Redis 应运而生。
下面我们来看两个场景
这是一个线上找房的业务场景,超多的查询条件导致后台必然是一个复杂的查询 SQL,这种场景下是否必须使用 Redis 呢?
答案是否定的,由于线上找房业务并发量低,客户对于业务响应时间要求也没有那么苛刻,大部分的请求可以直接通过动态 SQL 临时查询。当然为了提升用户体验,可以将一些热点的查询结果预缓存到 Redis 里提升用户体验。
我们再来看下这个场景
视频应用的查片系统,跟找房系统几乎是一模一样的业务场景,但是并发量要高几个数量级,这个场景就非常适合使用 Redis 作为缓存提升并发访问量,降低响应时间,满足几十万甚至上百万的并发访问需求。由此可见决定是否使用 Redis 的根本要素就是并发量和延迟要求。
下面我们来看一下 Redis 是如何解决互联网极端场景下的并发访问需求的。
超高并发访问下的缓存解决方案
这是一个典型的媒体类缓存架构图,发文系统不定期更新媒体库,通过分布式缓存服务将各个最新文章同步到 Redis 缓存,前端应用通过路由层找到相应的数据源访问。各个缓存服务数据不同步。当发生热点事件时,路由层可能将不通地区的访问路由到热点数据所在的缓存服务器,带来瞬间的流量暴涨,极端情况下可能导致服务器宕机,业务受损。那么这种不定期突发流量的场景要如何解决呢?
这里有几个思路:
将热点 Key 加前缀打散,实现热数据复制
路由层追加本地缓存,通过多级缓存提升缓存能力
缓存层提供数据副本,提高并发访问能力
第一种方案,可以有效打散热数据,但是热点事件是不定期随机发生,运维压力大,成本高,这只是个头痛医头脚痛医脚的方案。
第二种方案,可以通过追加本地缓存提升缓存能力,但是本地缓存设置多大,刷新频率多高,业务是否能容忍脏读,这些都是无法绕开的问题。
第三种方案,可以追加只读副本来实现数据的复制,但是同样也会带来成本高企,主库负载高等问题。
上面这个架构图是一个优化的解决方案,通过主库拉取多个只读从库的分支,对不同的请求源,划分独立的缓存服务。比如手机应用就固定路由到APP数据资源组,WEB 访问就路由到WEB 数据资源组等,并且每个资源组可以提供N个只读副本,提高同源访问下的并发访问能力。这种架构可以提升不同访问源的资源隔离能力,提升多源访问下业务的稳定性和可用性。
这个方案的问题也比较明显:
主库读写性能差
只读副本多,成本高
只读链路过长,管理维护难,运维成本高
我们的客户里最夸张的用到过 1主40只读的架构,来满足类似的业务场景。
阿里云Redis是如何解决这种超高并发访问的问题呢?
阿里云重磅推出Redis性能增强版本,通过提升网络IO的并发处理能力,极大的提升了Redis单节点的读写性能,对比社区版本,性能提升3倍。由于保持单 Worker 的处理模式,100% 兼容 Redis 协议。上面的单数据百万QPS 的访问能力轻松达成。本文介绍的媒体类场景可以通过开通性能增强版1主5只读实例实现单数据200w+ QPS,有效缓解突发热点事件带来的流量激增,超高并发访问等行业痛点问题。相比较自建1主40只读的社区版本,同样性能标准的阿里云Redis性能增强版1主5只读架构更稳定,管理更便捷,使用也更方便。
以上就是Redis 单数据多源超高并发下的解决方案的详细内容,更多请关注php中文网其它相关文章!
已抢17082个
抢已抢50043个
抢已抢184337个
抢已抢66166个
抢已抢350551个
抢已抢664477个
抢