redis哈希演算法

① Redis怎麼做集群

為什麼集群？

通常，為了提高網站響應速度，總是把熱點數據保存在內存中而不是直接從後端資料庫中讀取。Redis是一個很好的Cache工具。大型網站應用，熱點數據量往往巨大，幾十G上百G是很正常的事兒，在這種情況下，如何正確架構Redis呢？

首先，無論我們是使用自己的物理主機，還是使用雲服務主機，內存資源往往是有限制的，scale up不是一個好辦法，我們需要scale out橫向可伸縮擴展，這需要由多台主機協同提供服務，即分布式多個Redis實例協同運行。

其次，目前硬體資源成本降低，多核CPU，幾十G內存的主機很普遍，對於主進程是單線程工作的Redis，只運行一個實例就顯得有些浪費。同時，管理一個巨大內存不如管理相對較小的內存高效。因此，實際使用中，通常一台機器上同時跑多個Redis實例。

方案

1.Redis官方集群方案 Redis Cluster

Redis Cluster是一種伺服器Sharding技術，3.0版本開始正式提供。

Redis Cluster中，Sharding採用slot(槽)的概念，一共分成16384個槽，這有點兒類pre sharding思路。對於每個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一個中。使用的hash演算法也比較簡單，就是CRC16後16384取模。

Redis集群中的每個node(節點)負責分攤這16384個slot中的一部分，也就是說，每個slot都對應一個node負責處理。當動態添加或減少node節點時，需要將16384個槽做個再分配，槽中的鍵值也要遷移。當然，這一過程，在目前實現中，還處於半自動狀態，需要人工介入。

Redis集群，要保證16384個槽對應的node都正常工作，如果某個node發生故障，那它負責的slots也就失效，整個集群將不能工作。

為了增加集群的可訪問性，官方推薦的方案是將node配置成主從結構，即一個master主節點，掛n個slave從節點。這時，如果主節點失效，Redis Cluster會根據選舉演算法從slave節點中選擇一個上升為主節點，整個集群繼續對外提供服務。這非常類似前篇文章提到的Redis Sharding場景下伺服器節點通過Sentinel監控架構成主從結構，只是Redis Cluster本身提供了故障轉移容錯的能力。

Redis Cluster的新節點識別能力、故障判斷及故障轉移能力是通過集群中的每個node都在和其它nodes進行通信，這被稱為集群匯流排(cluster bus)。它們使用特殊的埠號，即對外服務埠號加10000。例如如果某個node的埠號是6379，那麼它與其它nodes通信的埠號是16379。nodes之間的通信採用特殊的二進制協議。

對客戶端來說，整個cluster被看做是一個整體，客戶端可以連接任意一個node進行操作，就像操作單一Redis實例一樣，當客戶端操作的key沒有分配到該node上時，Redis會返回轉向指令，指向正確的node，這有點兒像瀏覽器頁面的302 redirect跳轉。

Redis Cluster是Redis 3.0以後才正式推出，時間較晚，目前能證明在大規模生產環境下成功的案例還不是很多，需要時間檢驗。

2.Redis Sharding集群

Redis 3正式推出了官方集群技術，解決了多Redis實例協同服務問題。Redis Cluster可以說是服務端Sharding分片技術的體現，即將鍵值按照一定演算法合理分配到各個實例分片上，同時各個實例節點協調溝通，共同對外承擔一致服務。

多Redis實例服務，比單Redis實例要復雜的多，這涉及到定位、協同、容錯、擴容等技術難題。這里，我們介紹一種輕量級的客戶端Redis Sharding技術。

Redis Sharding可以說是Redis Cluster出來之前，業界普遍使用的多Redis實例集群方法。其主要思想是採用哈希演算法將Redis數據的key進行散列，通過hash函數，特定的key會映射到特定的Redis節點上。這樣，客戶端就知道該向哪個Redis節點操作數據。

