Jedis源码分析（一）-Jedis介绍

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

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

1 Jedis对应Redis的四种工作模式
 

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

 2 Jedis的三种请求模式

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

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

 

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

2.1 Client模式

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

2.2 Pipeline模式

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

2.3 Transaction模式

​ Transaction模式即开启Redis的事务管理，Pipeline可以在事务中，也可以不在事务中。事务模式开启后，所有的命令（除了 EXEC 、 DISCARD 、 MULTI 和 WATCH ）到达服务端以后，不会立即执行，会进入一个等待队列，等到收到下述四个命令时执行不同操作：

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

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