redis5.0.0功能介紹以及主從集羣、哨兵搭建

這兩天忽然想起redis，索性就再嘗試一下搭建最新版本的redis，過程有點艱辛呀，記錄一下，供本身和你們從此搭建作參考。

1、爲何用Redis？

　　我本身總結了一下：

　　一、基於內存實現的key-value類型的存儲，速度快，性能好。

　　二、支持多種存儲類型，有Strings，Hashes，Sets，Lists，Sorted Sets類型。

　　三、支持數據持久化，有Snapshotting，Append-Only File模式的持久化。

　　四、支持集羣和哨兵。

　　五、支持主從複製。

　　六、支持簡單的事務控制。

　　七、支持消息的發佈和訂閱。

　　八、安全性的支持。

　　九、支持數據過時。等等

2、Redis的應用場景

　　總結了如下幾點，應用場景特別多，你們根據其特性可類推其做用：

　　一、主要是用於熱點數據的存儲，好比Top100，最新10個數據。

　　二、時間過時（如短信驗證碼的過時時間等）。

　　三、計數器，因爲Redis是單線程且命令的原子性，可用來構建計數器。

　　四、可用來構建隊列，Sorted Sets。

　　五、緩存，爲減輕數據庫訪問壓力。

　　六、分佈式鎖，分佈式session管理。

3、Redis主要功能介紹。

　　先介紹Redis的幾個主要功能。

　　一、不一樣數據類型的存儲。這個我在這裏就不講了。哈哈，你們去百度下都有了。

　　二、高級特性。在這裏，我經過redis的redis.conf配置文件來給你們講解，只講常常會用到的，其他配置，你們感興趣可本身學習下。

　　(1)、NETWORK，網絡配置。

• bind：綁定服務器的網卡IP，因爲一個服務器可能有多個網卡，配置這個bind屬性，可限制訪問該網卡IP才能訪問到Redis。注意：不是綁定外部訪問該服務器的IP，網上不少地方都是錯誤講解的。我這邊搭建環境通常都是將其註釋掉，容許該服務器全部IP都能訪問到Redis服務。默認是bind 127.0.0.1。
• protected-mode：Redis服務的保護模式，保護模式下，只能容許127.0.0.1 and ::1這種本地訪問，配置默認爲開啓狀態protected-mode yes。這裏要注意保護模式的生效條件。根據配置文件中註釋：

　　　　# When protected mode is on and if:1) The server is not binding explicitly to a set of addresses using the "bind" directive.2) No password is configured.

　　　該模式在bind被註釋掉和沒有配置訪問密碼的時候才生效。通常可以讓其爲開啓狀態，同時配置訪問密碼，來實現Redis的服務安全性。

• port：配置Redis服務的端口。很重要哦。默認是6379。

　　(2)、GENERAL，常規配置。

• daemonize：服務是否後臺運行，默認是no，咱們本身沒有改的話，啓動redis時候，會佔用當前鏈接。因此，你們記得改爲yes，讓其在後臺運行。
• pidfile：配置Redis服務的PID號存在哪一個文件。因爲可能在同一服務器上啓動多個Redis服務，因此，你們最好指定具體的PID文件，且不一樣的Redis服務的PID文件不一樣。

　　　如配置爲：pidfile /var/run/redis_（端口）.pid

• logfile：指定Redis服務的日誌路徑，你們記得也修改一下。

　　(3)、SNAPSHOTTING，快照類型的持久化配置，這裏說明下快照的原理：快照是Redis的默認持久化方式，這種方式就是以快照的方式將內存中的數據寫到二進制文件中，文件名爲dump.rdb。介紹下快照保存的步驟：一、redis調用fork，產生一個子進程。二、父進程繼續接受client的請求處理數據，利用copy on write，將執行快照動做時候的內存拷貝作成副本。三、子進程經過副本將數據寫入臨時文件，並替換以前的dump.rdb文件，而後退出。因此，快照持久化的數據是執行快照動做時的內存數據。Client能夠經過調用save或者bgsave命令執行快照，不一樣點事save命令由redis主進程完成，會阻塞因此client請求，而bgsave是開啓子進程執行，不會阻塞其餘client請求。須要注意的是，當Redis服務是做爲大數據量的內存存儲時，調用快照，因爲數據量較大，且是快照全部內存數據，這會形成大量磁盤IO動做，可能會嚴重影響性能。

