在Redis集群技术上，你不可错过的四大集成者

前阵子有幸现场聆听了云栖大会Redis专场的分享，可以说是不虚此行：会上见到了Redis之父Salvatore Sanfilippo，Redis labs CTO Yiftach Shoolman，Redisson 联合创始人 Jack Gu，Codis 作者王乃峥以及阿里云Redis团队的众多技术大牛。演讲的内容干货也很多，这里稍作总结跟大家分享。

一、阿里云ApsaraCache

先介绍一下阿里云开源的飞天缓存ApsaraCache项目(https://github.com/alibaba/ApsaraCache)，这是在社区2.8版基础上开始维护的分支，并backport了部分3.0分支的功能。

那与社区版Redis相比有哪些特点呢？阿里云技术专家白宸在演讲中做了很详细的介绍，先从架构上有一个整体的认识：

架构图

特点：

与Redis相比，ApsaraCache的显著特点是与场景有关，与数据规模无关。其技术特点和优势，主要表现在：

• 灾备深度加固，可以重构内核同步机制，解决了原生内核在弱网条件下容易复制中断导致的全量同步问题。（作者注：社区版2.8引入psync机制在一定程度上解决了类似问题）

• 兼容Memcached协议，能支持双副本的Memcached，数据可持久化，提供更可靠的Memcached服务。（作者注：Memcached是一种in-memory KV 存储，实例重启数据丢失，极容易导致“雪崩”）

• 短链接优化，使短链接场景下性能提升30%以上，对PHP短连接应用居多的应用提升效果明显。

• AOF强化，避免AOF Rewrite频繁造成的主机稳定性瓶颈，且能精确到秒级的按时间点恢复。（作者注：单机上部署多个实例如同时触发bgsave或bgrewriteaof操作，在copy-on-write机制作用下，非常可能会导致服务器内存很快耗尽，从而导致Redis服务崩溃，微博也作了类似的改造，废弃掉了aof重写机制，增加了定时持久化操作的配置项cronsave，相当于一个定时任务）

• 独特的热升级机制，增加了热升级的功能，能够在3ms内完成一个实例的热更新。（作者注：这个功能可以避免由于升级造成的业务影响）

• 实例的可用性检测等。

除了上面的，在Redis Cluster上面，阿里云团队也做了很多的工作，比如：

1. 集群支持select、pub/sub、blpop的能力；

2. 对热key的感知和处理；

3. 读写分离；

4. 多数据中心的灾备以及稳定可靠的基于aof log的复制等。

二、Redis Enterprise

来自Redis labs的联合创始人&CTO YiftachShoolman先生在会上提到的一点非常有意思，根据similarweb.com的统计，在Redis使用者TOP5中，中国排第一，远超第二名美国，可见国内Redis用户群体之多。

另外，他还给大家普及了一下Redis的基础，比如Redis的数据结构。

Redis modules 这个功能，相信大家不陌生吧？就是Redis labs这个公司所提出的，并且在此基础上开发了很多的扩展功能，其中本文作者就翻译过其中几篇介绍的文章，比如有：ReJSON、Redis-ML、RediSearch等。

链接：

• http://www.sohu.com/a/155063241_99937638

• http://www.sohu.com/a/155010567_99937638

• http://www.sohu.com/a/154690419_99937638

还讲了很多关于Redis labs产品相关的内容，最后讲到了Redis 企业版的优势，听上去他们真的做了很多的事情，有很多值得学习地方。如下：

三、Codis集群演化和Redis异步迁移

1、Codis集群演化

Redis Cluster和Codis的特性比较：

需要特别提醒一下的是：Codis在3.2版本的时候就允许异步迁移，能够进行平滑的扩容缩容，这是比Redis Cluster进步的地方。

架构设计：

优缺点：

特性介绍

高吞吐

• - 指令流水

• - 实现效率 + 优化GC

并发多连接

• - 单连接 – Redis

• - 多连接 – SSD（RocksDB）

多DB支持

• - 默认16个DB

访问控制

• - 指令黑名单

• - SessionAuth – Proxy 独立配置

• - ProductAuth – Codis 集群共享

读写分离 – 跨机房优化（默认是关闭的）

• - 牺牲一致性

• - 写：写主

• - 读：同IP > 同IDC > 跨IDC （优先级策略）

高可用

• - Sentinel 替换了HA

他还讲述了未来的规划，提到了有如下几点：

• - 兼容Redis，升级到Redis4.2，做到最小修改，兼容分片策略等；

• - 完善Codis，完善K8S的支持，提升自动化部署程度、实现Transaction等，集成Sentinel功能等。

更大的挑战

• - 更大的副本容量：单副本100TB以上

• - 更高的集群吞吐：QPS 500 ~ 1000w/s

• - 更复杂的访问模式1）普通业务 – 低延迟

  2）数据平台 – 高吞吐

• Codis + RocksDB开源方案Pika

2、Redis异步迁移

听到这里时，还以为上面是重点，结果不是，重点下面才真正开始。

Redis同步迁移存在的问题：

降低服务质量

• - 阻塞服务

• - 误触HA、丢失数据

限制数据规模

• - 实际建议<2MB（RESP限制<512MB）

迁移受网络质量（RTT）影响

• - 增加阻塞时间、降低迁移效率

增加错误处理难度

• - 错误恢复困难、人工介入困难

举个栗子：

那么上述的问题的解决思路是什么呢？他继续分享到：

指令分解

• - 单个复杂、耗时的操作，分解成多个简单、高效的指令

• - 分摊CPU分摊，单指令us级别

• - 支持AUTH、SELECT指令

异步IO + 指令流水

• - 连接复用

• - 流量控制 – 发送窗口

• - 批量迁移（Batch）

错误处理 – 脏数据处理

• - 主动清理

• - 过期清理

迁移状态机

• - 发送窗口初始化

• - 确定传输模式：简单 or 分片？

• - 连接初始化（start）

• - REPLACE语义

• - 发送分片（Chunked）

• - 临时TTL = RTT x 3

• - 迁移完成

• - 重置TTL

• - 标记完成（Done）

• - 异步删除 – BIO thread

访问冲突

• - 迁移间隙 – Key Missing

• - 迁移过程中 – 1）读 – 迁冲突； 2）写 – 迁冲突；3）Key Missing

四、Redisson

接着他分享了Redis以及Redisson的概念和特点的介绍，这里为了节省篇幅，省略N多文字，但为了后面的理解，多啰嗦一句：Redisson是操作最简单，功能最丰富的Redis智能客户端，为JVM提供基于Redis的高性能驻内存数据网格。那Redisson的智能化又是体现在哪些方面呢？

Redisson是如此智能的客户端，那相比其它的普通客户端又有怎样的差异和优势呢？

回到主题上，Redisson可以解决传统Web项目分布式化？那它是怎么做到的？当时由于时间的关系，Jack Gu只是从两个方面进行了讲解，相信能在更多的方面进行解决，这两个方面分别是从数据缓存的角度和分布式锁的角度进行分享。

Redisson映射

• Redis基本结构：Redis Hash

• Java 接口：java.util.Map、java.util.concurrent.ConcurrentMap

• 缓存设计模式：Read Through、Write Through、Write Behind

• 数据预热：Data Preload

防缓存穿透，在Redisson上做了一些改进：

Redisson映射数据缓存的两种方案：

在锁上Redisson又做了哪些改进来满足分布式的需求呢？

看着上面的简单描述，各种名词似曾相识吧？真正要用起来，还是需要花些时间慢慢消化的。Redisson在一定程度上减少了使用的复杂性，提高了业务性能，提升了开发效率，可以尝试一下。