Jedis源码分析(一) - Jedis介绍

Jedis源码分析共有四个章节,以下为各章链接:

  1. Jedis源码分析(一) - Jedis介绍
  2. Jedis源码分析(二) - Jedis类结构及实现
  3. Jedis源码分析(三) - JedisCluster类结构及实现
  4. Jedis源码分析(四) - JedisSentinel与ShardedJedis介绍

Jedis对应Redis的四种工作模式

avatar

图1-1 Jedis的主要模块

图1-1是Jedis的主要模块,Jedis,JedisCluster,JedisSentinel和ShardedJedis对应了Redis的四种工作模式:Redis Standalone(单节点模式),Redis Cluster(集群模式),Redis Sentinel(哨兵模式)和Redis Sharding(分片模式)。

Jedis的三种请求模式

​ 每个Jedis实例对应一个Redis节点,我们对Jedis实例的每个操作,都相当于使用redis-cli启动客户端的直接操作。无论是集群模式,哨兵模式,还是分片模式,内部均为对Jedis实例的操作。所以了解Jedis类的内部结构及Jedis实例的请求模式是掌握Jedis框架的基础。

Jedis实例有3种请求模式,Pipeline,Transaction和Client。

avatar

图2-1 Jedis的三种请求模式

Jedis实例通过Socket建立客户端与服务端的长连接,往outputStream发送命令,从inputStream读取回复,图2-1显示Redis常用的3种请求模式,下文是详细说明:

Client模式

Client模式就是常用的“所见即所得”,客户端发一个命令,阻塞等待服务端执行,然后读取返回结果。优点是确保每次处理都有结果,一旦发现返回结果中有Error,就可以立即处理。

Pipeline模式

Pipeline模式则是一次性发送多个命令,最后一次取回所有的返回结果,这种模式通过减少网络的往返时间和IO的读写次数,大幅度提高通信性能,但Pipeline不支持原子性,如果想保证原子性,可同时开启事务模式。

Transaction模式

Transaction模式即开启Redis的事务管理,Pipeline可以在事务中,也可以不在事务中。事务模式开启后,所有的命令(除了 EXECDISCARDMULTIWATCH )到达服务端以后,不会立即执行,会进入一个等待队列,等到收到下述四个命令时执行不同操作:

  1. EXEC命令执行时, 服务器以先进先出(FIFO)的方式执行事务队列中的命令,当事务队列里的所有命令被执行完之后, 将回复队列作为自己的执行结果返回给客户端, 客户端从事务状态返回到非事务状态, 至此, 事务执行完毕。
  2. DISCARD命令用于取消一个事务, 它清空客户端的整个事务队列, 然后将客户端从事务状态调整回非事务状态, 最后返回字符串 OK 给客户端, 说明事务已被取消。
  3. Redis 的事务是不可嵌套的, 当客户端已经处于事务状态, 而客户端又再向服务器发送MULTI时, 服务器只是简单地向客户端发送一个错误, 然后继续等待其他命令的入队。 MULTI命令的发送不会造成整个事务失败, 也不会修改事务队列中已有的数据。
  4. WATCH只能在客户端进入事务状态之前执行, 在事务状态下发送 WATCH命令会引发一个错误, 但它不会造成整个事务失败, 也不会修改事务队列中已有的数据(和前面处理 MULTI的情况一样)。

Jedis主要有两条业务逻辑:1)初始化的过程,2)发送命令的过程。下面将摸索着2条主线来学习。本文源码解析基于Jedis-2.10,为突出主要架构,部分内容稍有删减。

0%