Redis-集羣 - 分片

Redis是一個基於內存的數據庫，其不只讀寫速度快，每秒能夠執行大約110000的寫操做，81000的讀取操做，並且其支持存儲字符串，哈希結構，鏈表，集合豐富的數據類型。因此獲得不少開發者的青睞。加之其支持主從、持久化等功能，3.0版本開始正式提供分片技術、讓其在大型互聯網應用中大顯身手

 

分片（parttitioning）就是將你的數據拆分到多個redis實例的過程，這樣每一個實例只包含全部鍵的子集，

 

分片的目的：

一、容許使用不少電腦內存綜合來支持更大的數據庫，沒有分片你就被侷限於單機能支持的內存容量

二、容許伸縮計算到多核和多服務器，伸縮網絡帶寬到多服務器或者多網絡適配器

 

拓展

（

Redis採用的是基於內存的採用的是單進程單線程模型的KV數據庫，由C語言編寫。官方提供的數據是能夠達到100000+的qps。這個數據不比採用單進程多線程的一樣基於內存的KV數據庫Memcached差。

Redis快的主要緣由是：

1. 徹底基於內存
2. 數據結構簡單，對數據操做也簡單
3. 使用多路 I/O 複用模型

單進程單線程好處

1. 代碼更清晰，處理邏輯更簡單
2. 不用去考慮各類鎖的問題，不存在加鎖釋放鎖操做，沒有由於可能出現死鎖而致使的性能消耗
3. 不存在多進程或者多線程致使的切換而消耗CPU

單進程單線程弊端

1. 沒法發揮多核CPU性能，不過能夠經過在單機開多個Redis實例來完善；

）

 

分片的基礎

一、範圍分片

二、哈希分片

 

分片的不一樣實現

一、客戶端分片：客戶端直接選擇正確的節點來寫入和讀取指定鍵，許多Redis客戶端實現了客戶端的分析

二、代理協助分片：客戶端發送一個請求到一個能夠理解Redis協議的代理上，而不是直接發送請求到

Redis實例上，代理會根據配置好的分片模式，來保證轉發咱們的請求到正確的Redis實例，並返回給客戶端，Redis和Memcached的代理Twemproxy實現了代理協助分片

三、查詢路由分片：你能夠發送你的查詢到一個隨機實例，這個實例會保證轉發你的查詢到正確的節點，Redis集羣在客戶端的幫助下，實現了查詢路由的一種混合形式（請求不是直接從Redis實例轉發到另外一個，而是客戶端收到重定向到正確的節點）。

四、在服務端進行分片即Redis官方集羣分片方案 Redis Cluster

 

理論講完，就來點幹活

最近公司打算作redis集羣分片，研究了下redis 自帶的clutesr 功能真的很強大，惟一的不足之處就是當其中一個分片服務器掛掉的話整個集羣就會宕機，處於系統不可用狀態

官網分片方案，很不錯可是要保證數據備份，作redis 災備方案，會比較麻煩，並且須要不少臺服務器，redis搭建cluster分片服務起須要針對每臺分片搭建主從配置方案，實現自動切換從而解決相關問題，相關主從的配置還有須要搭建redis sentinel哨兵服務,致使整個集羣變得愈來愈複雜維護成本愈來愈高，因此爲了解決這個問題，就打算經過客戶端分片的方式實現該功能，減小運維壓力

 

一致性哈希算法實現redis的數據分片橫向擴展

翻閱資料發現java 有現成的jredis客戶端分片方案，C#比較悲哀只能本身實現，其實jedis實現實現分片方式是經過一致性哈希算法實現的集羣分片，裝模作樣照搬實現方式，備份經過兩次哈希鍵值達到備份的目的

那麼什麼是一致性哈希算法呢？網上有不少資料，我講講本身的簡單理解

redis 是鍵值對數據存儲的一種數據庫，咱們在存出數據的時候要將數據均勻的分佈在多個服務器上面，而且在增長減小cache server後，cache的遷移作到最少。

那麼一致性hash算法就是爲了實現這個功能設計的

具體算法代碼參見
https://git.oschina.net/hl.wei/RedisCluster.git
一致性哈希算法能夠實現數據散列到均衡的服務器，可以最大限度的達到增減服務器的時候數據散列問題影響至最小。

實際應用中減小服務器添加，刪除，形成的數據丟失問題，可使用以下方案：
假如咱們有 A，B，C 三臺服務器，咱們在三臺服務器上面天天搭建三個redis 實例，等於建立了 有9臺redis 實例，當咱們添加新機器的時候就能夠直接映射一臺服務器到 其中一個實例，對該服務器數據進行遷移達到數據零偏差完美遷移的目的。