阿里云专访Redisson做者Rui Gu：构建开源企业级Redis客户端之路

摘要： 本文为阿里云同窗在RedisConf2018上对Redisson开源客户端做者Rui Gu作的一个专访，主要介绍了Rui Gu参与开启Redisson客户端开发的历程，同时也详细介绍了Redisson的架构模型还有在分布式锁上的工做，最后Rui Gu介绍了Redisson和开源的协做，同时介绍了后续Redisson客户端的长期发展目标。

笔者表明阿里云参加了RedisConf 2018的会议，在会议上对开源Redisson客户端的做者Rui Gu作了一个访谈，Rui Gu在Redis社区国际上的影响力还有在开源上的工做给笔者留下了深入的印象，如下是访谈的具体内容。

以上照片为阿里云夏周、Rui Gu、阿里云白宸、阿里泽贤

当初为何参与设计开发Redisson？

自04年从事工业自动化、工业IoT工做至今，涉及到不少场景须要对一系列设备进行监控和信号处理等工做。该类场景对实时处理能力，系统稳定性，高可用性，容灾能力等等要求很是高。从12年时决定采用Redis做为实时数据库时就产生了许多想法。Redis与Java这样的编程语言中的经常使用数据结构看似相像却又不一样，一直但愿可以用什么方法将二者联系起来。13年开始商用Redis之后这种想法越增强烈。因而在工做之余自行开始了一些相关的摸索与实践，最终决定采用动态类的形式让Redis的数据结构操做起来更像Java对应的结构。谁知远在莫斯科的Nikita彷佛也有相似的想法，他从14年元旦便开始了实际应用的开发，并很快的开源了Redisson。于此同时个人实践也有了许些进展，并初步的实现了一些基本功能。不过因为工做上的种种缘由，再加上当时本身也缺少足够的信心，毕竟这是条没人走过的路，大半年过去了进展比较缓慢。却不知Nikita面对这一样的问题，可是他不只艰难地坚持了下来，并且丝毫没有放弃的意思。14年下半年时我开始注意到了Redisson项目，仔细了解了之后顿时产生了很强的共鸣，虽然和个人实践有着一样的理念却又是不一样的出发点。因而乎，在有了这样的火花之后，咱们开始了相互之间的沟通和交流，最后在15年初时决定，放弃本身的实践项目，加入Redisson。至此，在这条没人走过的路上咱们再也不独行。

Redisson解决了什么问题？相比其余Redis客户端它有什么优点？

2.1）IoT行业里，一组设备的各类实时状态值每每是做为一个具备业务意义的对象，由JVM管理在内存里，若是将这个对象存储到Redis数据库的String结构里，每次更新一个状态值，就须要作一次序列化和反序列化。同时还有可能面临着同一时刻操做同一个对象的不一样状态值带来的并发难题。实际应用时采用了Redis提供的Hash数据结构来储存这个对象，只有这样才能有效地避免这类问题的发生。尽管Redis的Hash结构和Java里的HashMap极为类似，可是在程序操做Redis的时候不能像操做HashMap同样便捷。并且若是对Redis相关命令的用法不能稔熟于心，或在细节之到处理不当，便会最终形成业务上的各类问题。Redisson的Map就是为了填补Redis的Hash和Java的HashMap二者之间的空缺而产生。

图1 - Jedis的Hash操做

图2 - Java的ConcurrentHashMap

图3 - Redisson的ConcurrentHashMap

2.2）工控和某些IoT场景对实时处理能力要求很高，全部的信号都必须实现毫秒级响应。这类场景还具备并发量巨大的特色。与社交电商等场景不一样的是这类应用场景基本没有峰谷流量，时时刻刻都是峰值。所以其它场景里常见的削峰填谷措施在这里只能加剧负担。在这样的场景下若是使用像Jedis这样采用同步编程模型的客户端时，就须要随时确保并发线程数与链接数一对一，不然获取不到可用链接会直接报错。相比之下Redisson利用了Netty异步编程框架，使用了与Redis服务端结构相似的事件循环（EventLoop）式的线程池，并结合链接池的方式弹性管理链接。最终作到了使用少许的链接既能够知足对大量线程的要求，从根本上缓解线程之间的竞争关系。同时异步操做的模式还可以避免数据请求形成业务线程的阻塞。

2.3）Redis 发展至今经历了屡次技术变迁。官方版在迭代的过程当中不但增长了许多有用的功能，同时也发展了几种高可用性方案。于此同时，社区和云计算商在官方版上进而开发出了多种基于代理（Proxy）的高可用方案。相比之下，这些方案各有优劣，适用场景也各自不一。多样化的方案在带来便利的同时也带来了麻烦。好比在业务扩容，从简单的单机或主从模式迁移到哨兵或集群模式；或是业务迁移，从自建的Redis环境迁移到云上；亦或是项目的持续性交付CD/CI过程当中，不一样的阶段使用不一样Redis运行模式等等状况。每每须要开发人员针对不一样的高可用方案开发出一套与之匹配的使用方法。使得一个项目对Redis运行模式的耦合度高，在Redis运行模式变化时就必须更改业务代码。Redisson针对这种状况提供了一套便捷的文件化配置方法，在无需修改程序代码的状况下，经过不一样的JSON，YAML或SpringXML文件实现对不一样Redis运行模式和环境的支持。这既下降了开发难度，也下降了运维难度。