• save 900 1
  save 300 10
  save 60 10000

　　　save <seconds> <changes>，配置快照觸發的條件。解讀第一個sava：900秒內有一個key值變化，則會觸發快照。可配置多個條件，條件是獨立的。

• stop-writes-on-bgsave-error：這個配置默認爲yes，是指Redis在後臺持久化失敗後，爲了讓客戶感知到，會拒絕寫服務，直到後臺持久化恢復正常。若是須要在後臺持久化失敗後，但願能繼續服務。可將其設置爲no。
• dbfilename：指定二進制文件名，默認爲dump.rdb。
• dir：指定rdb文件路徑。配置爲文件夾那一層。在一臺服務器上啓動多個Redis服務時，注意修改成不一樣文件路徑。

　　(4)、REPLICATION，主從模式的配置。注意，以前版本的redis，配置爲slave of，如今改成REPLICATION。主從模式，能夠是樹狀的，從服務屬於多臺主服務，且從服務也能夠有從服務。主從模式，可實現讀寫分離；高可用模式下，主服務出現問題，也能夠經過哨兵切換從服務爲主服務；可實現主服務不用數據持久化，從服務進行持久化工做，減輕主服務負擔等等。

• replicaof <masterip> <masterport>：配置主服務的ip和端口。配置以後，就是這臺機器的小弟了。主服務也能知道誰是他的小弟。
• masterauth <master-password>：若是主服務須要密碼認證，這裏須要配置從服務鏈接主服務的密碼。
• replica-read-only：默認爲yes，配置從服務默認爲只讀模式。

　　(5)、SECURITY，安全配置。

• requirepass：配置鏈接該Redis服務須要的認證密碼。注意一下，因爲redis的請求速度特別快，每秒150K，因此密碼強度必定要高一些，否則很快就會被破解。

　　(6)、CLIENTS，客戶端配置

• maxclients：配置最大客戶端鏈接數，最大支持10000個。超過了鏈接時，客戶端會收到超過最大鏈接數的提示。

　　(7)、MEMORY MANAGEMENT，內存管理配置。配置Redis服務佔用的最大內存，超過內存後，會將設置超時的key按超時時間來剔除，若是沒有可剔除的key後，那就報內存已滿。配置沒細細研究，下來研究一下補充。

　　(8)、APPEND ONLY MODE，aof模式的另外一種持久化方式。這種模式，是爲了彌補快照模式的不足。快照模式下，對於大內存數據時，快照嚴重影響性能，並且，快照是有觸發條件的時間間隔，這個間隔時間內，若是Redis服務Down掉，那這個時間段的數據就消失了。若是應用的數據一致性要求比較高，那就可使用AOF模式。AOF模式是在收到寫命令後，經過write將命令追加到appendonly.aof文件中。Redis重啓後，經過讀取該文件中的命令來從新恢復內存數據（注意，若是同時存在aof和rdb文件，Redis服務啓動時，優先讀取aof文件）。注意：持久化文件會愈來愈大，並且會有不少重複的命令，這也會致使沒必要要的內存影響，因此，Redis提供了bgrewriteaof命令來重建aof文件，過程以下：一、主進程調用fork，產生子進程。二、Redis子進程經過當前數據的快照，往aof臨時文件中寫入數據命令。三、redis主進程繼續接收命令，並存在緩存中。四、子進程寫完快照命令後，通知主進程，主進程將緩存中的命令也寫入臨時aof文件中。五、寫完後，主進程用臨時的aof文件替換以前的aof文件。

