IT豆豆2017-08-10 23:06:24Redis是單執行緒，但是一般的作為快取使用的話，redis足夠了，因為它的讀寫速度太快了。
官方的一個簡單測試：
測試完成了50個併發執行100000個請求。
設定和獲取的值是一個256位元組字串。
結果：讀的速度是110000次/s，寫的速度是81000次/s
在這麼快的讀寫速度下，對於一般程式來說足夠用了，但是對於訪問量特別大的網站來說，還是稍有不足。那麼，如何提升redis的效能呢？看標題就知道了，搭建叢集。
3。0版本之前
3。0版本之前的redis是不支援叢集的，我們的徐子睿老師說，那個時候，我們的redis如果想要叢集的話，就需要一箇中間件，然後這個中介軟體負責將我們需要存入redis中的資料的key透過一套演算法計算得出一個值。然後根據這個值找到對應的redis節點，將這些資料存在這個redis的節點中。
在取值的時候，同樣先將key進行計算，得到對應的值，然後就去找對應的redis節點，從對應的節點中取出對應的值。
這樣做有很多不好的地方，比如說我們的這些計算都需要在系統中去進行，所以會增加系統的負擔。還有就是這種叢集模式下，某個節點掛掉，其他的節點無法知道。而且也不容易對每個節點進行負載均衡。
3。0版本及以後
先來一張redis叢集的架構圖：
在這個圖中，每一個藍色的圈都代表著一個redis的伺服器節點。它們任何兩個節點之間都是相互連通的。客戶端可以與任何一個節點相連線，然後就可以訪問叢集中的任何一個節點。對其進行存取和其他操作。
那麼redis是怎麼做到的呢？首先，在redis的每一個節點上，都有這麼兩個東西，一個是插槽（slot）可以理解為是一個可以儲存兩個數值的一個變數這個變數的取值範圍是：0-16383。還有一個就是cluster我個人把這個cluster理解為是一個叢集管理的外掛。當我們的存取的key到達的時候，redis會根據crc16的演算法得出一個結果，然後把結果對 16384 求餘數，這樣每個 key 都會對應一個編號在 0-16383 之間的雜湊槽，透過這個值，去找到對應的插槽所對應的節點，然後直接自動跳轉到這個對應的節點上進行存取操作。
還有就是因為如果叢集的話，是有好多個redis一起工作的，那麼，就需要這個叢集不是那麼容易掛掉，所以呢，理論上就應該給叢集中的每個節點至少一個備用的redis服務。這個備用的redis稱為從節點（slave）。那麼這個叢集是如何判斷是否有某個節點掛掉了呢？
首先要說的是，每一個節點都存有這個叢集所有主節點以及從節點的資訊。
它們之間透過互相的ping-pong判斷是否節點可以連線上。如果有一半以上的節點去ping一個節點的時候沒有迴應，叢集就認為這個節點宕機了，然後去連線它的備用節點。如果某個節點和所有從節點全部掛掉，我們叢集就進入faill狀態。還有就是如果有一半以上的主節點宕機，那麼我們叢集同樣進入發力了狀態。這就是我們的redis的投票機制，具體原理如下圖所示：
（1）投票過程是叢集中所有master參與，如果半數以上master節點與master節點通訊超時（cluster-node-timeout），認為當前master節點掛掉。
（2）：什麼時候整個叢集不可用（cluster_state：fail）？
a：如果叢集任意master掛掉，且當前master沒有slave。叢集進入fail狀態，也可以理解成叢集的slot對映［0-16383］不完整時進入fail狀態。 ps ： redis-3。0。0。rc1加入cluster-require-full-coverage引數，預設關閉，開啟叢集相容部分失敗。
b：如果叢集超過半數以上master掛掉，無論是否有slave，叢集進入fail狀態。
小鳥攻城獅2018-04-29 23:48:18謝邀。
說到redis叢集，那必須從redis spec說起。
M打頭的是master，S打頭的是slave。
redis spec
Redis叢集
設計的主要特性、基本原理和Redis叢集目標
Redis叢集是Redis的一個分散式實現，具有以下目標，按照設計中的重要性排序：
高效能和線性可擴充套件性，支援最大1000個節點的叢集。叢集中，沒有代理，使用非同步複製，並且沒有對值執行合併操作。
可接受的寫入安全程度：系統嘗試（以盡力而為的方式）保留源自與大多數主節點連線的客戶端的所有寫入。通常會有小機率的，寫ack丟失。當客戶端處於少數分割槽（腦裂）時，ack丟失機率會更大。
可用性：Redis群集能夠在大部分主節點都可以訪問的分割槽中存活，並且每個不再可訪問的主節點至少有一個可訪問的從節點。此外，使用副本遷移，任何從節點不再複製的主伺服器將從多個從從節點所覆蓋的主伺服器接收資料。
截至目前，spec本文件中描述的內容在Redis 3。0或更高版本中已經實現。
通俗解釋
Redis非常擅長，在高可用性服務裡必不可少。 自2015年4月釋出3。0。0以來，它已經支援群集。將許多redis伺服器集中在一起可以實現更高的吞吐量（擴充套件負載）以及冗餘（用於伺服器意外宕機時）。
工作前景
就目前我在的廠裡而言：
redis叢集的工作前景還是可觀的，但需求量不大。基本的職位是，redis叢集的開發工程師，維護工程師。
基本在大公司裡需要，小公司都是兼具。
以下是搜尋的職位資訊，也不多，22個相關的。
百度的redis叢集
百度的redis叢集倒是有不少人從開始開發，到測試，到維護。
名稱叫bdrp。BDRP（baidu distributed redis platform）是包含twemproxy，redis，redis-sentinel 等多個模組開發的分散式 redis 平臺。
感興趣的，請關注，以後解讀。
歡迎關注，解鎖更多，共同進步！
張棟847464822017-08-10 11:54:08謝謝邀請！Redis叢集可以用來做資料快取，可以減輕資料庫的壓力，另外可以加快資料查詢的速度，使用者去一個網站去訪問資料，網站會先去redis 集群裡面去找，如果有相應的資料，也直接返回給使用者，如果改集群裡面沒有，則去資料庫裡面去查詢，並且返給使用者，並且存入redis快取，並且redis會不定期的進行資料備份，所以相對於mencached資料就比較安全，所以在我看來redis的工作前景還是很明亮的！
偶爾來逛逛隨便來瞧瞧2017-08-15 20:07:06還有這工作？redis只是很小的資料庫分支，雖然這幾年nosql發展很快，但商用範圍內還是關係型的天下，redis大多數淪落到當快取來使用，即使是持久化，在我們的專案中也只作為中間或臨時資料儲存，最終資料仍會放到Oracle中，如果想做叢集，個人但是建議你看看pika，360出品的開源，雖然這個公司本人不是太欣賞，但這套做的還可以