最近在讀hbase源碼關(guān)于rpc的一些實現(xiàn)細節(jié)，想正好趁此機會和大家分享一下我理解到的hbase關(guān)于Nonce機制的實現(xiàn)。

Nonce機制的來源

Nonce這個詞由來已久，且在各個領(lǐng)域都會有相對應(yīng)的名詞解釋。對于HBase來說，由于網(wǎng)絡(luò)環(huán)境的復雜性，在客戶端調(diào)用rpc像服務(wù)器發(fā)送請求時，隨時都有丟失該請求的風險。對于客戶端發(fā)出的一個請求來說，客戶端只會收到三種結(jié)果：服務(wù)端響應(yīng)成功、服務(wù)端響應(yīng)失敗、請求超時。在一個并不可靠的網(wǎng)絡(luò)連接下，請求超時是經(jīng)常會發(fā)生的，對此，HBase中有相應(yīng)的Retry機制保證一個請求可以順利被發(fā)送到服務(wù)端，然而對于Append、Increment這樣的非冪等操作（在HBase中被稱為Delta操作）來說，一個被服務(wù)端重復接收的請求帶來的后果無疑是災(zāi)難性的。于是Nonce機制便應(yīng)運而生。

Nonce機制的實現(xiàn)

下面進入正題，關(guān)于Nonce機制如何在HBase中實現(xiàn)，我將從提出問題-解決問題的角度簡單分析HBase中對于“delta”操作的實現(xiàn)過程。

第一步 現(xiàn)在假設(shè)我是一個客戶端，那么對于我來說，最重要的事就是要去區(qū)分我發(fā)送的多個請求，所以我要為我發(fā)送的每一個請求分配一個id并且保證這些請求的id都是唯一的，對于這個要求，我們可以簡單的使用jdk中的Random類來實現(xiàn)隨機生成不重復的long型數(shù)字作為請求的id。

第二步 現(xiàn)在我們已經(jīng)實現(xiàn)了用一個id標示一個客戶端的不同請求，但是對于一個server來說，他會收到來自超級多的客戶端發(fā)送的請求，那么就會不可避免的遇到不同客戶端發(fā)送的請求中會有id重復的問題。所以解決問題的方式也非常簡單，就是為每一個客戶端也生成一個id去標識，這樣就可以通過一個客戶端id和一個請求id來全局唯一的標識一個服務(wù)端收到的請求了，（HBase的服務(wù)端中用來標識請求的類被稱為NonceKey，其中核心的兩個成員變量便是客戶端id和請求id即nonce值）在HBase3的版本中，這個唯一的客戶端id的生成方式是使用client id的哈希值加一個隨機數(shù)

第三步 有了前面兩步，我們現(xiàn)在已經(jīng)知道一個server是如何區(qū)分請求的問題了，接下來我們關(guān)注服務(wù)端如何對請求進行nonce處理的問題。服務(wù)端有一個核心的管理器叫ServerNonceManager，他掌握著一個請求是否被執(zhí)行的“生殺大權(quán)”，在這個類的內(nèi)部有一個核心容器ConcurrentHashMap<NonceKey, OperationContext>，其中NonceKey就是我們在上兩步中說的用于標識一個請求的key，而OperationContext代表著這個請求進行的操作的具體信息，其中有這個操作的執(zhí)行狀態(tài)（三種執(zhí)行狀態(tài)DONT_PROCEED、PROCEED和WAIT），這三種執(zhí)行狀態(tài)中，DONT_PROCEED代表已經(jīng)執(zhí)行成功不需要再次執(zhí)行了，PROCEED表示已經(jīng)被執(zhí)行但是執(zhí)行失敗了，WAIT表示這個請求正在等待其他請求執(zhí)行結(jié)束后再執(zhí)行。

所以對于ServerNonceManager來說，他要做的事情就是判斷一個請求是否可以被執(zhí)行。對于這個問題，他首先根據(jù)NonceKey去map中找是否之前收到過相同NonceKey的請求，如果沒有，則代表這個請求可以被執(zhí)行（因為之前沒有被重復提交的請求），如果map中有相同NonceKey的請求，則說明這個請求由于網(wǎng)絡(luò)問題被重復發(fā)送了，這時候manager就要通過map中已有的這個請求的狀態(tài)來判斷了，

1. 如果這個已有的請求狀態(tài)為wait，則代表請求還在等待執(zhí)行，于是接著等待，而直接丟棄新來的請求

2. 如果這個已有請求的狀態(tài)為DONT_PROCEED，則代表請求已經(jīng)執(zhí)行完畢，不執(zhí)行新請求

3. 如果這個已有請求的狀態(tài)為PROCEED，則代表請求已經(jīng)執(zhí)行完畢并且執(zhí)行失敗了，則將會執(zhí)行新請求。

另外，為了防止這個map無限擴張，ServerNonceManager將會對其進行定期清理（默認半個小時）

第四步 我們通過前三步已經(jīng)了解到了一個ServerNonceManager是如何構(gòu)建起來的以及如何解決問題的。于是問題就簡單了，當服務(wù)端收到一個delta請求時，首先會根據(jù)ServerNonceManager反饋的結(jié)果，若不能執(zhí)行便直接丟棄，允許執(zhí)行才會進行接下來的處理邏輯。

以上便是我對于HBase中實現(xiàn)Nonce機制的一些思考。

總結(jié)

以上是生活随笔為你收集整理的解决问题的反馈机制_谈谈HBase中的Nonce机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。