Redis 单数据多源超高并发下的解决方案
本文主要给大家分享一下 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 单数据多源超高并发下的解决方案的详细内容，更多请关注其它相关文章！