本文版權歸博客園和作者吳雙本人共同所有 轉載和爬蟲請註明原文地址 www.cnblogs.com/tdws

一.基礎安裝

wget http://download.redis.io/releases/redis-4.0.0.tar.gz

tar xzf redis-4.0.0.tar.gz

cd redis-4.0.0

cd src

make

make test

./redis-server ../redis.conf

ps -ef |grep redis  查看redis進程
netstat -lntp | grep 6380  查詢指定端口監聽

kill 
 
-9 進程id  強制殺死redis進程

二. 4.0版本初步了解

Redis4.0中增加了UNLINK 命令(替換del命令)，這個命令在刪除體積較大的鍵時，命令在後臺線程裏面執行，還有異步的flushdb和flushall命令分別是

flushdb async

flushall async

盡可能的避免了服務器阻塞。

增加了交換數據庫命令，比如SWAPDB 0 1 ，交換0庫和1庫

增加了memory命令，可以視察內存使用情況，通過help命令可以看到

127.0.0.1:6379> memory help

1) "MEMORY USAGE <key> [SAMPLES <count>] - Estimate memory usage of key"

2) "MEMORY STATS - Show memory usage details"

3) "MEMORY PURGE - Ask the allocator to release memory"

4) "MEMORY MALLOC-STATS - Show allocator internal stats"

MEMORY USAGE <key> 預估指定key所需內存

MEMORY STATS 視察內存使用詳情

MEMORY PURGE 向分配器索要釋放更多內存

MEMORY MALLOC-STATS 視察分配器內部狀態

另外還有一系列優化比如 LRU和PSYNC，還有模塊系統。

三.Cluster

雖然一主一從加哨兵可以解決普通場景下服務可用的問題，但是兩個節點分別存儲所有的緩存數據，這不僅導致容量受限，更是讓我們受限於機器配置最差的那一臺，這就是木桶效應。硬件垂直擴容並不能解決日益龐大的緩存數據量和提供能搞得可用性。

在古老的Redis版本中，水平擴容的能力來自於發送命令的客戶端，由客戶端路由不同的key給到不同的節點，下次讀取的時候，也按照相同方式路由key到指定節點拿到數據。如果接下來還希望增加擴容節點的話，就要對歷史緩存數據做遷移，遷移過程中為保證數據一致性也要付出一定代價。為了解決節點的不斷擴容，設計初期可以預先設置很多節點，以備日後使用，所有設計的節點都參與到分片當中，鑒於初期數據較少，可單臺服務器多個節點，在日後數據增多的情況下，只需要遷移節點到新的服務器。而不需要對數據進行重新分配等操作。但是這種做法依然讓我們覺得難維護，難遷移，難應對故障，遷移過程中也很難保證數據一致性，比如50個節點，任意一個節點想要停止並遷移服務器，都會引發數據不一致或者出現故障，只能停止集群，等待遷移完成後，集群上線。

Redis3.0提供了Cluster集群。這個集群的概念和前面提到的集群有所不同。前面的集群僅代表，多個節點間沒有相互的關系，只是根據客戶端路由分配key到不同的節點，所有節點共同分配所有數據。3.0的Cluster功能，擁有和單機實例相同的性能，幾乎支持所有命令，對於涉及多個鍵的命令，比如MGET,如果每一個鍵都在同一個節點則可以正常返回數據，否則提示錯誤。另外集群中限制了0號數據庫，如果切換數據庫則會提示錯誤。

哨兵和集群是兩個獨立的功能，但從特性來看哨兵可以視為集群的子集。當不需要數據分片或者已經利用客戶端分片的場景下哨兵已經足夠使用，如果需要水平擴容，Cluster是非常好的選擇。

每個集群至少三臺主節點。

到redis-4.0.0目錄下 修改redis.conf

修改所有redis.conf文件 在GENERAL一般設置中找到daemonize 將其設置為yes 我們將後臺運行redis

protect mode為no

bind ip為0.0.0.0

集群搭建成功前不要設置連接密碼。

設置maxmemory 100m

cluster-enabled設置為yes

註意cluster-config-file配置不同的名稱。我剛開始給每個節點都配置nodes.conf , 結果弄了幾個小時都不行，一直在waiting claster join. WTF？？？ 工作目錄明明都是自己的文件夾呀，後來在stackoverflow上 看到有人相同情況，我就改下配置文件名試了一下，還真可以了....

把redis-4.0.0文件夾復制6份

我準備了兩臺服務器，當然一臺服務器也是可以玩轉的。

六個節點分別啟動，此時集群是不能正常工作的，因為他們還是六個獨立的節點。下面我們要使用src目錄下的redis-trib.rb來將他們加入到同一個集群當中。但是.rb由Ruby編寫，我們需要安裝環境，還需要gem redis包。yum install ruby下載的是2.0版本，並且得不到升級， 我們需要ruby2.2+,所以我們不使用。ruby安裝指南http://blog.csdn.net/lixwjava/article/details/49231899

wget https://cache.ruby-lang.org/pub/ruby/2.2/ruby-2.2.7.tar.gz
tar -zxvf ruby-2.2.7.tar.gz  
cd  ruby-2.2.7
./configure  
make  
make test
make install  
如果順利的話就安裝完ruby了

如果沒有zlib 先安裝一下
yum install zlib-devel
yum install zlib
接下來進入ruby文件夾下ext/zlib中 安裝ruby自身提供的zlib包
cd ext/zlib
ruby ./extconf.rb
make
make install

另外需要安裝openssl (不裝也行) http://blog.csdn.net/yangxuan0261/article/details/52065158 如果沒裝，更換gem鏡像為非ssl的中國ruby鏡像https://ruby.taobao.org/

gem sources --add http://gems.ruby-china.org/ --remove https://rubygems.org/
gem sources -l
gem install redis.

在執行create cluster之前 請保證每個node的0庫不包含任何key.如果有key 就對不純潔的節點執行flushall和cluster reset 。每個Node都有一個特定的TCP端口，用來接收其他nodes的鏈接；此端口號為面向Client的端口號 + 10000，比如果客戶端端口號為6379，那麽次node的BUS端口號為16379，客戶端端口號可以在配置文件中聲明。由此可見，nodes之間的交互通訊是通過Bus端口進行，使用了特定的二進制協議，此端口通常應該只對nodes可用，可以借助防火墻技術來屏蔽其他非法訪問。所以註意我們的所有節點端口+10000 也要保持開放

./redis-trib.rb create --replicas 1 47.92.93.157:6379 47.92.93.157:6380 47.92.93.157:6381 47.92.93.157:6382 47.92.93.157:6383 47.92.93.157:6384

啟動redis-cli 使用-c參數 連接集群，將會為我們做一些自動重定向工作。

設置集群密碼：

config set masterauth abc  
config set requirepass abc  
config rewrite  

Redis4.0 Cluster — Centos7