Redisson在分布式锁方面的工做很是多，可否介绍下这方面的实践？
对于Redis分布式锁的实现方式，网上讨论相关文章都基本都“烂大街”了。然而几乎全部相关介绍都是在单纯使用setnx命令的基础上进行一个简单封装，且少有文章分析这样设计的缺陷。在这个博客满天飞，代码随便贴的时代，这样的局面无形之中给了你们一个假象，就是Redis分布式锁只能是以这样简单的形式存在，即使有缺陷也只能在业务代码里规避。那么为何不换位思考一下，即用稍微复杂点的设计来弥补它的不足，从而换取业务上的灵活性呢？再从新设计Redis分布式锁以前，咱们先了解一下单纯使用setnx命令封装的分布式锁有哪些不足。
1). 不具有可重入性
在执行setnx命令时，一般采用业务上指定的名称做为key名，用时间或随机值做为value来实现。这样的实现方式不具有追踪请求线程的能力，同时也不具有统计重入次数的能力，甚至有些实现方式都不具有操做的原子性。当遇到业务上须要在多个地方用到一样一个锁的时候，很显然使用不具备可重入的锁会很容易发生死锁的现象。特别是在有递归逻辑的场景里，发生死锁的概率会更高。Java并发工具包里的Lock对象和sychronized语块都具备可重入性，对于常用这些工具的人来讲，每每会很容易忽略setnx的这个缺陷。

2). 不支持续约
在分布式环境中，为了保证锁的活性和避免程序宕机形成的死锁现象，分布式锁每每会引入一个失效时间，超过这个时间则认为自动解锁。这样的设计前提是开发人员对这个自动解锁时间的粒度有一个很好的把握，过短了可能会出现任务没作完锁就失效了，而太长了在出现程序宕机或业务节点挂掉时，其它节点须要等很长时间才能恢复，而难以保证业务的SLA。setnx的设计缺少一个延续有效期的续约机制，没法保证业务可以先工做作完再解锁，也不能确保在某个程序宕机或业务节点挂掉的时候，其它节点可以很快的恢复业务处理能力。

3). 不具有阻塞的能力
日常你们多少都接触过的锁，因为加锁策略（Locking Strategy）的差异，使得每种锁都有各自不一样的特性。可是在一般状况下这些锁都具有两个共性：一是互斥性，二是阻塞性。互斥性是指在任什么时候刻最多只能有一个线程得到通行的资格。阻塞性是指的在有竞争的状况下，未获取到资源的线程会中止继续操做，直到成功获取到资源或取消操做。很显然setnx命令只提供了互斥的特性，却没有提供阻塞的能力。虽然在业务代码里能够引入自旋机制来进行再次获取，但这仅仅是把本来应该在锁里实现的功能搬到了业务代码里，经过增长业务代码的复杂程度来简化锁的实现彷佛显得有点南辕北辙。

Redisson的分布式锁在知足以上三个基本要求的同时还增长了线程安全的特色。利用Redis的Hash结构做为储存单元，将业务指定的名称做为key，将随机UUID和线程ID做为field，最后将加锁的次数做为value来储存。同时UUID做为锁的实例变量保存在客户端。将UUID和线程ID做为标签在运行多个线程同时使用同一个锁的实例时，仍然保证了操做的独立性，知足了线程安全的要求。

加锁时经过Lua脚本先检查锁是否存在，如不存在则建立hash相关字段并设定过时时间后返回，这表示加锁成功。若是该hash字段已经存在，再检查随机字段和线程id是否一致。若是一致则递增value的值并从新更新过时时间后返回，此时表示同一节点同一线程再次成功加锁，从而保证了可重入性。若是hash存在且字段不一致，说明其余节点或线程已经拥有了这个锁。所以Lua脚本返回这个hash的当前有效期。当结果返回到在客户端后，若是加锁成功，则经过线程池依照设定好的参数定时执行续约，最后通知请求线程继续后续操做。若是加锁没有成功，则监听一个以这个key为后缀的pubsub频道，直到收到解锁消息后再次重试。

解锁时经过Lua脚本先检查锁是否存在，若是已经不存在则直接发布解锁消息并返回。若是任然存在则检查标签是否存在，若是不存在则表示这个锁并不为本线程所拥有，这种状况请求线程将收到报错。若是存在则表示该锁正是被该线程所拥有。在这种状况下，递减标签字段后判断，若是返回的加锁数量仍然大于0，说明当前的锁仍然有效，仅仅只是重入次数减小了。相反这表示锁已经彻底解开，则当即删除该锁并发布解锁信息。

