一、阿里云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上面，阿里云团队也做了很多的工作，比如：
集群支持select、pub/sub、blpop的能力；
对热key的感知和处理；
读写分离；
多数据中心的灾备以及稳定可靠的基于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集群演化
Codis作者spinlock9首先分享了Codis出现的背景和开发中的挑战，他们也跟大多公司一样，也经历过多次的技术选型上的迭代，也曾在Redis + Twemproxy和Redis Cluster进行过尝试，踩过坑，比如twitter 在2015年就不再贡献Twemproxy代码，它最大的缺点是一个静态的Sharding 策略，随着业务的增长也几乎没有办法进行动态的扩缩容。而当时Redis Cluster也只是推出了beta版本，对于线上的业务存在风险。故最终确定在2014年酝酿要开发Codis，15年开始Release出来，会上他介绍了开发过程需要解决的问题，比如：
兼容所有语言的客户端
能支持GB到TB级别的水平扩展能力
也能提供Redis同样的高吞吐和低延迟的优势
高可用等
挑战：
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
Redisson是什么？以及Redisson专业版有哪些特性和优点？Redisson联合创始人顾睿从Redisson使用上，举例“如何利用Redisson分布式化传统web项目”的分享，算是对之前内容的一个很好的补充和论证。(Redisson项目地址：https://github.com/redisson/redisson)传统Web项目的基本架构
传统Web项目的典型特征：
- 非分布式
- 非高可用
- 非高并发
什么是分布式系统？
- 网络 – 高度互联
- 集群 – 多节点
- 单一 – 透明化
分布式系统的特点：
- 开放性
- 透明性
- 扩展性
- 并发性
分布式化的实现方式有哪些呢？
- 架构细分
- 服务化、模块化
- 数据中心化
- 事件驱动
分布式系统会遇到哪些挑战？
接着他分享了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在一定程度上减少了使用的复杂性，提高了业务性能，提升了开发效率，可以尝试一下。
原文链接