Redis搭建(四):Sharding集群模式
一、 方案
1. 介紹
redis集群分為服務端集群(Cluster)和客戶端分片(Sharding)
服務端集群:redis3.0以上版本實現,使用哈希槽,計算key的CRC16結果再模16834。此處暫不介紹
客戶端分片:3.0以下使用,采用Key的一致性hash算法來區分key存儲在哪個Redis實例上。每個Redis實例彼此獨立,使用ShardedJedisPool
2. Sharding存在兩個問題
單點故障問題:當集群中的某一臺服務掛掉之后,客戶端在根據一致性hash無法從這臺服務器獲取數據。對于單點故障問題,我們可以使用Redis的HA高可用來實現。利用Redis-Sentinal來通知主從服務的切換。
擴容問題:因為使用了一致性哈稀進行分片,那么不同的key分布到不同的Redis-Server上,當我們需要擴容時,需要增加機器到分片列表中,這時候會使得同樣的key算出來落到跟原來不同的機器上,這樣如果要取某一個值,會出現取不到的情況,之前的緩存相當于全部失效。對于擴容問題,Redis的作者提出了一種名為Pre-Sharding的方式。即事先部署足夠多的Redis服務。
3. 一致性hash算法(Consistent hashing)
環形hash空間,早在1997年就在論文《Consistent hashing and random trees》提出
虛擬節點(解決hash傾斜性,多些虛擬節點)
命中率計算公式:(1-n/(n+m)*100% (n:服務器數,m:新增的服務器數)
二、 Sharding解決辦法
1. 單點故障問題解決:
使用Redis主從復制的功能,兩臺物理主機上分別都運行有Redis-Server,其中一個Redis-Server是另一個的從庫,采用雙機熱備技術,客戶端通過虛擬IP訪問主庫的物理IP,當主庫宕機時,切換到從庫的物理IP。只是事后修復主庫時,應該將之前的從庫改為主庫(使用命令slaveof no one),主庫變為其從庫(使用命令slaveof IP PORT),這樣才能保證修復期間新增數據的一致性。
2. 通過pre-sharding進行Redis在線擴容。
解決動態擴容和數據分區的問題,實際就是在同一臺機器上部署多個Redis實例的方式,當容量不夠時將多個實例拆分到不同的機器上,這樣實際就達到了擴容的效果。Pre-Sharding方法是將每一個臺物理機上,運行多個不同端口的Redis實例,假如有三個物理機,每個物理機運行三個Redis實例,那么我們的分片列表中實際有9個Redis實例,當我們需要擴容時,增加一臺物理機來代替9個中的一個redis,有人說,這樣不還是9個么,是的,但是以前服務器上面有三個redis,壓力很大的,這樣做,相當于單獨分離出來并且將數據一起copy給新的服務器。值得注意的是,還需要修改客戶端被代替的redis的IP和端口為現在新的服務器,只要順序不變,不會影響一致性哈希分片。
拆分過程如下:
在新機器上啟動好對應端口的Redis實例。
配置新端口為待遷移端口的從庫。
待復制完成,與主庫完成同步后,切換所有客戶端配置到新的從庫的端口。
配置從庫為新的主庫。
移除老的端口實例。
重復上述過程遷移好所有的端口到指定服務器上。
以上拆分流程是Redis作者提出的一個平滑遷移的過程,不過該拆分方法還是很依賴Redis本身的復制功能的,如果主庫快照數據文件過大,這個復制的過程也會很久,同時會給主庫帶來壓力。所以做這個拆分的過程最好選擇為業務訪問低峰時段進行。
三、實現
打開redis.conf,修改端口號,避免端口沖突
啟動多個Redis實例,每個Redis彼此獨立
使用RedisShardedPool增加多個Redis
總結
以上是生活随笔為你收集整理的Redis搭建(四):Sharding集群模式的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 特性(摘要)
- 下一篇: 《哈迪斯 2》明年二季度 PC 上线抢先