“百变”Redis带你见识不同场景下的产品技术架构

摘要: 2018飞天技术汇24期-云数据库Redis产品发布会,由阿里云数据库技术组技术专家王欢、怀听、梁盼分别带来以“Redis全球多活产品”、“Redis混合存储产品”、“Redis多线程性能增强版”为题的演讲,本文对Redis进行了简单的介绍,进而针对不同的应用场景研制出不同的产品,并对不同产品分别进行了详细地介绍。
2018飞天技术汇24期-云数据库Redis产品发布会,由阿里云数据库技术组技术专家王欢、怀听、梁盼分别带来以“Redis全球多活产品”、“Redis混合存储产品”、“Redis多线程性能增强版”为题的演讲。本文对Redis进行了简单的介绍,进而针对不同的应用场景研制出不同的产品,并对不同产品分别进行了详细地介绍。
Redis简介
Redis 是一个高性能的key-value数据库,Redis的优势有很多,例如,它的性能极高 ,Redis能读的速度是110000次/s,写的速度是81000次/s ;它具有丰富的数据类型,可支持二进制案例的 Strings、Lists、Hashes、Sets 及 Ordered Sets 数据类型操作;它的所有操作都是原子性的,意思就是要么成功执行要么失败完全不执行;它还具有丰富的特性, 即支持 publish/subscribe、通知、key过期等等特性。
Redis 与其他key - value 缓存产品有三个共同特点:一是Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用;二是Redis不仅仅支持简单的key-value类型的数据,同时还提供list、set、zset、hash等数据结构的存储;三是Redis支持数据的备份,即master-slave模式的数据备份。
Redis与其他key-value存储的不同点在于Redis有着更为复杂的数据结构并且提供对它们的原子性操作,这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员是透明的,无需进行额外的抽象。另外的一个不同点在于Redis在内存中运行时可以持久化到磁盘中,所以在对不同数据集进行高速读写时需要权衡内存,因为数据量不能大于硬件内存。因此,与磁盘上相同的复杂数据结构相比,在内存中操作起来更为简单,这样Redis可以做很多内部复杂性很强的事情。同时,在磁盘格式方面它们是紧凑以追加的方式产生的,因为他们并不需要进行随机访问。
Redis全球多活产品
Redis全球多活产品是指多个Redis实例分布在全球不同的区域,它是阿里云自研、基于云数据库Redis版(ApsaraDB for Redis)、100%兼容 Redis 协议的多活数据库系统。通过数据同步通道,把多个Redis实例组网成1个逻辑上的 Redis 多活实例,多活实例内的所有实例均可读写并保持实时数据同步。数据同步通道通过内网打通,具有高可靠、高安全、低延迟的特性。子实例间通过CRDT(Conflict-free Replicated Data Type)机制检测并解决数据冲突,保障数据最终一致性。Redis全球多活产品轻松支持异地多个站点同时对外提供服务的业务场景,助力企业快速复制阿里巴巴异地多活架构。
高可用架构演练之路
程序在运行过程中总会遇到各种各样的问题,例如程序bug、机器故障、机房断电起火故障等,业务上要求发生这些故障时要保证数据一致性和业务可用性,所以就有了架构演练之路,即单可用区-同城容灾-两地三中心-异地多活。
由于单可用区架构无法应对机房出现故障,就有了同城容灾的架构。同城容灾架构由于无法应对地域级别的问题,接着就有了两地三中心架构。由于许多金融业务要求数据存储在不同的地域中,同时对故障恢复时间有要求,因此两地三中心架构就在同城容灾基础上加了一个standby中心,但依旧存在几个缺陷,即冷备中心不工作,关键时刻不敢切的缺陷;冷备中心不工作,成本浪费的缺陷;本质上数据仍然单点写,数据库瓶颈无法解的缺陷;资源、容灾、扩展无法解决的缺陷。
后来有了异地多活架构,它是指所有的中心都提供业务服务,底层的数据能够相互同步,因此存在着许多优点,例如,所有中心工作,切换有保障;所有中心工作,成本低;弹性伸缩,增加/减少中心个数;故障独立性导致中心不可用时,只影响部分用户。
产品架构

