Jedis源碼分析共有四個章節，以下為各章連結：
- Jedis源碼分析（一）-Jedis介紹
- Jedis源碼分析（二）-Jedis類結構及實作
- Jedis源碼分析（三）- JedisCluster類結構及實作
- 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 ）到達服務端以後，不會立即執行，會進入一個等待隊列，等到收到下述四個指令時執行不同操作：
- EXEC指令執行時， 伺服器以先進先出（FIFO）的方式執行事務隊列中的指令,當事務隊列裡的所有指令被執行完之後， 将回複隊列作為自己的執行結果傳回給用戶端， 用戶端從事務狀态傳回到非事務狀态， 至此， 事務執行完畢。
- DISCARD指令用于取消一個事務， 它清空用戶端的整個事務隊列， 然後将用戶端從事務狀态調整回非事務狀态， 最後傳回字元串 OK 給用戶端， 說明事務已被取消。
- Redis 的事務是不可嵌套的， 當用戶端已經處于事務狀态， 而用戶端又再向伺服器發送MULTI時， 伺服器隻是簡單地向用戶端發送一個錯誤， 然後繼續等待其他指令的入隊。 MULTI指令的發送不會造成整個事務失敗， 也不會修改事務隊列中已有的資料。
- WATCH隻能在用戶端進入事務狀态之前執行， 在事務狀态下發送 WATCH指令會引發一個錯誤， 但它不會造成整個事務失敗， 也不會修改事務隊列中已有的資料（和前面處理 MULTI的情況一樣）。
Jedis主要有兩條業務邏輯：1）初始化的過程，2）發送指令的過程。下面将摸索着2條主線來學習。本文源碼解析基于Jedis-2.10，為突出主要架構，部分内容稍有删減。