豁達是正確樂觀的面對失敗的系統。不需要過多的擔心，需要一種去說那又怎樣的能力。因此架構的設計是如此的重要。許多優秀的系統沒有進一步成長的能力，我們應該做的是使用其他的系統去共同分擔工作。

Redis是其中一個吸引我的系統，一個持久性的，鍵值對存儲內存操作高性能的平臺。它是一個優秀的鍵值對數據庫。我已經在使用了。即使AWS最近宣布開始支持 ElasticCache的下級緩存。但是一個無主的redis集群仍然起著重要的作用。我們需要多系統去完成工作。同時，我們能夠集合多種組件在一個容錯和無主的集群里共同工作么？在這片文章中我將介紹夢幻般的redis。

一致哈希

構建一個存儲數據集群的關鍵是有一個有效的數據存儲和復制機制。我希望通過一個行之有效的方法來說明建造一個數據集群，在這個過程中你可以隨意添加或移除一個Redis節點，同時保證你的數據仍然存在，而不會消失。這個方法稱為一致哈希。

由于它不是一個很明顯的概念，我將用一點時間來解釋一下。為了理解一致哈希，你可以想像有一個函數f（x），對于給定的x總是返回一個1到60（為什么是 60？你會知道的，但現在請等等）之間的結果，同樣對于一個唯一的x，f（x）總是返回相同的結果。這些1到60的值按順時針排成一個環。

現在集群中的每個節點都需要一個唯一的名字。所以如果你將這個名字傳遞給f（''），它將返回一個1到60之間的數字（包括1和60），這個數字就是節點在環上的位置。當然它只是節點的邏輯（記錄的）位置。這樣，你獲得一個節點，將它傳給哈希函數，獲得結果并將它放到環上。是不是很簡單？這樣每個節點都在環上有了它自己的位置。假設這里有5個Redis節點，名字分別為'a'，'b'，'c'，'d'，'e'。每個節點都傳給哈希函數f（x）并且放到了環上。在這里 f（'a'） = 21, f（'b'） = 49, f（'c'） = 11, f（'d'） = 40, f（'e'） = 57。一定記得這里位置是邏輯位置。

那么，我們為什么要將節點放在一個環上呢？將節點放到環上的目的是確定擁有哪些哈?？臻g。圖中的節點'd'擁有的哈?？臻g就是f（'a'）到f（'d'）（其值為40）之間的部分，包括f（'d'），即（21, 40]。也就是說節點'd'將擁有鍵x，如果f（x）的屬于區間（21, 40】。比如鍵‘apple’，其值f（'apple'） = 35，那么鍵'apple'將被存在'd'節點。類似的，每個存儲在集群上的鍵都會通過哈希函數，在環上按順時針方向被恰當地存到最近的節點。

雖然一致哈希講完了，但應知道，在多數情況下，這種類型的系統是伴隨著高可用性而構建。為了滿足數據的高可用性，需要根據一些因子進行復制，這些因子稱為復制因子。假設我們集群的復制因子為2，那么屬于'd'節點的數據將會被復制到按順時針方向與之相隔最近的'b'和'e'節點上。這就保證了如果從'd'節點獲取數據失敗，這些數據能夠從'b'或'e'節點獲取。

不僅僅是鍵使用一致哈希來存儲，也很容易覆蓋失敗了的節點，并且復制因子依然完好有效。比如'd'節點失敗了，'b'節點將獲取'd'節點哈?？臻g的所有權，同時'd'節點的哈?？臻g能夠很容易地復制到'c'節點。

壞事和好事

壞事就是目前這些討論過的所有概念，復制（冗余），失效處理以及集群規模等，在Redis之外是不可行的。一致哈希僅僅描述了節點在哈希環上的映射以及那些哈希數據的所有權，盡管這樣，它仍然是構建一個彈性可擴展系統的極好的開端。

好事就是，也有一些分立的其他工具在Redis集群上實現一致哈希，它們能提醒節點失效和新節點的加入。雖然這個功能不是一個工具的一部分，我們將看到如何用多個系統來使一個理想化的Redis集群運轉起來。

Twemproxy aka Nutcracker

Twemproxy是一個開源工具，它是一個基于memcached和Redis協議的快速、輕量的代理。其本質就是，如果你有一些Redis服務器在運行，同時希望用這些服務器構建集群，你只需要將Twemproxy部署在這些服務器前端，并且讓所有Redis流量都通過它。

Twemproxy除了能夠代理Redis流量外，在它存儲數據在Redis服務器時還能進行一致哈希。這就保證了數據被分布在基于一致哈希的多個不同Redis節點上。