异地多活产品架构图如上图所示,它是由云数据库Redis版实例、同步通道和通道管理器三部分组成。由于异地多活是由多个Redis实例组成,因此可以实现每个子实例之间实时数据同步、每个子实例数据最终一致、每个子实例均可读写等功能。
在异地多活构架中,对Redis进行了aof binlog增加oplog和CRDT策略merge key的改造,其中aof binlog增加oplog中包含gtid和逻辑时钟信息,解决了循环同步、Exactly-once Apply的问题;CRDT策略merge key中解决了一致性的问题。
异地多活产品具有高可用、高性能、数据最终一致以及功能丰富的特性,具体介绍如下:
● 高可用
高可用是指同步通道支持断点续传,它最高可容忍天级别的隔断,且隔断之后数据还可以在断点处继续同步;同时,同步通道还可以自适应处理子实例异常,例如主备切换、备库重搭等。
● 高性能
高性能是指它具有异步复制同步不影响Redis自身读写性能,因为它本身定位就具有高性能、高吞吐、低延迟的性能,高吞吐是指它具有标准版Redis使得单向同步链路高达10万TPS以及随Redis节点数线性扩展的集群版Redis。低延迟是指洲际内地域仅需百毫秒,更厉害的是跨洲际地域仅需 1秒级。
● 最终一致性
为了解决过去的架构由于异步同步的逻辑产生的一致性问题,最终引进了CRDT(Conflict-Free Replicated Data Types)策略,它可支持最终一致性的数据类型有 String/Counter、Hash、Set、Zset、Geo、hyperloglog等。
● 功能丰富
异地多活产品增加了支持 Redis 实例类型、同步中的子实例支持变配规格、新增与删除子实例等新功能,其中支持的 Redis 实例类型包括标准版、集群版以及读写分离版。
业务设计

异地多活业务具有不同的业务有不同的业务设计要求,它必须允许多个地域具有同时修改同一份数据的功能,例如全局session、全局PV、用户收藏夹、购物车、地理位置信息、收藏夹、历史搜索记录、弹幕、评论等。同时,它还需要做数据切分,要求一份数据只允许有1个写入点。
多活业务设计的要点有自包含性、松耦合性和路由规则一致性,即多活业务设计的所有计算与数据必须在1个中心内完成;跨单元之间只能进行服务调用,不能直接访问数据库或其他存储;路由必须是入口路由或者微服务调用路由。
Redis混合存储产品
Redis混合存储实例是阿里云自主研发的完全兼容Redis协议和特性的混合存储产品。通过将部分冷数据存储到磁盘,在保证绝大部分访问性能不下降的基础上,大大降低了用户成本,并突破了内存对Redis单实例数据量的限制。
技术架构

它的数据类型是将热数据存储在内存里,将冷数据存储在磁盘里面,顾名思义,热数据就是指频繁访问到的数据。因为所有的Redis都会访问到Keys,相对来说Keys的访问天生就比Values大许多,因此Redis混合存储产品是将所有的Keys、常访问的Values放到内存里存储,而不经常访问的Values放到磁盘里存储。在业务场景里面,Keys只占十几个字节,但Values却占几百甚至几千个字节,所以将所有的Keys放到内存里对整体性能能够提高很多。

