shell之正向解析脚本的实现方法

一、阿里云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等。

链接：

https://www.qedev.com/bigdata/795.html

https://www.qedev.com/bigdata/800.html

https://www.qedev.com/bigdata/824.html

还讲了很多关于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 HashJava

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

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

• 数据预热：Data Preload

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

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

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

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