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，爲突出主要架構，部份內容稍有刪減。