Redis混合存储架构如上图所示,从业务模型来看,我们把Redis混合存储架构分为三层,第一层是计算层,它包含所有Redis的网络连接、协议解析、定时任务、命令处理、过期、淘汰、同步等业务逻辑;第二层是数据层,它包含热数据表示、冷热数据交换、冷数据编解码;第三层是存储层,它包含存储引擎、文件系统以及硬件管理。
其中,数据层进行冷热交换是为了保证兼容性,因为所有Redis的业务逻辑是采用主线程来处理的,所有实际的IO是由后台来运行的,进而也不会阻挡主线程的运行。在热数据转换成冷数据的过程中,数据量小于内存时,Redis混合存储会把所有的Keys和Values放到内存里面,这样可以达到性能最高。当数据量越来越大时,内存里会出现存不下的现象,这时会按照最近的访问频率筛选出一些很少被访问到的Values,然后由主线程生成IO任务,接着后台的IO线程拿到这些任务存储到磁盘中,最后主线会将这些Values释放掉。在冷数据转换成热数据的过程中,收到用户请求后,首先判断任务请求会访问到哪些Values,然后看这些Values是否都在内存里面,如果部分Values不在,会对这些Values生成IO任务,然后主线程将客户端挂起,接着继续处理其它客户端的请求,当此线程拿到这些任务后,会把数据从磁盘里面加载到内存里面,同时通知给主线程,主线程收到这些通知之后会将挂起的客户端唤醒继续处理其他用户请求。
对于存储层而言,磁盘上的存储是跟阿里巴巴的服务器研发团队共建的一个用户态的存储引擎,称为FusionEngine。它是由业务定制一个RocksDB,然后通过底层的一个用户固态的文件系统来缩短用户的IO路径,进而避免了内核的开销。在业务场景里面,FusionEngine的性能比过去的文件系统性能提升了约80%左右,因此整体的Redis混合存储性能也得到了有效的提升。
产品特性
Redis混合存储产品的底层实线是支持冷热数据任意配比的,即可以任意的匹配内存占用多少和磁盘占用多少,进而在性能和成本上达到一个平衡。在应用中,所有的数据量不能超过内存加磁盘的容量。此产品适用于Values比较大的场景,因为Values对性能的影响不是很大,所以也比较适合数据访问冷热不均的场景。目前混合存储开通的区域有华北2(北京)的可用区D、华东1(杭州)的可用区E、华南1(深圳)的可用区C。
应用场景
Redis混合存储产品应用的场景包含电商类应用、直播类应用、互联网类应用,对于电商类应用而言,它的活跃商品数据存放到内存中,冷门商品数据存放到磁盘中;对于直播类应用而言,它的活跃直播间和热门直播间的数据存放到内存中,下线直播间和冷门直播间的数据存放到磁盘中;对于互联网类应用而言,它的首页和热门贴数据存放到内存中,冷门帖子存放到磁盘中。
Redis多线程性能增强版
Redis多线程性能增强版突破了Redis单线程的性能瓶颈,且100%兼容原生Redis,业务无需修改任何代码。通过将命令解析,读写,响应等事件分发给多个IO线程并发处理,实现处理性能质的飞跃。
技术架构
原生的Redis是进行串行处理的,当它接收到一个请求时,会尝试连接读取到一部分数据,并对这部分数据进行解析,如果解析到一个完整的数据,就会对这个数据进行处理。当这个数据处理完之后,会生成对数据的一个响应,针对这个响应在发送给客户端。原生的Redis存在一个缺陷,就是不能做到并发。相对而言,Redis多线程做的一个Master-Slave架构就能够做到并发,它是将Master数据处理完之后,将数据同步到Slave上。

如上图所示,Redis多线程性能增强版是由主线程、多个IO线程和WORKER线程组成,主线程主要负责接受连接,创建client,将连接转发给IO线程。IO线程负责处理连接的读写事件,解析命令,将解析的完整命令转发给WORKER线程处理,发送response包,负责删除连接等;WORKER线程负责命令的处理,生成客户端回包,定时器事件的执行等。
在线程间数据在进行交换的过程中,一个IO线程在获取到连接之后,就开始尝试在这个连接上读取请求,然后对请求做一个解析,若解析到是一个完整的请求,就会将请求放到队列里面。接着,IO线程通知WORKER线程有新的命令需要处理,这个通知是通过管道来进行的。最后,WORKER线程接受到命令后就会对其进行处理,处理完之后会形成对命令的响应,并将响应放到队列里面,同样,WORKER线程也会通知IO线程。
产品特性

IO线程越多,Redis多线程的性能越好,但是IO线程与Redis多线程的性能并不是线性的,当IO线程达到一定的数量时,WORKER就会达到一个瓶颈。因此,IO线程最多支持多达6个,默认情况下只有一个IO线程。另外需要注意的是,线程数个数跟规格是绑定的,一旦选定实例创建完毕后无法动态修改,如需修改,就需要通过升级规格的方式完成。
Redis多线程并不是在所有的场景中都适用,Redis多线程只适用于主从版无法满足性能需求时、集群版shard节点成为性能瓶颈时、读写分离版本有热写瓶时以及同步延迟等问题时。
应用场景
Redis多线程性能增强版主要应用在电商类应用、直播类应用中,对于电商类应用而言,适用于秒杀场景和库存计数;对于直播类应用而言,主要适用于热点直播间和明星大V的直播。

原文链接

本文为云栖社区原创内容,未经允许不得转载。

原文地址:http://blog.51cto.com/13952056/2171800

时间: 2024-10-31 22:23:12

“百变”Redis带你见识不同场景下的产品技术架构的相关文章

亿级流量场景下,大型缓存架构的虚拟机环境搭建

