基於一致性哈希的分佈式內存鍵值存儲——CHKV

時間 2019-12-09

標籤基於一致性哈希分佈式內存鍵值存儲 chkv 欄目 Zookeeper 简体版

原文原文鏈接

Consistent Hashing based Key-Value Memory Storage

基於一致性哈希的分佈式內存鍵值存儲——CHKV。
目前的定位就是做爲 Cache，DataBase 的功能先不考慮。java

系統設計

NameNode : 維護 DataNode節點 列表，用心跳檢測 DataNode（通常被動，被動失效時主動詢問三次），節點增減等系統信息變化時調整數據並通知 Client；
DataNode : 存儲具體的數據，向 NameNode 主動發起心跳並採用請求響應的方式來實現上下線，便於 NameNode 發起挪動數據指令，實際挪動操做由 DataNode 自行完成；
Client : 負責向 NameNode 請求 DataNode 相關信息並監聽其變化，操縱數據時直接向對應 DataNode 發起請求就行，

目前支持set,get,delete,keys,expire幾個操做；git

NameNode 失效則整個系統不可用。github

若當成內存數據庫使用，則要注意持久化，並且只要有一個 DataNode 失效（未經請求與數據轉移就下線了）整個系統就不可對外服務；
若當成內存緩存使用，則 DataNode 失效只是失去了一部分緩存，系統仍然可用。
redis

DataNode 失效（未經請求與數據轉移就斷開了和 NameNode 的鏈接）則 NameNode 須要及時通知 Client。數據庫

客戶要使用 CHKV 就必須使用 Client 庫或者本身依據協議（兼容redis）實現，能夠是多種語言的API。
固然也能夠把 Client 當作 Proxy，使得 CHKV 內部結構對客戶透明，亦即有以下兩種方式：緩存

方式1：安全

用戶直接使用Client庫
              ||
        ||          ||
    ||                      ||
NameNode        ||      ||      ||      ||
            DataNode DataNode DataNode DataNode ......

方式2：網絡

用戶經過Proxy訪問    
              ||  
         Client庫構建的Proxy
              ||
        ||          ||
    ||                      ||
NameNode        ||      ||      ||      ||
            DataNode DataNode DataNode DataNode ......

分析

要想實現高可用有兩點： NameNode 要主從雙機熱備，避免單點失效；每一個 DataNode 能夠作成主從複製甚至集羣。多線程

各個組件之間的鏈接狀況：併發

NameNode 要保持和 N 個 Client 的TCP長鏈接，可是隻有在集羣發生變化時纔有交互，因此使用IO多路複用負載就不大
NameNode 要和 M 個 DataNode 保持心跳，TCP請求響應式，負載與 M 和心跳間隔秒數 interval 有關
DataNode 與 Client 是TCP請求響應式操做，Client 請求完畢後保留與該 DataNode TCP鏈接一段時間，以備後續訪問複用鏈接，鏈接採起自動過時策略，相似於LRU
DataNode 與 NameNode 保持心跳
Client 與 NameNode 保持TCP長鏈接
Client 與 DataNode TCP請求響應式操做

以下圖所示，有4個鏈接：其中一、2要主動心跳來保持鏈接；3保持鏈接以備複用並能夠自動超時斷開，再次使用時重連；4完成數據轉移後就斷開鏈接。

NameNode
                   ||       ||     
  一、心跳請求響應||              ||二、監聽長鏈接 
             ||   三、數據請求響應   ||     
          DataNodes  ==========  Clients
           ||    ||
              ||
      四、數據轉移，可複用3

開發優先級：三、一、四、2

代碼結構

NameNode : 實現 NameNode 功能
- handler : handler
- res : 資源，如常量，命令工廠
- service : 服務，含Client管理，DataNode管理
DataNode : 實現 DataNode 功能
- command : 處理客戶端各個命令的具體命令對象
- job : 一些的任務如心跳、數據遷移
- handler : 處理鏈接的handler
- service : 服務，含定時任務管理，數據請求管理
Client : 實現 Client 功能
- handler : handler
- Client : 暴露給用戶的命令管理
- Connection : 發出網絡請求
Common : 實現一些公共的功能，上面三個模塊依賴於此模塊
- command : 命令抽象類
- model : 一些公用的pojo，如請求響應對象
- util : 一些工具類
- helper : 輔助腳本

使用方法

DataNode 運行起來就能夠直接使用 redis-cli 鏈接，如redis-cli -h 127.0.0.1 -p 10100，並進行set、get、del等操做；

注意：要首先運行 NameNode，而後能夠經過JVM參數的方式調整端口，在同一臺機器上運行多個 DataNode，
若要在不一樣機器上運行 DataNode 也能夠直接修改配置文件。

新的 DataNode 能夠直接上線，NameNode 會自動通知下一個節點轉移相應數據給新節點；DataNode 若要下線，
則能夠經過 telnet DataNode 節點的下線監聽端口（TCP監聽）如 telnet 127.0.0.1 6666 ，
併發送 k 字符便可，待下線的DataNode收到命令 k 後會自動把數據所有轉移給下一個 DataNode
而後提示進程pid，用戶就能夠關閉該DataNode進程了，如 Linux： kill -s 9 23456，Windows:taskkill /pid 23456

NameNode 和 DataNode 啓動後就可使用 Client 了，代碼示例以下：

Client 代碼示例在此，關鍵以下：

try(Client client = new Client("192.168.0.136","10102")){// 支持自動關閉
        logger.debug(client.set("192.168.0.136:10099","123456")+"");
        logger.debug(client.get("192.168.0.136:10099")+"");
        logger.debug(client.set("112","23")+"");
        logger.debug(client.del("1321")+"");
        logger.debug(client.del("112")+"");
    }

壓力測試