但是Twemproxy并沒有為Redis集群建立高可用性支持。最簡單的辦法是為集群中的每個節點都建立一個從（冗余）服務器，當主服務器失效時將從（冗余）服務器提升為主服務器。為Redis配置一個從服務器是非常簡單的。

這種模型的缺點是非常明顯的，它需要為Redis集群中的每個節點同時運行兩個服務器。但是節點失效也是非常明顯，并且更加危險，所以我們怎么知道這些問題并解決。

Gossip on Serf

Gossip是一個標準的機制，通過這個機制集群上的節點可以很清楚的了解成員的最新情況。這樣子集群中的每個節點就很清楚集群中節點的變化，如節點的新增和節目的刪除。

Serf通過實現Gossip機制提供這樣的幫助。Serf是一個基于代理的機制，這個機制實現了Gossip的協議達到節點成員信息交換的目的。Serf是不斷運行，除此之外，它還可以生成自定義的事件

現在拿我們的節點集群為例，如果每個節點上也有一個serf代理正在運行,那么節點與節點之間可以進行細節交換.因此，群集中的每個節點都能清楚知道其他節點的存在，也能清楚知道他們的狀態。

這還并不夠，為了高可靠性我們還需要讓twemproxy知道何時一個節點已經失效，這樣的話它就可以據此修改它的配置。像前面提到的Serf，就可以做到這一點，它是基于一些gossip觸發的事件，使用自定義動作實現的。因此只要集群中的一個Redis節點因為一些原因宕掉了，另一個節點就可以發送有成員意外掉線的消息給任何給定的端點，這個端點在我們的案例中也就是twemproxy服務器。

這還不是全部

現在我們有了Redis集群，基于一致性哈希環，相應的是用twemproxy存儲數據（一致性哈希），還有Serf，它用gossip協議來檢測Redis集群成員失效，并且向twemproxy發送失效消息；但是我們還沒有建立起理想化的Redis集群。

消息偵聽器

雖然Serf可以給任何端點發送成員離線或者成員上線消息。然而twemproxy卻沒有偵聽此類事件的機制。因此我們需要自定義一個偵聽器，就像Redis-Twenproxy代理，它需要做以下這些事情。

偵聽Serf消息
更新nutcraker.yml 以反映新的拓撲
重啟twemproxy

這個消息偵聽器可以是一個小型的http服務器；它在收到一批POST數據的時候，為twemproxy做以上列表中的動作。需要記住的是，這種消息應該是一個原子操作；因為當一個節點失效（或者意外離線）的時候，所有能發消息的活動節點都將發送這個失效事件消息給偵聽器；但是偵聽器應該只響應一次。

數據復制

在上面的“一致哈希”中，我提到了Redis集群中的復制因素。同樣它也不是Twemproxy的固有特性；Twemproxy只關心使用一致哈希存儲一個拷貝。所以在我們追求理想化Redis集群的過程中，我們還需要給twemproxy或者redis自己創建這種復制的能力。

為了給Twenproxy創建復制能力，需要將復制因子作為一個配置項目，并且將數據保存在集群中相鄰的redis節點（根據復制因子）。由于twemproxy知道節點的位置，所以這將給twemproxy增加一個很棒的功能。

由于twemproxy只不過是代理服務器，它的簡單功能就是它強大的地方，為它創建復制管理功能將使它臃腫膨脹。

Redis 主從環

在思考這其中的工作機制的時候，我忽然想到，為什么不將每個節點設置成另一個節點的副本，或者說從節點，并由此而形成一個主從環呢？

這樣的話如果一個節點失效了，失效節點的數據在這個環上相鄰的節點上仍然可以獲得。而那個具有該數據副本的節點，將作為該節點的從節點，并提供保存數據副本的服務。這是一個既是主節點也是從節點的環。Serf仍像通常一樣作為散布節點失效消息的代理。但是這一回，我們twenproxy上的的客戶端，即偵聽器，將不僅僅只更新twenproxy上的失效信息，還要調整redis服務器群集來適應這個變化。

在這個環中有一個明顯的，同樣也是技術方面的缺陷。這個明顯的缺陷是，這個環會壞掉，因為從節點的從節點無法判別哪一個是它的主節點的數據，哪一個是它的主節點的主節點的數據。這樣的話就會循環的傳送所有的數據。

同樣技術性的問題是，一旦redis將主節點的數據同步給從節點，它就會將從節點的數據擦除干凈；這樣就將曾經寫到從節點的所有數據刪除了。這種主從環顯然不能實際應用，除非修改主從環的復制機制以適應我們的需求。這樣的話每個從節點就不會將它的主節點的數據同步給它的從節點。要想實現這一點，必須的條件是每個節點都可以區分出自己的密鑰空間，以及它的主節點的密鑰空間；這樣的話它就不會將主節點的數據傳送給它的從節點。