13518219792
這篇文章主要為大家展示了“redis分片機制的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Redis分片機制的示例分析”這篇文章吧。
創新互聯建站于2013年開始，是專業互聯網技術服務公司，擁有項目網站建設、網站設計網站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元朝陽做網站,已為上家服務,為朝陽各地企業和個人服務,聯系電話:13518219792
引入分片概念--分片機制的作用
而本篇文章主要談談Redis的分片機制，如果沒有分片機制，Redis就被局限于單機所支持的內存容量。Redis的分片機制允許數據拆分存放在不同的Redis實例上，每個Redis實例只包含所有鍵的子集。可以減輕單臺Redis的壓力，提升Redis擴展能力和計算能力。如果我們只使用一個Redis實例，當Redis宕機將會直接停止服務，所以我們可以采取分片機制，將原本一臺Redis實例維護的數據，改為由多個Redis實例共同維護這部分數據。
(1)范圍分片
分片需要將不同key映射到不同Redis實例上存儲，所以key的映射規則需要制定一個算法，最簡單的一個分片方案應該是范圍分片。范圍分片理解起來很簡單，比如我們存儲用戶基本信息，我們制定一個算法將用戶user_id從0到1000映射到實例A，user_id從1000到2000映射到實例B，以此類推。這個方案很輕松可以使用，但是引發了一個問題：我們需要維護user_id范圍和映射實例之間的關系。而正是這個問題導致范圍分片雖然簡單，但是效率比其他分片方案低效許多，所以Redis中一般不會使用范圍分片作為分片方案。
(2)哈希分片
比如我們目前有四個Redis實例，我們需要存儲一個key。我們可以通過哈希函數crc32()將key名轉換成一個長整型數字，然后對長整型數字對4取余，就可以得到映射的實例。但是這種分配方案一樣存在弊端：當我們需要增加或移除Redis實例時，就會造成大量key無法被命中。所以這時候出現了一種哈希分片的高級形式--一致性哈希。一致性哈希有三大特性：
key哈希結果盡可能分配到不同Redis實例。
當實例增加或移除，需要保護已映射的內容不會重新被分配到新實例上。
對key的哈希應盡量避免重復。
但是在Redis中沒有使用一致性哈希這個概念，而是引入了哈希槽。在Redis集群中共有16384個哈希槽，然后每個key通過哈希函數crc16()將key名轉化成一個長整型數字再對16384取余，最終決定這個key存儲的哈希槽。而每個Redis實例負責維護一部分哈希槽，所有實例共同維護所有的哈希槽。使用哈希槽最顯而易見的特點就是Redis實例的增加或者移除很方便，而不需要暫停所有Redis實例服務。
分片實現
上一篇談到主從切換的哨兵模式已經提到，哨兵模式可以實現高可用以及讀寫分離，但是缺點在于所有Redis實例存儲的數據全部一致，所以Redis支持cluster模式，可以簡單將cluster理解為Redis集群管理的一個插件，通過它可以實現Redis的分布式存儲。
數據分片方式一般有三種：客戶端分片、代理分片和服務器分片。
客戶端分片
定義：客戶端自己計算key需要映射到哪一個Redis實例。
優點：客戶端分片最明顯的好處在于降低了集群的復雜度，而服務器之間沒有任何關聯性，數據分片由客戶端來負責實現。
缺點：客戶端實現分片則客戶端需要知道當前集群下不同Redis實例的信息，當新增Redis實例時需要支持動態分片，多數Redis需要重啟才能實現該功能。
代理分片
定義：客戶端將請求發送到代理，代理通過計算得到需要映射的集群實例信息，然后將客戶端的請求轉發到對應的集群實例上，然后返回響應給客戶端。
優點：降低了客戶端的復雜度，客戶端不用關心后端Redis實例的狀態信息。
缺點：多了一個中間分發環節，所以對性能有些取的損失。
服務器分片
定義：客戶端可以和集群中任意Redis實例通信，當客戶端訪問某個實例時，服務器進行計算key應該映射到哪個具體的Redis實例中存儲，如果映射的實例不是當前實例，則該實例主動引導客戶端去對應實例對key進行操作。這其實是一個重定向的過程。這個過程不是從當前Redis實例轉發到對應的Redis實例，而是客戶端收到服務器通知具體映射的Redis實例重定向到映射的實例中。當前還不能完全適用于生產環境。
優點：支持高可用，任意實例都有主從，主掛了從會自動接管。
缺點：需要客戶端語言實現服務器集群協議，但是目前大多數語言都有其客戶端實現版本。
預分片
從上面可以清楚地看出，分片機制增加或移除實例是非常麻煩的一件事，所以我們可以考慮一開始就開啟32個節點實例，當我們可以新增Redis服務器時，我們可以將一半的節點移動到新的Redis服務器。這樣我們只需要在新服務器啟動一個空節點，然后移動數據，配置新節點為源節點的從節點，然后更新被移動節點的ip信息，然后向新服務器發送slaveof命令關閉主從配置，最后關閉舊服務器不需要使用的實例并且重新啟動客戶端。這樣我們就可以在幾乎不需要停機時間時完成數據的移動。
分片機制的缺點
分片是由多臺Redis實例共同運轉，所以如果其中一個Redis實例宕機，則整個分片都將無法使用，所以分片機制無法實現高可用。
如果有不同的key映射到不同的Redis實例，這時候不能對這兩個key做交集或者使用事務。
使用分片機制因為涉及多實例，數據處理比較復雜。
分片中對于實例的添加或刪除會很復雜，不過可以使用預分片技術進行改善。
以上是“Redis分片機制的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注創新互聯行業資訊頻道！