慶幸的是，java redis客戶端驅動jedis，已支持Redis Sharding功能，即ShardedJedis以及結合緩存池的ShardedJedisPool。

Jedis的Redis Sharding實現具有如下特點：

1. 採用一致性哈希演算法(consistent hashing)，將key和節點name同時hashing，然後進行映射匹配，採用的演算法是MURMUR_HASH。採用一致性哈希而不是採用簡單類似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的rehashing。一致性哈希隻影響相鄰節點key分配，影響量小。

2.為了避免一致性哈希隻影響相鄰節點造成節點分配壓力，ShardedJedis會對每個Redis節點根據名字(沒有，Jedis會賦予預設名字)會虛擬化出160個虛擬節點進行散列。根據權重weight，也可虛擬化出160倍數的虛擬節點。用虛擬節點做映射匹配，可以在增加或減少Redis節點時，key在各Redis節點移動再分配更均勻，而不是只有相鄰節點受影響。

3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，這樣通過合理命名key，可以將一組相關聯的key放入同一個Redis節點，這在避免跨節點訪問相關數據時很重要。

② redis使用什麼演算法來解決hash沖突

因為Memcached的哈希策略是在其客戶端實現的，因此不同的客戶端實現也有區別，以Spymemcache、Xmemcache為例，都是使用了KETAMA作為其實現。
因此，我們也可以使用一致性hash演算法來解決Redis分布式這個問題。在介紹一致性hash演算法之前，先介紹一下我之前想的一個方法，怎麼把Key均勻的映射到多台Redis Server上。

③ redis集群使用一致性hash嗎

使用。

設定一個圓環上 0-2^3̂2-1 的點，每個點對應一個緩存區，每個鍵值對存儲的位置也經哈希計算後對應到環上節點。但現實中不可能有如此多的節點，所以倘若鍵值對經哈希計算後對應的位置沒有節點，那麼順時針找一個節點存儲它。

1、考慮增加伺服器節點的情況，該節點順時針方向的數據仍然被存儲到順時針方向的節點上，但它逆時針方向的數據被存儲到它自己。這時候只有部分數據會失效，被映射到新的緩存區。

2、考慮節點減少的情況。該缺失節點順時針方向上的數據仍然被存儲到其順時針方向上的節點，設為 beta，其逆時針方向上的數據會被存儲到 beta 上。同樣，只有有部分數據失效，被重新映射到新的伺服器節點。

(3)redis哈希演算法擴展閱讀：

一致性哈希演算法

這種方法可以應對節點失效的情況，當某個分布式集群節點宕機，服務請求可以通過hash演算法重新分配到其他可用的伺服器上。避免了無法處理請求的狀況出現 。

但這種方法的缺陷也很明顯，如果伺服器中保存有服務請求對應的數據，那麼如果重新計算請求的hash值，會造成大量的請求被重定位到不同的伺服器而造成請求所要使用的數據失效，這種情況在分布式系統中是非常糟糕的。

一個設計良好的分布式系統應該具有良好的單調性，即伺服器的添加與移除不會造成大量的哈希重定位，而一致性哈希恰好可以解決這個問題。

④ 分布式redis怎麼保證數據一致性

Redis 默認是單機環境使用的。數據量較大時需要shard（多機環境），這個時候要用ShardedJedis。ShardedJedis是基於一致性哈希演算法實現的分布式Redis集群客戶端

⑤ redis的分片能存在相同的key嗎

不能。redis的分片採用的是一致性哈希演算法，對於相同的key肯定是能唯一分配到同一個redis-server，而同一個redis-server是不允許有相同key的。

⑥ redis自帶的集群為什麼不用一致性哈希演算法

答：1、內存中對象說的是對象類型的數據還是就單純的是存入的數據？一般String使用setex()命令進行插入有時效的value； 2、作為NOSQL的代表，redis性能還是很不錯的，一般不用管道的話，讀寫同時處理10000次/秒不在話下，用上管道經過本人測試20...