• appendonly：默認爲no，關閉aof模式，須要開啓則設置爲yes。
• appendfilename ："appendonly.aof"，指定aof文件名。
• appendfsync ：always，每次寫操做時觸發aof。
  appendfsync ：everysec，每秒寫一次aof，默認設置，3個配置選一個就行。
  appendfsync ：no，依賴os系統，當系統想刷新aof時，就執行aof。（任性，性能高，不穩定，和快照感受差很少）。

　　(9)、REDIS CLUSTER，redis集羣配置。

• cluster-enabled：默認是註釋掉，不啓用集羣模式的。取消註釋便可開啓集羣模式。
• cluster-config-file：指定cluster的配置文件，每一個cluster的節點都須要這個配置文件，會在簡歷集羣的時候自動填充內容，因此，須要指定爲不一樣的文件。
• cluster-node-timeout：超過這個時間，某個節點不能被連通，則視該節點爲failover狀態。

　　(10)、其他配置項你們本身研究一下。

4、Redis集羣及哨兵簡單介紹

　　集羣：集羣是一個提供在多Redis節點間共享數據的程序集。Redis集羣會把數據分配到不一樣的片區，引入了16384個哈希槽，哈希槽會分佈在集羣中的主節點，key經過CRC16校驗後，對16384取模，來決定數據落在哪一個槽內，有利於添加或刪除節點，只需進行哈希槽的從新分配。集羣經過主從模式，具備高可用性，某個主節點fail後，集羣會選取主節點下一個從節點做爲新的主節點，並給它分配以前主節點的槽位，若是切換完成後，舊的主節點上線，它此時也只能做爲新的主節點的從節點。注意，Redis5.0以前，部署集羣須要安裝ruby等，但在Redis5.0中，不須要安裝Ruby，直接使用redis-cli就能夠建立集羣！

　　哨兵：主從模式下，爲了使主從具有高可用性，就須要經過哨兵進行監控，在主節點下線後，會經過投票出新的主節點，在主節點上線後，也只能做爲新主節點的從節點。哨兵在生產環境下，也須要具有高可用，因此哨兵通常也要配置爲集羣。

5、搭建主從模式的Redis服務，並啓動多個哨兵進行監控

　　一、下載redis。下載地址：http://www.redis.cn/download.html。

　　二、解壓，編譯Redis。

　　(1)、新建一個文件夾放Redis服務相關的東西。

　　(2)、在該文件夾下解壓、編譯Redis。

　　　　tar -zxvf redis-5.0.0.tar.gz

　　　　make && make install

　　(3)、在解壓後的Redis文件夾中，找到redis.conf文件，該文件是啓動redis服務所需文件，拿出來，咱們這裏建三個redis服務，一主兩從，將文件拷貝三份，分別命名爲redis-7000.conf，redis-7001.conf，redis-7002.conf，分別編輯如下內容，注意若是配置的文件夾不存在，則須要新建好。其他配置保持默認。我舉一個例子說明：

• #bind 127.0.0.1，將bind註釋掉。
• port 7000：改變其服務端口，三份文件端口分別爲7000,7001,7002，注意檢查端口是否被其餘程序佔用。
• daemonize yes：修改服務爲後臺運行。
• pidfile /var/run/redis_7000.pid：指定不一樣的pid文件，注意三份配置文件不一樣。
• logfile "/var/redis/7000.log"：指定log日誌路徑，本身配，要求不一樣。
• dir /opt/redis-cluster/redis-7000：這個指定rdb文件的路徑配置，要求改爲不一樣。
• # replicaof <masterip> <masterport>：主服務這句話註釋，從服務配置的兩臺須要開啓。配置主服務的ip的port。
• masterauth ibethfy：都配上吧，從服務到主服務的認證密碼。
• requirepass ibethfy：三份文件都配置，客戶端訪問須要密碼驗證。

　　(4)、配置好三份文件後，使用redis-server redis-7000.conf，redis-server redis-7001.conf，redis-server redis-7002.conf啓動服務，注意我是在配置文件路徑執行的命令。