在本機開啓1個 NameNode 和1個 DataNode 直接壓測，4次

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 5006.76 requests per second
SET: 5056.43 requests per second
SET: 5063.55 requests per second
SET: 5123.74.55 requests per second

把以上2個節點日誌級別都調整爲 info（實際上 DataNode 節點纔會影響 qps），重啓

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 62421.97 requests per second
SET: 87260.03 requests per second
SET: 92592.59 requests per second
SET: 94517.96 requests per second

可見日誌對qps影響很大，是幾k 與 幾十k 的不一樣數量級的概念，若把級別改爲 error，平均qps還能提高幾k，因此生產環境必定要注意日誌級別。

此外觀察，不重啓而且每次壓測間隔都很小的話，qps通常會從 65k 附近開始，通過一、2次的 88k 左右，最終穩定在 98k 附近，數十次測試，最低 62.4k，最高101.2k。

重啓的話，qps就會重複上述變化過程，這應該是和內存分配等初始化工做有關，第1次壓測有大量的初始化，然後面就沒了，因此第一次qps都比較低；還可能與 JIT 有關，因此 Java 的性能測試嚴格上來講要忽略掉最初的幾個樣本纔對。

經觀察，DataNode進程啓動後，內存消耗在59M附近，第1次壓測飆升到134M而後穩定到112M，第2次上升到133M而後穩定到116M，後面每次壓測內存都是先增長几M而後減少更多，最終穩定在76M。

在本機運行一個redis-server進程，而後壓測一下

redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -t set -q

SET: 129032.27 requests per second
SET: 124533.27 requests per second
SET: 130208.34 requests per second
SET: 132450.33 requests per second

經數十次測試，qps 穩定在 128k 附近，最高 132.3k ，最低 122.7k 可見CHKV的單個 DataNode 目前性能還比不過單個 redis。

DataNode 通過重構後，如今的壓測結果以下

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 78554.59 requests per second
SET: 114285.71 requests per second
SET: 119047.63 requests per second
SET: 123628.14 requests per second

通過屢次測試，qps 穩定在 125k 附近，最高 131.9k ，最低 78.6k（這是啓動後第一次壓測的特例，後期穩定時最低是 114.3k），可見重構後
單個 DataNode 和單個 redis-server 的 qps 差距已經很小了，優化效果仍是比較明顯的。

主要優化兩個：去掉單獨的 BusinessHandler 的單獨邏輯線程，由於沒有耗時操做，直接在IO線程操做反而能省掉切換時間；
DataNode 經過 public static volatile Map<String,String> DATA_POOL 共享數據池，其餘相關操做類減小了這個域，省一些內存；
第一條對比明顯，很容易直接測試，第二條沒直接測，只是分析。

而後經過 -Xint 或者 -Djava.compiler=NONE 關閉 JIT 使用 解釋模式，再壓測試試。

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 16105.65 requests per second
SET: 16244.31 requests per second
SET: 16183.85 requests per second
SET: 16170.76 requests per second

可見關閉 JIT 後 qps 下降了 7倍多，並且每次差異不大（即便是第一次），這也能說明上面（默認是混合模式）第一次壓測的 qps 比後面低了那麼多的緣由確實和 JIT 有關。

經過 -Xcomp 使用 編譯模式 ，啓動會很慢。

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 83612.04 requests per second
SET: 117647.05 requests per second
SET: 121802.68 requests per second
SET: 120048.02 requests per second

可見 編譯模式 並無比 混合模式 效果好，由於即便是不熱點的代碼也要編譯，反而浪費時間，因此通常仍是選擇默認的 混合模式 較好。

而後來驗證線程數、客戶端操做與 qps 的關係，實驗機器是 4 core、8 processor，我把 DataNode 的 DataManager 中 workerGroup的線程數依次減小從 8 調到爲 1 （以前的測試都是 4 ），
發現 qps 先升後降，在值爲 2 的時候達到最大值，超過了redis，下面是數據

redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -q

SET: 93283.04 requests per second
SET: 141043.05 requests per second
SET: 145560.68 requests per second
SET: 145384.02 requests per second

經數十次測試，qps 穩定在 142k 附近，最高 150.6k ，穩定後最低 137.2k。
Netty 自己使用了IO多路複用，在客戶端操做都比較輕量（壓測這個 set 也確實比較輕量）時選擇線程數較少是合理的，
由於這時候線程切換的代價超過了多線程帶來的好處，這樣咱們也能理解 redis 單線程設計的初衷了，
單線程雖然有些極端，可是若是考慮 面向快速輕量操做的客戶端 和 單線程的安全與簡潔特性，也是最佳的選擇。

可是若是客戶端操做不是輕量級的，好比咱們把 set 數據大小調爲500bytes，再對 CKHV 不一樣的 workerGroup線程數進行壓測

2 redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -d 500 -q

SET: 80450.52 requests per second
SET: 102459.02 requests per second
SET: 108813.92 requests per second
SET: 99206.34 requests per second

3 redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -d 500 -q

SET: 92592.59 requests per second
SET: 133868.81 requests per second
SET: 133868.81 requests per second
SET: 135685.22 requests per second

4 redis-benchmark -h 127.0.0.1 -p 10100 -c 100 -t set -d 500 -q

SET: 72046.11 requests per second
SET: 106723.59 requests per second
SET: 114810.56 requests per second
SET: 119047.63 requests per second

可見這個時候四、3個線程qps都大於2個線程，符合驗證，可是4的qps又比3少，說明線程太多反而很差，
然而把數據大小調到900byte時，4個線程又比3個線程的qps大了，
因此這個參數真的要針對不一樣的應用場景作出不一樣的調整，總結起來就是輕量快速的操做適宜線程 適當少，重量慢速操做適宜線程 適當多。