中介軟體是什麼

中介軟體是一種獨立的系統軟體或服務程式，分散式應用軟體藉助這種軟體在不同的技術之間共享資源。中介軟體位於客戶機/ 伺服器的作業系統之上，管理計算機資源和網路通訊。是連線兩個獨立應用程式或獨立系統的軟體。相連線的系統，即使它們具有不同的介面，但通過中介軟體相互之間仍能交換資訊。執行中介軟體的一個關鍵途徑是資訊傳遞。通過中介軟體，應用程式可以工作於多平臺或 OS 環境。中介軟體是介於作業系統和應用軟體之間，為應用軟體提供服務功能的軟體，有訊息中介軟體，交易中介軟體，應用伺服器等。由於介於兩種軟體之間，所以，稱為中介軟體。

為什麼使用中介軟體

具體地說，中介軟體遮蔽了底層作業系統的複雜性，使程式開發人員面對一個簡單而統一的開發環境，減少程式設計的複雜性，將注意力集中在自己的業務上，不必再為程式在不同系統軟體上的移植而重複工作，從而大大減少了技術上的負擔。中介軟體帶給應用系統的，不只是開發的簡便、開發週期的縮短，也減少了系統的維護、執行和管理的工作量，還減少了計算機總體費用的投入。

今天給大家介紹的是一款中介軟體KeyDB，KeyDB專案是從redis fork出來的分支。眾所周知redis是一個單執行緒的kv記憶體儲存系統，而KeyDB在100%相容redis API的情況下將redis改造成多執行緒。

而對於KeyDB，在Gitee上有這樣一段話

KeyDB是Redis的高效能分支，專注於多執行緒，記憶體效率和高吞吐量。除了多執行緒之外，KeyDB還具有僅在Redis Enterprise中可用的功能（例如FLASH儲存支援），而根本不可用的功能（例如直接備份到AWS S3）。

在相同的硬體上，KeyDB每秒可以執行的查詢數量是Redis的兩倍，而延遲卻降低了60％

那我們來看一下，這麼牛逼的中介軟體他怎麼就這麼牛逼的

執行緒模型

KeyDB將redis原來的主執行緒拆分成了主執行緒和worker執行緒。每個worker執行緒都是io執行緒，負責監聽埠，accept請求，讀取資料和解析協議。如圖所示：

KeyDB使用了SO_REUSEPORT特性，多個執行緒可以繫結監聽同個埠。

每個worker執行緒做了cpu綁核，讀取資料也使用了SO_INCOMING_CPU特性，指定cpu接收資料。解析協議之後每個執行緒都會去操作記憶體中的資料，由一把全域性鎖來控制多執行緒訪問記憶體資料。主執行緒其實也是一個worker執行緒，包括了worker執行緒的工作內容，同時也包括只有主執行緒才可以完成的工作內容。在worker執行緒陣列中下標為0的就是主執行緒。

主執行緒的主要工作在實現serverCron，包括：

處理統計客戶端連結管理db資料的resize和reshard處理aofreplication主備同步cluster模式下的任務連結管理

在redis中所有連結管理都是在一個執行緒中完成的。在KeyDB的設計中，每個worker執行緒負責一組連結，所有的連結插入到本執行緒的連結列表中維護。連結的產生、工作、銷燬必須在同個執行緒中。每個連結新增一個欄位

int iel; /* the event loop index we're registered with */

用來表示連結屬於哪個執行緒接管。

KeyDB維護了三個關鍵的資料結構做連結管理：

clients_pending_write：執行緒專屬的連結串列，維護同步給客戶連結傳送資料的佇列clients_pending_asyncwrite：執行緒專屬的連結串列，維護非同步給客戶連結傳送資料的佇列clients_to_close：全域性連結串列，維護需要非同步關閉的客戶連結

分成同步和非同步兩個佇列，是因為redis有些聯動api，比如pub/sub，pub之後需要給sub的客戶端傳送訊息，pub執行的執行緒和sub的客戶端所線上程不是同一個執行緒，為了處理這種情況，KeyDB將需要給非本執行緒的客戶端傳送資料維護在非同步佇列中。

同步傳送的邏輯比較簡單，都是在本執行緒中完成，以下圖來說明如何同步給客戶端傳送資料：

如上文所提到的，一個連結的建立、接收資料、傳送資料、釋放連結都必須在同個執行緒執行。非同步傳送涉及到兩個執行緒之間的互動。KeyDB通過管道在兩個執行緒中傳遞訊息：

int fdCmdWrite; //寫管道int fdCmdRead; //讀管道

本地執行緒需要非同步傳送資料時，先檢查client是否屬於本地執行緒，非本地執行緒獲取到client專屬的執行緒ID，之後給專屬的執行緒管到傳送AE_ASYNC_OP::CreateFileEvent的操作，要求新增寫socket事件。專屬執行緒在處理管道訊息時將對應的請求新增到寫事件中，如圖所示：

redis有些關閉客戶端的請求並非完全是在連結所在的執行緒執行關閉，所以在這裡維護了一個全域性的非同步關閉連結串列。

鎖機制

KeyDB實現了一套類似spinlock的鎖機制，稱之為fastlock。

fastlock的主要資料結構有：

struct ticket{ uint16_t m_active; //解鎖+1 uint16_t m_avail; //加鎖+1};struct fastlock{ volatile struct ticket m_ticket; volatile int m_pidOwner; //當前解鎖的執行緒id volatile int m_depth; //當前執行緒重複加鎖的次數};

使用原子操作__atomic_load_2，__atomic_fetch_add，__atomic_compare_exchange來通過比較m_active=m_avail判斷是否可以獲取鎖。

fastlock提供了兩種獲取鎖的方式：

try_lock：一次獲取失敗，直接返回lock：忙等，每1024 * 1024次忙等後使用sched_yield 主動交出cpu，挪到cpu的任務末尾等待執行。

在KeyDB中將try_lock和事件結合起來，來避免忙等的情況發生。每個客戶端有一個專屬的lock，在讀取客戶端資料之前會先嚐試加鎖，如果失敗，則退出，因為資料還未讀取，所以在下個epoll_wait處理事件迴圈中可以再次處理。

Active-Replica

KeyDB實現了多活的機制，每個replica可設定成可寫非只讀，replica之間互相同步資料。主要特性有：

每個replica有個uuid標誌，用來去除環形複製新增加rreplay API，將增量命令打包成rreplay命令，帶上本地的uuidkey，value加上時間戳版本號，作為衝突校驗，如果本地有相同的key且時間戳版本號大於同步過來的資料，新寫入失敗。採用當前時間戳向左移20位，再加上後44位自增的方式來獲取key的時間戳版本號。

不知道看完這篇文章的老鐵們有沒有一點收穫，關注我的老鐵，應該清楚，之前的文章中，寫的更多的是一些在面試的過程中考察的比較多的技術，還有就是一些資料以及思維導圖的普及，但是最近有讀者跟我說，可以後面多加一些技術的擴充套件講解，於是有了今天的這份文章