Redis安裝及HA(High Availability)配置

Redis是一種內存數據庫，以KEY-VALUE(即鍵值對)的形式存儲數據。這篇文章主要介紹的是Redis安裝及配置，因此不對Redis自己做詳細介紹了。

 

下載：

http://redis.io/download (另外，Redis做者有一博客：http://antirez.com/latest/0，有興趣的能夠關注)

 

解壓：

以redis-2.8.19.tar.gz爲例，解壓放在某目錄下，這裏選擇/usr/local目錄。

 

編譯：

進入/usr/local/redis-2.8.19，執行

#make

如遇到gcc: Command not found錯誤，表示須要安裝gcc

#yum install gcc

如遇到zmalloc.h:50:31: error: jemalloc/jemalloc.h: No such file or directory錯誤，則要進入deps目錄，執行：

#make hiredis

#make jemalloc

#make linenoise

#make lua

而後再回到上級目錄執行make便可。

 

啓動：

make成功以後，會在src目錄生成redis-server等可執行文件，執行：

#src/redis-server

或

#src/redis-server &//加&爲了可讓鼠標退出Redis的命令行

 

查看：

#ps aux|grep redis//查看是否有相應的進程

或

#telnet localhost 6379//登陸Redis

或更經常使用的

#src/redis-cli//進入Redis交互命令行

這裏介紹三個最基本的Redis命令(1)keys *，顯示數據庫中全部的key；(2)set foo bar，即爲鍵foo設置值bar；(3)get foo，查看鍵foo的值。

 

關閉：

#src/redis-cli shutdown

 

日誌：

無論對什麼應用程序，日誌對於診斷工做有很大的做用，因此這裏提一下Redis的日誌。咱們發現按上面的方法啓動Redis，咱們在系統中找不到Redis的日誌，即使咱們配置了/usr/local/redis-2.8.19/redis.conf文件中的logfile，指向/var/log/redis.log，仍然找不到日誌。

同時，經過src/redis-cli CONFIG GET *來查看配置項，則提示命令參數錯誤ERR Wrong number of arguments for CONFIG GET

其實，形成這些問題的緣由是在啓動Redis時沒有明確指定配置文件，能夠這樣指定：

#src/redis-server redis.conf &//可使用絕對路徑來指定redis.conf

這樣就一切正常了，日誌文件也生成了。

 

HA配置：

咱們先介紹Redis怎麼配置Replication，這裏準備了兩臺機器：redisha1(153.65.171.99)，這個做master；redisha2(153.65.170.156)，這個咱們用來做slave，修改它的redis.conf：

slaveof 153.65.171.99 6379

表示我是redisha1的slave。這樣設置以後，若是咱們在redisha1中經過set foo bar2，在redisha2中經過get foo就能夠取到值bar2。Redis自動完成了同步。

須要注意的是，配置完Replication後，做爲slave的redisha2則進入read-only模式，也就是咱們不能在redisha2上使用set命令寫入數據了，set操做會收到(error) READONLY You can't write against a read only slave。

 

配置完Replication並不意味着就萬事大吉了，試想若是redisha1宕機了，則基本意味着這套Redis系統失效了，由於這個時候剩下的redisha2是一個read-only的slave。

咱們指望能有一個監控程序能夠自動完成Redis Replication系統中的角色切換，而這正是咱們要介紹的Redis Sentinel的設計目的（sentinel自己有哨兵、放哨之意）。一樣，也準備了兩臺機器，都用來運行Sentinel：redisha3(153.65.171.168)，redisha4(153.65.170.145)，而且和前面的redisha1和redisha2同樣，都部署了redis-2.8.19，所不一樣的是，咱們並不改動redis.conf進行，要改動的是sentinel.conf：

sentinel monitor test 153.65.171.99   6379   2

這一行配置表示我要監控153.65.171.99這臺機器上的Redis實例，併爲它取了一個暱稱叫test(默認是mymaster，若是你改動了，注意要搜索這個文件中全部mymaster的地方，並都改過來)。6379則是99上Redis監聽的端口。

最後的2這個數字則是quorum數，對於一個Redis主從系統，能夠有多個sentinel同時監控它，以免當惟一的一個sentinel宕掉後影響redis系統的運行。多個sentinel之間採用一種「投票」機制，即某一sentinel發現某一redis實例宕掉了，它不能直接將它移出系統，而要詢問全部的sentinel，只有當n個sentinel都投票贊成說這個redis實例確實宕掉了，才能將它移出。而這個這n值正是由quorum參數指定。

 

啓動Sentinel：

在redisha3與redisha4上，進入/usr/local/redis-2.8.19目錄，執行：

#src/redis-server sentinel.conf --sentinel

 

測試：

關閉redisha1上的redis實例，則在sentinel的窗口中：

+switch-master test 153.65.171.99 6379 153.65.170.156 6379

也就是說原來的redisha1(153.65.171.99)的master角色如今因爲redisha2(153.65.170.156)來承擔了。

同時你會發現看到redisha2的redis.conf中的slaveof配置被移除了，由於它如今是master了。

 

啓動redisha1上的redis，redisha1會被以slave的身份加入到redis系統中，能夠在sentinel的窗口中看到：

+convert-to-slave slave 153.65.171.99:6379 153.65.171.99 6379 @ test 153.65.170.156 6379

而redisha1中的redis.conf文件的最後一行會被自動添加上slaveof配置，指向如今的master即redisha2。

須要注意的是，這個自動發現新redis實例並把它做爲slave加入到系統中的功能，在2.6版本中是沒有的。

 

關閉redisha4上的sentinel，redisha3上能夠看到：

+sdown sentinel 153.65.170.145:26379 153.65.170.145 26379 @ test 153.65.170.156 6379

這個時候我關閉redisha2（它如今是master），sentinel沒法進行自動角色切換了，這跟quorum的配置有關，由於它如今沒有辦法收到2個投票，這個上面介紹過了。

 

SDOWN, ODOWN：

在sentinel的輸出中，常常能夠看到這兩個狀態：

Subjectively Down condition (SDOWN) 主觀以爲某redis實例已中止，即當前sentinel判斷某redis實例已經中止。

Objectively Down condition (ODOWN) 客戶判斷某redis實例已中止，quorum參數指定的數量n，噹噹前有n個sentinel投票此redis已經宕了，則進入ODOWN狀態。

 

其它幾個命令：

#redis-cli -h {IP} -p 26379 info Sentinel//查看sentinel的信息

#redis-cli -h {IP} -p 6379 info Replication//查看replication的信息

#redis-cli -h {IP} -p 26379 sentinel slaves test//查看全部slave的信息。test是sentinel.conf中配置的master的暱稱

 

---

送書了，送書了，關注公衆號「程序員雜書館」，送出O'Reilly《Spark快速大數據分析》紙質書（亦有一批PDF分享）！ —— 2018年12月