摘要：基于一致性哈希的分布式內(nèi)存鍵值存儲(chǔ)。失效未經(jīng)請(qǐng)求與數(shù)據(jù)轉(zhuǎn)移就斷開了和的連接則需要及時(shí)通知?？梢娋幾g模式并沒有比混合模式效果好，因?yàn)榧词故遣粺狳c(diǎn)的代碼也要編譯，反而浪費(fèi)時(shí)間，所以一般還是選擇默認(rèn)的混合模式較好。

基于一致性哈希的分布式內(nèi)存鍵值存儲(chǔ)——CHKV。
目前的定位就是作為 Cache，DataBase 的功能先不考慮。

NameNode : 維護(hù) DataNode節(jié)點(diǎn) 列表，用心跳檢測(cè) DataNode（一般被動(dòng)，被動(dòng)失效時(shí)主動(dòng)詢問三次），節(jié)點(diǎn)增減等系統(tǒng)信息變化時(shí)調(diào)整數(shù)據(jù)并通知 Client；

DataNode : 存儲(chǔ)具體的數(shù)據(jù)，向 NameNode 主動(dòng)發(fā)起心跳并采用請(qǐng)求響應(yīng)的方式來實(shí)現(xiàn)上下線，便于 NameNode 發(fā)起挪動(dòng)數(shù)據(jù)指令，實(shí)際挪動(dòng)操作由 DataNode 自行完成；

Client : 負(fù)責(zé)向 NameNode 請(qǐng)求 DataNode 相關(guān)信息并監(jiān)聽其變化，操縱數(shù)據(jù)時(shí)直接向?qū)?yīng) DataNode 發(fā)起請(qǐng)求就行，

目前支持set,get,delete,keys,expire幾個(gè)操作；

NameNode 失效則整個(gè)系統(tǒng)不可用。

若當(dāng)成內(nèi)存數(shù)據(jù)庫使用，則要注意持久化，而且只要有一個(gè) DataNode 失效（未經(jīng)請(qǐng)求與數(shù)據(jù)轉(zhuǎn)移就下線了）整個(gè)系統(tǒng)就不可對(duì)外服務(wù)；
若當(dāng)成內(nèi)存緩存使用，則 DataNode 失效只是失去了一部分緩存，系統(tǒng)仍然可用。

DataNode 失效（未經(jīng)請(qǐng)求與數(shù)據(jù)轉(zhuǎn)移就斷開了和 NameNode 的連接）則 NameNode 需要及時(shí)通知 Client。

客戶 要使用 CHKV 就必須使用 Client 庫或者自己依據(jù)協(xié)議（兼容redis）實(shí)現(xiàn)，可以是多種語言的API。
當(dāng)然也可以把 Client 當(dāng)做 Proxy，使得 CHKV 內(nèi)部結(jié)構(gòu)對(duì) 客戶 透明，亦即有如下兩種方式：

方式1：

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

方式2：

         用戶通過Proxy訪問    
              ||  
         Client庫構(gòu)建的Proxy
              ||
        ||          ||
    ||                      ||
NameNode        ||      ||      ||      ||
            DataNode DataNode DataNode DataNode ......            

要想實(shí)現(xiàn)高可用有兩點(diǎn)： NameNode 要主從雙機(jī)熱備，避免單點(diǎn)失效；每個(gè) DataNode 可以做成主從復(fù)制甚至集群。

各個(gè)組件之間的連接情況：

NameNode 要保持和 N 個(gè) Client 的TCP長(zhǎng)連接，但是只有在集群發(fā)生變化時(shí)才有交互，所以使用IO多路復(fù)用負(fù)載就不大

NameNode 要和 M 個(gè) DataNode 保持心跳，TCP請(qǐng)求響應(yīng)式，負(fù)載與 M 和心跳間隔秒數(shù) interval 有關(guān)

DataNode 與 Client 是TCP請(qǐng)求響應(yīng)式操作，Client 請(qǐng)求完畢后保留與該 DataNode TCP連接一段時(shí)間，以備后續(xù)訪問復(fù)用連接，連接采取自動(dòng)過期策略，類似于LRU

DataNode 與 NameNode 保持心跳

Client 與 NameNode 保持TCP長(zhǎng)連接

Client 與 DataNode TCP請(qǐng)求響應(yīng)式操作

如下圖所示，有4個(gè)連接：其中1、2要主動(dòng)心跳來保持連接；3保持連接以備復(fù)用并可以自動(dòng)超時(shí)斷開，再次使用時(shí)重連；4完成數(shù)據(jù)轉(zhuǎn)移后就斷開連接。

                     NameNode
                   ||       ||     
  1、心跳請(qǐng)求響應(yīng)||              ||2、監(jiān)聽長(zhǎng)連接 
             ||   3、數(shù)據(jù)請(qǐng)求響應(yīng)   ||     
          DataNodes  ==========  Clients
           ||    ||
              ||
      4、數(shù)據(jù)轉(zhuǎn)移，可復(fù)用3  

