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

Nonce機制的來源

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

Nonce機制的實現

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

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

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

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

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

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

2. 如果這個已有請求的狀態為DONT_PROCEED，則代表請求已經執行完畢，不執行新請求

3. 如果這個已有請求的狀態為PROCEED，則代表請求已經執行完畢并且執行失敗了，則將會執行新請求。

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。