戳蓝字「TopCoder」关注我们哦！
编者注：笔者整理了一份【Redis不完全指南】，包含了很多详细的知识点和Redis经典面试题，可关注「TopCoder」公众号，发送 Reids 来获取~
Redis异步
说到Redis的通信，我们都知道Redis基于RESP(Redis Serialization Protocol)协议来通信，并且通信方式是停等模型，也就说一次通信独占一个连接直到client读取到返回结果之后才能释放该连接让其他线程使用。
这里小伙伴们思考一下，针对Redis客户端，我们能否使用异步通信方式呢？首先要理解这里讨论的异步到底是指什么，这里的异步就是能够让client端在等待Redis服务端返回结果的这段时间内不再阻塞死等，而是可以继续干其他事情。
针对异步，其实有两种实现思路，一种是类似于dubbo那样使用单连接+序列号（标识单次通信）的通信方式，另外一种是类似于netty client那样直接基于Reactor模型来做。注意：方式一的底层通信机制一般也是基于Reactor模型，client端不管是什么处理方式，对于redis server端来说是无感知的。
下面就这2种实现思路分别讨论下 :)
单连接+序列号通信方式
单连接+序列号通信方式理论上是可以的，不过由于RESP协议中并没有一个"序列号"的字段，所以直接靠原生的通信方法来实现是不现实的。不过我们可以通过echo命令传递并返回"序列号"+正常的读写方式来实现，这里要保证二者执行的原子性，可以通过lua脚本或者事务来实现，事务方式如下：
MULTI
ECHO "唯一序列号"
GET key1
EXEC
然后客户端收到的结果是一个 [ "唯一序列号", "value1" ]的列表，可以根据前一项识别出这是发送的哪个请求。
为什么Redis通信方式并没有采用类似于dubbo这种通信方式呢，笔者认为有以下几点：
使用停等这种通信方式实现简单，并且协议字段尽可能紧凑；
Redis都是内存操作，处理性能较强，停等协议不会造成客户端等待时间较长；
目前来看，通信方式这块不是Redis使用上的性能瓶颈，这一点很重要。
Reactor模型通信机制
Reactor模型通信机制就是应用程序与Redis通信时，发送数据之后就将该连接的后续的读取操作（read事件）交给其他Reactor来处理，在Java中也就是常说的Java NIO/Selecter机制，注意，这里重要的是需要设置Redis结果读取的回调处理方法。
从以上两个异步处理机制流程来说，异步处理重要的是设置对应的处理回调逻辑，其实不仅仅是Redis通信，任何网络通信（RPC/数据库等）都可以进行异步化改造，异步化改造虽然原理不难，但是在一个处理链路上需要多个地方设置异步回调逻辑，理解上来说可能稍微麻烦一点。
反应式架构
反应式架构中的反应式就是 Reactive，分析反应式架构之前，先了解下常见的异步化处理机制：线程池、事件驱动、消息驱动等。
线程池：业务中将耗时操作交给线程池来处理，不影响当前线程。
事件驱动：比如网络IO事件，也就是常说的Reactor处理机制。
消息驱动：通过消息将后续处理逻辑交给其他线程或者进程来处理，达到解耦效果。
反应式架构，从低纬度来说，比如针对网络通信这块，可以通过Reactor机制（比如Java的NIO/Selector等）来完成异步处理；从高纬度来说，就是在一整个业务链路中，涉及到可能造成阻塞的环节都改造成异步处理。
目前针对反应式架构，业界已经有一些对应的开源解决方案，比如Java 8 已经逐渐普及，因为它包含对 Lambda 的支持，这让开发者对 Lambda 的接受度大大提高；同时 Reactive 相关的业务框架在业界已有成熟的实现，RxJava 已经广泛在大小公司中应用；最后，包括 Java 9（引入 Reactive Sreams 规范 API）、Spring 5（引入 Reactor/WebFlux）、Spring Boot 2 都开始拥抱 Reactive，说明反应式编程的确是趋势。
整个方案对业务架构的升级主要包括编程框架、中间件，以及业务方的升级。中间件的升级，包括服务框架（RPC）、网关、缓存、消息（MQ）、DB（JDBC）、限流组件、分布式跟踪系统、移动端 Rx 框架。更多的反应式架构可参考：https://www.infoq.cn/article/2upHTmd0pOEUNmhY5-Ay
往期精选
扫一扫
1166
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
