Redis請求路由的示例分析

這篇文章主要介紹Redis請求路由的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

請求重定向

既然是重定向我們就應(yīng)該了解，重定向指的是通過某種方法將原來的請求重新轉(zhuǎn)向其它的地方，那么Redis中的重定向指的到底是什么呢？我們知道Redis中的任何鍵都存儲到槽中，而通過上幾篇文章中我們知道在Redis集群環(huán)境中，槽被均勻的分布到多個主節(jié)點中了，所以在我們執(zhí)行任何Redis命令時，和單節(jié)點有很大的不同，因為集群環(huán)境首先要計算鍵對應(yīng)的槽，再根據(jù)槽找出相應(yīng)的節(jié)點。如果計算之后，當(dāng)前鍵所在的槽是當(dāng)前節(jié)點，那么就直接處理該命令，如果計算完后，不是當(dāng)前節(jié)點，則Redis會顯示MOVED重定向錯誤，也就是告訴客戶端該鍵所對應(yīng)槽的正確節(jié)點是多少。這個就叫做Redis的重定向。下面我們演示一下上述所說的內(nèi)容。

下面我們啟動一個新節(jié)點6387。因為該節(jié)點沒有添加到集群中，所以我們執(zhí)行set命令時，可以直接返回成功。

下面我們在集群中執(zhí)行同樣的命令。

我們看在集群環(huán)境中執(zhí)行同樣的命令時，Redis提示了MOVED錯誤。原因也就是上述介紹中的那樣。下面我們看一下MOVED重定向的執(zhí)行流程。也就是如下圖所示：

在Redis中我們可以使用cluster keyslot {key}命令查看key所對應(yīng)的槽，然后在通過cluster nodes命令查看每個節(jié)點負責(zé)的槽，這樣我們就可以在執(zhí)行命令的時候，就可以知道在哪個節(jié)點上執(zhí)行了。我還還是已上圖的key為例。具體操作如下圖所示:

我們用cluster keyslot {key}命令查看鍵所在的槽是12691。然后我們通過cluster nodes命令知道節(jié)點6382負責(zé)的槽為12288-16383。所以我們在執(zhí)行命令時，只有在6382節(jié)點上執(zhí)行才能成功，在其它節(jié)點上執(zhí)行Redis都會報MOVED重定向錯誤。下面我們將上述執(zhí)行失敗的命令在6382節(jié)點執(zhí)行。

在Redis中我們使用redis-cli執(zhí)行命令時，我們可以添加-c參數(shù)，該參數(shù)會自動重定向，簡化我們手動重定向操作。

鍵命令執(zhí)行主要分兩個步驟：計算槽，查找槽所在的節(jié)點。下面我們詳細介紹一下這兩方面的內(nèi)容。

計算槽

Redis根據(jù)鍵的使用CRC16函數(shù)計算鍵的散列值，然后在用散列值對16383取余，這樣使每個鍵都可以映射到0-16383槽范圍內(nèi)。

槽節(jié)點查找

Redis計算得到鍵所對應(yīng)的槽后，需要查找槽所在的節(jié)點。集群內(nèi)通過消息交換每個節(jié)點都會知道所有節(jié)點的槽的信息。根據(jù)MOVED重定向機制，客戶端可以隨機連接集群內(nèi)的任意Redis獲取鍵的所在節(jié)點，這種客戶端叫做傀儡客戶端，它的優(yōu)點是代碼實現(xiàn)簡單，對客戶端協(xié)議影響比較小，只需要根據(jù)重定向信息再次發(fā)送請求即可。但這樣也有它的弊端，也就是每次執(zhí)行鍵命令前都要到Redis上進行重定向才能找到要執(zhí)行命令的節(jié)點。這樣就額外的增加了IO開銷。正是因為這樣的弊端所以Redis提供了另一種技術(shù)實現(xiàn)，也叫Smart(智能)客戶端，在下一篇中，我們在介紹Smart相關(guān)的內(nèi)容。

以上是“Redis請求路由的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！