開發(fā)優(yōu)先級(jí)：3、1、4、2

NameNode : 實(shí)現(xiàn) NameNode 功能

handler : handler

res : 資源，如常量，命令工廠

service : 服務(wù)，含Client管理，DataNode管理

DataNode : 實(shí)現(xiàn) DataNode 功能

command : 處理客戶端各個(gè)命令的具體命令對(duì)象

job : 一些的任務(wù)如心跳、數(shù)據(jù)遷移

handler : 處理連接的handler

service : 服務(wù)，含定時(shí)任務(wù)管理，數(shù)據(jù)請(qǐng)求管理

Client : 實(shí)現(xiàn) Client 功能

handler : handler

Client : 暴露給用戶的命令管理

Connection : 發(fā)出網(wǎng)絡(luò)請(qǐng)求

Common : 實(shí)現(xiàn)一些公共的功能，上面三個(gè)模塊依賴于此模塊

command : 命令抽象類

model : 一些公用的pojo，如請(qǐng)求響應(yīng)對(duì)象

util : 一些工具類

helper : 輔助腳本

DataNode 運(yùn)行起來就可以直接使用 redis-cli 連接，如redis-cli -h 127.0.0.1 -p 10100，并進(jìn)行set、get、del等操作；

注意：要首先運(yùn)行 NameNode，然后可以通過JVM參數(shù)的方式調(diào)整端口，在同一臺(tái)機(jī)器上運(yùn)行多個(gè) DataNode，
若要在不同機(jī)器上運(yùn)行 DataNode 也可以直接修改配置文件。

新的 DataNode 可以直接上線，NameNode 會(huì)自動(dòng)通知下一個(gè)節(jié)點(diǎn)轉(zhuǎn)移相應(yīng)數(shù)據(jù)給新節(jié)點(diǎn)；DataNode 若要下線，
則可以通過 telnet DataNode 節(jié)點(diǎn)的下線監(jiān)聽端口（TCP監(jiān)聽） 如 telnet 127.0.0.1 6666 ，
并發(fā)送 k 字符即可，待下線的DataNode收到命令 k 后會(huì)自動(dòng)把數(shù)據(jù)全部轉(zhuǎn)移給下一個(gè) DataNode
然后提示進(jìn)程pid，用戶就可以關(guān)閉該DataNode進(jìn)程了，如 Linux： kill -s 9 23456，Windows:taskkill /pid 23456

NameNode 和 DataNode 啟動(dòng)后就可以使用 Client 了，代碼示例如下：

Client 代碼示例在此，關(guān)鍵如下：

    try(Client client = new Client("192.168.0.136","10102")){// 支持自動(dòng)關(guān)閉
        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")+"");
    }

在本機(jī)開啟1個(gè) NameNode 和1個(gè) DataNode 直接壓測(cè)，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個(gè)節(jié)點(diǎn)日志級(jí)別都調(diào)整為 info（實(shí)際上 DataNode 節(jié)點(diǎn)才會(huì)影響 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

可見日志對(duì)qps影響很大，是 幾k 與 幾十k 的不同數(shù)量級(jí)的概念，若把級(jí)別改成 error，平均qps還能提升 幾k，所以生產(chǎn)環(huán)境一定要注意日志級(jí)別。

此外觀察，不重啟并且每次壓測(cè)間隔都很小的話，qps一般會(huì)從 65k 附近開始，經(jīng)過1、2次的 88k 左右，最終穩(wěn)定在 98k 附近，數(shù)十次測(cè)試，最低 62.4k，最高101.2k。

重啟的話，qps就會(huì)重復(fù)上述變化過程，這應(yīng)該是和內(nèi)存分配等初始化工作有關(guān)，第1次壓測(cè)有大量的初始化，而后面就沒了，所以第一次qps都比較低；還可能與 JIT 有關(guān)，所以 Java 的性能測(cè)試嚴(yán)格上來說要忽略掉最初的幾個(gè)樣本才對(duì)。

經(jīng)觀察，DataNode進(jìn)程啟動(dòng)后，內(nèi)存消耗在59M附近，第1次壓測(cè)飆升到134M然后穩(wěn)定到112M，第2次上升到133M然后穩(wěn)定到116M，后面每次壓測(cè)內(nèi)存都是先增加幾M然后減小更多，最終穩(wěn)定在76M。

在本機(jī)運(yùn)行一個(gè)redis-server進(jìn)程，然后壓測(cè)一下

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