---内容持续更新--- 小型电商: 静态模板是固定的 数据库中的数据全量喧嚷到模板中,下次请求来了直接返回,速度也很快: 当数据上亿的时候,如果模板改定,把这些所有的数据在mysql中渲染进模板,非常耗时,不现实: 大型电商: 缓存数据生产服务: 不需要再进行全量重新渲染,直接将最新的html模板推送到nginx服务器,请求过来后直接在nginx本地进行渲染进模板中返回请求: redis的重要性: 虚拟机环境设置一: 虚拟机中安装CentOS 启动一个virtual box虚拟机管理软件 使用

基于redis+lua实现高并发场景下的秒杀限流解决方案

转自:https://blog.csdn.net/zzaric/article/details/80641786 应用场景如下: 公司内有多个业务系统,由于业务系统内有向用户发送消息的服务,所以通过统一消息系统对外暴露微服务接口供外部业务系统调用,所有公司内业务系统的消息(短信,APP,微信)推送都由统一消息系统去推送,短信推送需要走外部短信通道商去发送短信,APP和微信走内部系统的push服务器,但是不管是短信通道商还是内部push服务器都会有每秒上限的控制.在这假设n/s条. 以下是统一消息

亿级流量场景下,大型缓存架构设计实现【3】---- 实现高可用

1.Hystrix是什么? 在分布式系统中,每个服务都可能会调用很多其他服务,被调用的那些服务就是依赖服务,有的时候某些依赖服务出现故障也是很正常的. Hystrix可以让我们在分布式系统中对服务间的调用进行控制,加入一些调用延迟或者依赖故障的容错机制. Hystrix通过将依赖服务进行资源隔离,进而组织某个依赖服务出现故障的时候,这种故障在整个系统所有的依赖服务调用中进行蔓延,同时Hystrix还提供故障时的fallback降级机制 总而言之,Hystrix通过这些方法帮助我们提升分布式系统的

互联网业务场景下消息队列架构

消息队列作为一种基础的抽象数据结构,被广泛应用在各类编程与系统设计中. 同步VS异步 通信的一个基本问题是:发出去的消息什么时候需要被接收到?这个问题引出了两个基础概念:"同步通信"和"异步通信".根据理论抽象模型,同步通信和异步通信最本质的差别来自于时钟机制的有无.同步通信的双方需要一个校准的时钟,异步通信的双方不需要时钟.现实的情况是,没有完全校准的时钟,所以没有绝对的同步通信.同样,绝对异步通信意味着无法控制一个发出去的消息被接收到的时间点,无期限的等待一个消

Redis高级特性及应用场景

Redis高级特性及应用场景 redis中键的生存时间(expire) redis中可以使用expire命令设置一个键的生存时间,到时间后redis会自动删除它. 过期时间可以设置为秒或者毫秒精度. 过期时间分辨率总是 1 毫秒. 过期信息被复制和持久化到磁盘,当 Redis 停止时时间仍然在计算 (也就是说 Redis 保存了过期时间). expire  设置生存时间(单位/秒) expire key seconds(秒) ttl 查看键的剩余生存时间 ttl key persist 取消生存

Redis 11种Web应用场景举例

在"怎样让redis在你的系统中发挥作用"一文中,salvatore 'antirez' sanfilippo告诉我们如何利用redis独有的数据结构处理能力来解决一些常见问题.一些redis原语命令比如lpush.ltrim和lrem等等能够用来帮助开发者完成需要的任务--这些任务在传统的数据库存储中非常困难或缓慢.这是一篇非常有用并且实际的文章.那么要如何在你的框架中完成这些任务呢? 下面列出11种web应用场景,在这些场景下可以充分的利用redis的特性,大大提高效率. 1.在主

NoSQL初探之人人都爱Redis:(3)使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时呢,也使响应延迟加剧.这也说明

使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 "消息"是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,"消息队列"是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时

【转】NoSQL初探之人人都爱Redis:(3)使用Redis作为消息队列服务场景应用案例

一.消息队列场景简介 “消息”是在两台计算机间传送的数据单位.消息可以非常简单,例如只包含文本字符串:也可以更复杂,可能包含嵌入对象.消息被发送到队列中,“消息队列”是在消息的传输过程中保存消息的容器. 在目前广泛的Web应用中,都会出现一种场景:在某一个时刻,网站会迎来一个用户请求的高峰期(比如:淘宝的双十一购物狂欢节,12306的春运抢票节等),一般的设计中,用户的请求都会被直接写入数据库或文件中,在高并发的情形下会对数据库服务器或文件服务器造成巨大的压力,同时呢,也使响应延迟加剧.这也说明