　　　　使用ps -ef|grep redis查看是否三個服務都正常啓動，使用redis-cli -h ip地址 -p 端口 -a 密碼，經過客戶端登錄，執行info replication，能夠查看到主從信息。

　　(5)、搭建哨兵。新起一臺linux吧。一樣執行1,2步驟，安裝redis。拷貝sentinel.conf三份，分別爲sentinel-26380.conf，sentinel-26381.conf，sentinel-26382.conf。

　　(6)、修改sentinel

• protected-mode no：關閉保護模式，使外網能訪問。
• port 26380：修改端口。三份文件分別不一樣。
• daemonize yes：修改成後臺運行。
• pidfile /opt/redis-cluster/redis-sentinel-26380/sentinel.pid：指定不一樣pid文件，注意文件夾不存在本身要新建。
• logfile "/opt/redis-cluster/redis-sentinel-26380/26380.log"：配置哨兵日誌文件。
• dir /opt/redis-cluster/redis-sentinel-26380：配置哨兵工做路徑。
• sentinel monitor master7000 192.167.3.145 7000 2：配置哨兵須要監控的主節點ip和端口，最後的2表明，若是有2個哨兵主觀認爲主節點down了，那麼就客觀認爲主節點down掉了，開始發起投票選舉新主節點的操做。多個主節點配置多個。
• sentinel auth-pass master7000 ibethfy：配置哨兵鏈接主節點的認證密碼。（主節點配置的requirepass）。
• sentinel down-after-milliseconds master7000 5000：配置多少毫秒後沒收到主節點的反饋，則主觀認爲主節點down了。
• sentinel failover-timeout master7000 30000：failover過時時間。當failover開始後，在此時間內仍然沒有觸發任何failover操做，當前sentinel將會認爲這次failoer失敗。  

         注意，配置前把以前的默認的mymaster開啓的配置所有註銷掉！或者直接在其上修改！否則會出現問題！

　　(7)、在配置文件目錄下執行redis-sentinel sentinel-26380.conf，redis-sentinel sentinel-26381.conf，redis-sentinel sentinel-26382.conf，分別啓動三個哨兵。

　　(8)、測試，kill掉7000端口的redis服務，一段時間後，登錄到其餘端口的客戶端，查看info replication，此時是否從節點的某一個已切換成主節點，另外一個從節點屬於新主節點的從節點。並測試主節點再次上線後，是不是新主節點的從節點。

　　(9)、哨兵的細節問題，可參考：http://www.redis.cn/topics/sentinel.html。

6、集羣搭建

　　(1)、一樣解壓安裝、編譯Redis，拷貝redis.conf文件，分別爲7000-7008，共九個文件。準備搭建1主2從的3套Redis。

　　(2)、配置文件修改，同主從搭建的第三步，只是不須要配置服務的狀態了，將replicaof <masterip> <masterport>這個註釋掉。

• cluster-enabled yes：開啓集羣模式。
• cluster-config-file nodes-7000.conf：指定不一樣的集羣節點配置文件，集羣會本身修改內容。
• cluster-node-timeout 15000：配置多少毫秒後，主節點失聯將會觸發節點切換。

　　(3)、使用redis-server redis-7000.conf等將全部節點啓動。

　　(4)、使用redis-cli配置集羣。命令和啓動成功的提示以下。過程當中會讓你看下節點分配是否能夠，輸入yes肯定。經過日誌能夠看到，主節點爲7000,7001,7002，每一個主節點各兩個從節點，replicates後面跟的是主節點的nodeid。Slots 0-5460代表各主節點分配到的槽位。

