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

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

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

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

图1-1 Jedis的主要模块
​ 图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。

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

​ 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，为突出主要架构，部份内容稍有删减。