Redis 集羣分片&分佈式鎖的使用

前言

前段時間的一個項目Memcache緩存切換到Redis緩存，作了些Redis緩存方面的調研與學習，在學有所得的同時向你們分享些學到的乾貨。

爲何緩存技術選型最後選擇了Redis呢，結合項目的實際狀況由一下幾點考量的

• 緩存數據的持久化，因爲Memcache數據儲存在內充中，宕機或重啓memcache服務後緩存數據丟失

• 集羣的高可用性，Memcache自身並無實現集羣功能，是經過客戶端實現的。Redis集羣在負債均衡，數據丟失容錯處理都作得比前者要好。

（Memcache與Redis技術選型比較不是本文重點,如想詳細瞭解能夠搜索相關博文）

Redis集羣分片

瞭解redis集羣數據分片咱們能夠從如下這三個問題入手

• redis集羣中key是如何分佈到各個節點？
• 客戶端如何正確找到key所在節點？
• 鍵空間遷移過程是怎樣的？

Redis集羣有16384個哈希槽(hash slot),每一個key經過CRC16校驗後對16384取模來決定放置哪一個槽.集羣的每一個節點負責一部分hash slot。舉個例子,好比當前集羣有3個節點,那麼:

• 節點 A 包含 0 到 5500 hash solt.
• 節點 B 包含5501 到 11000 hash solt.
• 節點 C 包含11001 到 16384 hash slot.

這種結構很容易添加或者刪除節點. 好比若是我想新添加個節點D, 我須要從節點 A, B, C中得部分槽到D上. 若是我想移除節點A,須要將A中的槽移到B和C節點上,而後將沒有任何槽的A節點從集羣中移除便可. 因爲從一個節點將哈希槽移動到另外一個節點並不會中止服務,因此不管添加刪除或者改變某個節點的哈希槽的數量都不會形成集羣不可用的狀態.

客戶端在查找key的所在節點時也是經過CRC16校驗後對16384取模。故此具體某個key存放在哪一個hash sort是固定的。

Redis 分佈式鎖

Redis集羣中自身沒有實現分佈式鎖，但咱們能夠經過SET命令的特性實現分佈式鎖

如下是Java版本的實例

獲取分佈式鎖的實現

釋放分佈式鎖的實現

源碼在這裏

寫在最後

學無止境，這段時間會陸續對前期的學習成果作些梳理並與你們分享，在給你們分享乾貨的同時，才疏學淺還望你們大刀予以斧正。也歡迎關注個人掘金或簡書,名稱爲柴碼