[root@rhel64 redis-cluster]# redis-cli --cluster create 192.167.3.145:7000 192.167.3.145:7001 192.167.3.145:7002 192.167.3.145:7003 192.167.3.145:7004 192.167.3.145:7005 192.167.3.145:7006 192.167.3.145:7007 192.167.3.145:7008 --cluster-replicas 2 -a ibethfy
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Performing hash slots allocation on 9 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.167.3.145:7003 to 192.167.3.145:7000
Adding replica 192.167.3.145:7004 to 192.167.3.145:7000
Adding replica 192.167.3.145:7005 to 192.167.3.145:7001
Adding replica 192.167.3.145:7006 to 192.167.3.145:7001
Adding replica 192.167.3.145:7007 to 192.167.3.145:7002
Adding replica 192.167.3.145:7008 to 192.167.3.145:7002
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: 35d56aab1045bded29a8b273dca0d8a9258b4182 192.167.3.145:7000
   slots:[0-5460] (5461 slots) master
M: 238c6ca906531cd0feeebaaa6ff2afb84b9cc072 192.167.3.145:7001
   slots:[5461-10922] (5462 slots) master
M: 144577204f66c0857920dd3ce91ad3248a16e426 192.167.3.145:7002
   slots:[10923-16383] (5461 slots) master
S: a98785183466cc59ae39599779196d986402c94a 192.167.3.145:7003
   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182
S: d80ffdfeef5a536e5e9aaa69aa175b42ca5b1f32 192.167.3.145:7004
   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072
S: 43bf3f2f15cd963f2cb7cbc8427e3c5d70d8b9dc 192.167.3.145:7005
   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182
S: 0723dfeeb31015178791eba46f895076ca66bc05 192.167.3.145:7006
   replicates 144577204f66c0857920dd3ce91ad3248a16e426
S: 603d61677a6044e57e415afb325d7a81501a78c8 192.167.3.145:7007
   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072
S: 110918384563a4173bb17d36b6dd6958a3e97b3c 192.167.3.145:7008
   replicates 144577204f66c0857920dd3ce91ad3248a16e426
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
..........
>>> Performing Cluster Check (using node 192.167.3.145:7000)
M: 35d56aab1045bded29a8b273dca0d8a9258b4182 192.167.3.145:7000
   slots:[0-5460] (5461 slots) master
   2 additional replica(s)
S: 603d61677a6044e57e415afb325d7a81501a78c8 192.167.3.145:7007
   slots: (0 slots) slave
   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072
S: 0723dfeeb31015178791eba46f895076ca66bc05 192.167.3.145:7006
   slots: (0 slots) slave
   replicates 144577204f66c0857920dd3ce91ad3248a16e426
M: 238c6ca906531cd0feeebaaa6ff2afb84b9cc072 192.167.3.145:7001
   slots:[5461-10922] (5462 slots) master
   2 additional replica(s)
M: 144577204f66c0857920dd3ce91ad3248a16e426 192.167.3.145:7002
   slots:[10923-16383] (5461 slots) master
   2 additional replica(s)
S: d80ffdfeef5a536e5e9aaa69aa175b42ca5b1f32 192.167.3.145:7004
   slots: (0 slots) slave
   replicates 238c6ca906531cd0feeebaaa6ff2afb84b9cc072
S: 110918384563a4173bb17d36b6dd6958a3e97b3c 192.167.3.145:7008
   slots: (0 slots) slave
   replicates 144577204f66c0857920dd3ce91ad3248a16e426
S: 43bf3f2f15cd963f2cb7cbc8427e3c5d70d8b9dc 192.167.3.145:7005
   slots: (0 slots) slave
   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182
S: a98785183466cc59ae39599779196d986402c94a 192.167.3.145:7003
   slots: (0 slots) slave
   replicates 35d56aab1045bded29a8b273dca0d8a9258b4182
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

　　(5)、測試節點下線，這裏就不說明了。結論是主節點故障後，下掛從節點會有一個升級成主節點，並接替主節點的槽位。另外一個從節點切換成做爲新主節點的從節點。舊主節點上線後，也只能做爲其從節點。

　　(6)、高級特性我這裏不說明了，太多了，給你們一個網址：http://www.redis.cn/topics/cluster-tutorial.html。

 7、最後，但願各位有問題能留言提出，你們能夠一塊兒學習成長！