redis cluster搭建起來了

redis cluster，提供了多個master，資料可以分散式儲存在多個master上; 每個master都帶著slave，自動就做讀寫分離; 每個master如果故障，那麼久會自動將slave切換成master，高可用

redis cluster的基本功能，來測試一下

1、實驗多master寫入 -> 海量資料的分散式儲存

你在redis cluster寫入資料的時候，其實是你可以將請求傳送到任意一個master上去執行

但是，每個master都會計算這個key對應的CRC16值，然後對16384個hashslot取模，找到key對應的hashslot，找到hashslot對應的master

如果對應的master就在自己本地的話，set mykey1 v1，mykey1這個key對應的hashslot就在自己本地，那麼自己就處理掉了

但是如果計算出來的hashslot在其他master上，那麼就會給客戶端返回一個moved error，告訴你，你得到哪個master上去執行這條寫入的命令

什麼叫做多master的寫入，就是每條資料只能存在於一個master上，不同的master負責儲存不同的資料，分散式的資料儲存

100w條資料，5個master，每個master就負責儲存20w條資料，分散式資料儲存

大型的java系統架構，還專注在大資料系統架構，分散式，分散式儲存，hadoop hdfs，分散式資源排程，hadoop yarn，分散式計算，hadoop mapreduce/hive

分散式的nosql資料庫，hbase，分散式的協調，zookeeper，分散式通用計算引擎，spark，分散式的實時計算引擎，storm

如果你要處理海量資料，就涉及到了一個名詞，叫做大資料，只要涉及到大資料，那麼其實就會涉及到分散式

redis cluster，分散式

因為我來講java系統的架構，有時候跟其他人不一樣，純搞java，但是我因為工作時間很長，早期專注做java架構，好多年，大資料興起，就一直專注大資料系統架構

大資料相關的系統，也涉及很多的java系統架構，高併發、高可用、高效能、可擴充套件、分散式系統

會給大家稍微拓展一下知識面，從不同的角度去講解一塊知識

redis，高併發、高效能、每日上億流量的大型電商網站的商品詳情頁系統的快取架構，來講解的，redis是作為大規模快取架構中的底層的核心儲存的支援

高併發、高效能、每日上億流量，redis持久化 -> 災難的時候，做資料恢復，複製 -> 讀寫分離，擴容slave，支撐更高的讀吞吐，redis怎麼支撐讀QPS超過10萬，幾十萬; 哨兵，在redis主從，一主多從，怎麼保證99.99%可用性; redis cluster，海量資料

java架構課，架構思路和設計是很重要的，但是另外一點，我希望能夠帶著大家用真正java架構師的角度去看待一些技術，而不是僅僅停留在技術的一些細節的點

給大家從一些大資料的角度，去分析一下我們java架構領域中的一些技術

天下武功，都出自一脈，研究過各種大資料的系統，redis cluster講解了很多原理，跟elasticsearch，很多底層的分散式原理，都是類似的

redis AOF，fsync

elasticsearch建立索引的時候，先寫記憶體快取，每秒鐘把資料刷入os cache，接下來再每隔一定時間fsync到磁碟上去

redis cluster，寫可以到任意master，任意master計算key的hashslot以後，告訴client，重定向，路由到其他mater去執行，分散式儲存的一個經典的做法

elasticsearch，建立索引的時候，也會根據doc id/routing value，做路由，路由到某個其他節點，重定向到其他節點去執行

分散式的一些，hadoop，spark，storm裡面很多核心的思想都是類似的

後面，馬上把redis架構給講完之後，就開始講解業務系統的開發，包括高併發的商品詳情頁系統的大型的快取架構，jedis cluster相關api去封裝和測試對redis cluster的訪問

jedis cluster api，就可以自動針對多個master進行寫入和讀取

2、實驗不同master各自的slave讀取 -> 讀寫分離

在這個redis cluster中，如果你要在slave讀取資料，那麼需要帶上readonly指令，get mykey1

redis-cli -c啟動，就會自動進行各種底層的重定向的操作

實驗redis cluster的讀寫分離的時候，會發現有一定的限制性，預設情況下，redis cluster的核心的理念，主要是用slave做高可用的，每個master掛一兩個slave，主要是做資料的熱備，還有master故障時的主備切換，實現高可用的

redis cluster預設是不支援slave節點讀或者寫的，跟我們手動基於replication搭建的主從架構不一樣的

slave node，readonly，get，這個時候才能在slave node進行讀取

redis cluster，主從架構是出來，讀寫分離，複雜了點，也可以做，jedis客戶端，對redis cluster的讀寫分離支援不太好的

預設的話就是讀和寫都到master上去執行的

如果你要讓最流行的jedis做redis cluster的讀寫分離的訪問，那可能還得自己修改一點jedis的原始碼，成本比較高

要不然你就是自己基於jedis，封裝一下，自己做一個redis cluster的讀寫分離的訪問api

核心的思路，就是說，redis cluster的時候，就沒有所謂的讀寫分離的概念了

讀寫分離，是為了什麼，主要是因為要建立一主多從的架構，才能橫向任意擴充套件slave node去支撐更大的讀吞吐量

redis cluster的架構下，實際上本身master就是可以任意擴充套件的，你如果要支撐更大的讀吞吐量，或者寫吞吐量，或者資料量，都可以直接對master進行橫向擴充套件就可以了

也可以實現支撐更高的讀吞吐的效果

不會去跟大家直接講解的，很多東西都要帶著一些疑問，未知，實際經過一些實驗和操作之後，讓你體會的更加深刻一些

redis cluster，主從架構，讀寫分離，沒說錯，沒有撒謊

redis cluster，不太好，server層面，jedis client層面，對master做擴容，所以說擴容master，跟之前擴容slave，效果是一樣的

3、實驗自動故障切換 -> 高可用性

redis-trib.rb check 192.168.31.187:7001

比如把master1，187:7001，殺掉，看看它對應的19:7004能不能自動切換成master，可以自動切換

切換成master後的19:7004，可以直接讀取資料

再試著把187:7001給重新啟動，恢復過來，自動作為slave掛載到了19:7004上面去