經(jīng)數(shù)十次測(cè)試，qps 穩(wěn)定在 128k 附近，最高 132.3k ，最低 122.7k 可見CHKV的單個(gè) DataNode 目前性能還比不過單個(gè) redis。

DataNode 經(jīng)過重構(gòu)后，現(xiàn)在的壓測(cè)結(jié)果如下

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

經(jīng)過多次測(cè)試，qps 穩(wěn)定在 125k 附近，最高 131.9k ，最低 78.6k（這是啟動(dòng)后第一次壓測(cè)的特例，后期穩(wěn)定時(shí)最低是 114.3k），可見重構(gòu)后
單個(gè) DataNode 和單個(gè) redis-server 的 qps 差距已經(jīng)很小了，優(yōu)化效果還是比較明顯的。

主要優(yōu)化兩個(gè)：去掉多帶帶的 BusinessHandler 的多帶帶邏輯線程，因?yàn)闆]有耗時(shí)操作，直接在IO線程操作反而能省掉切換時(shí)間；
DataNode 通過 public static volatile Map DATA_POOL 共享數(shù)據(jù)池，其他相關(guān)操作類減少了這個(gè)域，省一些內(nèi)存；
第一條對(duì)比明顯，很容易直接測(cè)試，第二條沒直接測(cè)，只是分析。

然后通過 -Xint 或者 -Djava.compiler=NONE 關(guān)閉 JIT 使用 解釋模式，再壓測(cè)試試。

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

可見關(guān)閉 JIT 后 qps 降低了 7倍多，而且每次差別不大（即使是第一次），這也能說明上面（默認(rèn)是混合模式）第一次壓測(cè)的 qps 比后面低了那么多的原因確實(shí)和 JIT 有關(guān)。

通過 -Xcomp 使用 編譯模式 ，啟動(dòng)會(huì)很慢。

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

可見 編譯模式 并沒有比 混合模式 效果好，因?yàn)榧词故遣粺狳c(diǎn)的代碼也要編譯，反而浪費(fèi)時(shí)間，所以一般還是選擇默認(rèn)的 混合模式 較好。

然后來驗(yàn)證線程數(shù)、客戶端操作與 qps 的關(guān)系，實(shí)驗(yàn)機(jī)器是 4 core、8 processor，我把 DataNode 的 DataManager 中 workerGroup的線程數(shù)依次減少?gòu)?8 調(diào)到為 1 （之前的測(cè)試都是 4 ），
發(fā)現(xiàn) qps 先升后降，在值為 2 的時(shí)候達(dá)到最大值，超過了redis，下面是數(shù)據(jù)

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

經(jīng)數(shù)十次測(cè)試，qps 穩(wěn)定在 142k 附近，最高 150.6k ，穩(wěn)定后最低 137.2k。
Netty 本身使用了IO多路復(fù)用，在客戶端操作都比較輕量（壓測(cè)這個(gè) set 也確實(shí)比較輕量）時(shí)選擇線程數(shù)較少是合理的，
因?yàn)檫@時(shí)候線程切換的代價(jià)超過了多線程帶來的好處，這樣我們也能理解 redis 單線程設(shè)計(jì)的初衷了，
單線程雖然有些極端，但是如果考慮 面向快速輕量操作的客戶端 和 單線程的安全與簡(jiǎn)潔特性，也是最佳的選擇。

但是如果客戶端操作不是輕量級(jí)的，比如我們把 set 數(shù)據(jù)大小調(diào)為500bytes，再對(duì) CKHV 不同的 workerGroup線程數(shù)進(jìn)行壓測(cè)

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

可見這個(gè)時(shí)候4、3個(gè)線程qps都大于2個(gè)線程，符合驗(yàn)證，但是4的qps又比3少，說明線程太多反而不好，
然而把數(shù)據(jù)大小調(diào)到900byte時(shí)，4個(gè)線程又比3個(gè)線程的qps大了，
所以這個(gè)參數(shù)真的要針對(duì)不同的應(yīng)用場(chǎng)景做出不同的調(diào)整，總結(jié)起來就是輕量快速的操作適宜線程 適當(dāng)少，重量慢速操作適宜線程 適當(dāng)多。

水平有限，目前項(xiàng)目的問題還很多，可以改進(jìn)的地方還很多，先列個(gè)清單：

高可用性保證

斷線重連

DataNode遷移數(shù)據(jù)的正確性保障

對(duì)于WeakReference的支持

更多數(shù)據(jù)類型

更多操作

完整的校驗(yàn)機(jī)制

等等......

全部代碼在Github上，歡迎 star，歡迎 issue，歡迎 fork，歡迎 pull request......
總之就是歡迎大家和我一起完善這個(gè)項(xiàng)目，一起進(jìn)步。

戳此看原文，來自MageekChiu