redis的客户端与服务器之间的一次通信过程

直接盗图(这个因为是付费专栏，所以标明出处也点不进去)： redis的客户端与服务器之间的一次通信过程

通信过程

• 1.客户端sock01向redis服务端发起连接请求。
• 2.服务端查看到连接请求，产生一个AE_READABLE事件。同时，IO多路复用程序监听到有新的事件，将事件压入队列。
• 3.文件事件分派器，将上一步产生的事件分派到连接应答处理器(为什么会分派到应答处理器呢？首先这个时间肯定包含了产生事件的源信息，通过这个源信息，就可以判断这是一个连接事件，那么就知道需要分派到的处理器了)。连接处理器会创建一个sock01于客户端进行通信。然后将服务端sock01的AE_READABLE事件与，服务端sock01绑定。
• 4.经过上面的几个步骤，连接建立了，那么接下来处理命令。客户端sock01的set k1 v1的命令到达服务端sock01。
• 5.服务端sock01产生一个AE_READABLE命令，同样被压入队列。然后文件事件分派处理器查看到事件源是来自sock01的read时间，由于上一步已经绑定好了。所以直接分派给命令请求处理器。
• 6.命令请求处理器，获取到命令的内容，然后在内存中执行命令。执行完成之后，会将服务端sock01的AE_WRITABLE事件绑定到命令响应处理器。
• 7.服务端sock01在觉察到客户端sock01已经准备好接受命令执行结果的时候，产生一个AE_WRITABLE命令，然后被压入队列，根据事件源被分派。
• 8.命令响应处理器，根据事件源信息，查找到命令的执行结果，然后返回给服务端sock01，然后服务端sock01发送给客户端执行结果。同时命令响应处理器，会将服务端sock01于自己绑定的AE_WRITABLE事件删除。

分析(这里只是自己的，因为并不知道redis中有几个相应处理器和命令处理器，没找到资料)

• 1.只有命令响应处理器在处理完事件之后会删除响应的时间绑定，也就是可能会每次响应sock01的响应器不同。
• 2.于sock01绑定的命令处理器，在每次处理完命令之后，并没有删除AE_READABLE事件，也就是每次执行命令，都会到同一个命令处理器
• 3.如果客户端异常断开，那么肯定是要做一些处理的，应该也包括这些处理器里面绑定时间的处理。也就是需要全部解除
• 4.根据这个图，也可以更好的理解reactor模型。

思考

• 1.根据这些reactor可以想到比如rocketMQ的架构模型，也差不多一样。
• 2.还是希望能在一门技术中想到更多有关联的点。这样有利于将学过的东西进行串联，不但能加身记忆，也能更好的应用。这样，对于新出的技术的优缺点能更快的捕捉到。思想是一致的，只是实现的方式不同，效率也不一样。