Redisson的可重入锁解决了setnx锁的许多先天性不足，可是因为它仍然是以单一一个key的方式储存在固定的一个Redis节点里，而且有自动失效期。这样的设计虽然能够很大程度上避免客户端程序宕机或业务节点挂掉形成的影响，可是随之带来的弊端是遇到服务端Redis进程宕机或节点挂掉的状况，仍是有可能会形成锁的信息丢失，这样的缺陷显然没法知足某些特定场景提出的高可用性要求。

介于这种状况，Redis做者Salvatore提出了一个基于多个节点的高可用分布式锁的算法，起名叫红锁（RedLock： https://redis.io/topics/distlock）。在这种算法下，客户端须要同时在多个节点里同时尝试获取一个独立的锁，只有当一次性成功获取了大多数锁的状况下才能被视为赢得了高可用分布式锁，不然须要解除已经部分获取到的锁，等待一个随机时间后再次重试。

在算法设计上，Salvatore依然采用的是setnx做为举例讲解分布式锁的互斥特性。在算法实现上，Redisson的RedissonRedLock采用的是前面提到的更加灵活方便的可重入锁。Redisson的扩展算法是Redis官网惟一承认的Java实现。

虽然Redlock的算法提供了高可用的特性，但创建在大多数可见原则的前提下，这样的算法适用性仍然有必定局限。Redisson为此提供了基于加强型的算法的高可用分布式联锁RedissonMultiLock。这种算法要求客户端必须成功获取所有节点的锁才被视为加锁成功，从而更进一步提升了算法的可靠性。

4.可否介绍下Redisson最前沿的发展方向？
Redisson的发展路线决定了它在Redis的功能扩展及应用方式上始终走在业界的前列，其中最具备表明性的即是本地缓存功能了。2016年为了解决一企业版用户的切实需求开发了这一功能。其原理是采用牺牲客户端自身内存的空间的方式，换取在频繁获取某些经常使用数据时消耗在网络上的时间。该功能在同年9月开源后便当即受到了广大用户的关注。这一功能的出现加速了传统IT用户从其余相似平台迁移到Redis的速度。其受欢迎程度大大超乎了Nikita和个人想象。以致于每一年都有企业用户不远万里去Redis大会等相似国际交流大会，并分享它们使用Redisson从其余平台向Redis迁移过程和经验。也正是由于这种趋势而引发了Redis做者Salvatore的注意，在同一些用户面对面沟通交流以后，Salvatore决定将客户端缓存功能做为Redis从此发展的重要方向，并为此提出了RESP3协议。RESP3的出现将为客户端缓存功能提供服务端协调的能力。同时Salvatore还邀请Redisson团队做为专家组成员参与Redis客户端缓存标准的指定。

5.Redisson作为开源项目如何保证持续的发展？
为了保证Redisson项目的可持续性的健康发展，为了不像其余开源项目面临的一段时间之后就无人维护的尴尬局面，17年初Nikita和我商量后决定在开源项目基础上提供收费咨询服务，为项目的正常运做提供必要的资金。同时还针对大型企业用户遇到的特殊场景提供了企业级的综合性解决方案，最后将这些全部的方案与企业级SLA支持服务打包做为Redisson PRO正式面向企业用户。

相对于其余客户端而言，虽然Redisson项目创立的时间较短，但已经受到了来自不一样行业企业的信任，其中不乏许多行业领头羊企业，其中最值得介绍的是这几个世界级的企业用户：
• 计算机行业的IBM。想必你们都熟悉IBM，PC机的鼻祖。，业界少有同时具备超强硬件软件研发能力的企业，即使如此，IBM也心甘情愿的使用Redisson，这种信任是对咱们最大的支持。
• 航空国防制造业的波音。在它们主动联系咱们之前，我很难想象波音也会对Redisson感兴趣。事实上波音除了造飞机之外，它也是全球最大的飞行航图提供商和移动电子飞行包的方案提供商，几乎每一个航空公司都是他们的用户。Redisson为他们的在线飞行导航业务提供了扎实的基础。
• 保险业的美国国际集团（AIG）。美国国际集团成立于1919年的中国上海，它是首个将保险概念带给中国人的西方企业，其业务遍及全球130多个国家和地区。虽然08年经济危机中，遭遇股价瞬间暴跌的惨剧将AIG推入了吃瓜群主的视线，但它今天还是一个拥有99年历史，总资产为6千多亿美圆的国际性大型企业。在通过AIG团队长时间的调研后，Redisson被用于支持其名目众多的金融保险业务。
• 金融机构标准普尔（S&P Global）。提到经济危机就不得不提一下世界权威金融分析机构标准普尔。它是美国证券交易委员会（SEC）承认的三大评级组织之一，专门为投资者提供信用评级，投资研究和咨询等服务。在业内外的知名度很高，颇负盛名的S&P 500美国股指即是由它建立并维护着。标准普尔不只对外提供针对上市企业的评级，还提供针对国家政府的评级。它在2011年时断然下降美国政府的评级，并把其前景调整为负面之后，立马引起了金融业的剧烈波动。但正是这个呼风唤雨无所不能，连美国政府都不放眼里的机构也成为了Redisson的忠实用户，并将其用于提供复杂的金融数据的分析和处理。因而可知Redisson的信任评级是很是的高[奸笑]。

原文连接