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节点成为性能瓶颈时、读写分离版本有热写瓶时以及同步延迟等问题时。