这篇文章主要介绍了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单数据多源超高并发下的解决方法内容对大家有帮助,同时也希望大家多多支持创新互联成都网站设计公司,关注创新互联成都网站设计公司行业资讯频道,遇到问题就找创新互联成都网站设计公司,详细的解决方法等着你来学习!
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、网站设计器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。