开心六月综合激情婷婷|欧美精品成人动漫二区|国产中文字幕综合色|亚洲人在线成视频

redis作為一種高效的緩存框架，使用是非常廣泛的，在數(shù)據(jù)存儲上，在運行時其將數(shù)據(jù)存儲在內(nèi)存中，以實現(xiàn)數(shù)據(jù)的高效讀寫，并且根據(jù)定制的持久化規(guī)則不同，其會不定期的將數(shù)據(jù)持久化到硬盤中。

另外相較于其他的NoSql數(shù)據(jù)庫，redis提供了非常豐富的數(shù)據(jù)結(jié)構(gòu)，如dict，sds，linkedlist，ziplist，set，quicklist，geometry。在這些存儲結(jié)構(gòu)的基礎上，redis為用戶提供了非常豐富的操作選擇，如通過zskiplist來達到對某種類型的數(shù)據(jù)的排序目的，而排序在數(shù)據(jù)庫中是一個非常耗時的操作。

1.redis單例的安裝和使用

redis相對于其他的緩存框架安裝非常的方便，只需要從https://redis.io/download下載后解壓，進入redis目錄之后執(zhí)行如下命令即安裝完成：

這里需要注意的是make是gcc中的一個命令，安裝之前請確保機器安裝了gcc。redis中所有的命令都在redis安裝目錄中的src子目錄下，其中比較重要的是redis-server，redis-sentinel，redis-cli。

編譯完成之后在src目錄下執(zhí)行./redis-server啟動redis（啟動后可關(guān)閉該窗口），然后新開一個窗口，在命令行中執(zhí)行./redis-cli即可連接啟動的redis服務。在其中執(zhí)行如下命令即可看到編譯安裝成功了：

這里需要說明的是，按照上述方式啟動redis，其使用的ip為本機ip 127.0.0.1，端口為6379，并且其余的配置采用的都是默認配置，相關(guān)配置可在redis安裝目錄下的redis.conf文件中查看。如果需要按照指定的配置文件來啟動，可在redis-server后接上配置文件名，如：

另外，上述使用redis-cli連接redis客戶端時如果不帶任何參數(shù)，那么其連接的默認ip和端口為127.0.0.1:6379。如果需要連接指定ip和端口的客戶端，可以使用如下方式：

這里-h參數(shù)表示連接的ip，-p則表示連接的端口。配置好redis之后，我們就可以在redis中執(zhí)行相關(guān)命令來操作數(shù)據(jù)。

2.redis主從模式的配置

redis單例提供了一種數(shù)據(jù)緩存方式和豐富的數(shù)據(jù)操作api，但是將數(shù)據(jù)完全存儲在單個redis中主要存在兩個問題：數(shù)據(jù)備份和數(shù)據(jù)體量較大造成的性能降低。這里redis的主從模式為這兩個問題提供了一個較好的解決方案。

主從模式指的是使用一個redis實例作為主機，其余的實例作為備份機。主機和從機的數(shù)據(jù)完全一致，主機支持數(shù)據(jù)的寫入和讀取等各項操作，而從機則只支持與主機數(shù)據(jù)的同步和讀取，也就是說，客戶端可以將數(shù)據(jù)寫入到主機，由主機自動將數(shù)據(jù)的寫入操作同步到從機。

主從模式很好的解決了數(shù)據(jù)備份問題，并且由于主從服務數(shù)據(jù)幾乎是一致的，因而可以將寫入數(shù)據(jù)的命令發(fā)送給主機執(zhí)行，而讀取數(shù)據(jù)的命令發(fā)送給不同的從機執(zhí)行，從而達到讀寫分離的目的。如下所示主機redis-A分別有redis-B、redis-C、redis-D、redis-E四個從機：

前面第1點中我們已經(jīng)介紹了redis單例的配置方式，而上面我們也介紹了主從模式其實也是多個redis實例組成的，因而redis主從模式的配置可以理解為多個不同的redis實例通過一定的配置告知其相互之間的主從關(guān)系。

而前面已經(jīng)介紹，每個redis實例都會占用一個本機的端口號，主從模式的配置主要的配置點有兩個：當前實例端口號和當前實例是主機還是從機，是從機的話其主機的ip和端口是什么。一般的redis目錄下的redis.conf保存的是默認配置，盡量不要對其進行修改，這里我們復制三份redis.conf文件，分別命名為6379.conf，6380.conf和6381.conf，如下是端口為6379的主機的主要配置：

如下是端口為6380和6381的從機的配置：

可以看到，端口為6380和6381的實例被配置為端口為6379的實例的從機。配置完成后使用redis-server分別執(zhí)行如下命令啟動三個實例：

啟動之后分別開啟開啟三個命令行工具分別執(zhí)行以下命令連接redis實例：

分別在三個命令行工具中執(zhí)行一個get命令，獲取鍵名為msg的數(shù)據(jù)，如下所示：

可以看到，在三個redis實例中都不存在鍵為msg的數(shù)據(jù)，現(xiàn)在我們在主機6379上設置一個鍵為msg的數(shù)據(jù)，如下所示：

可以看到設置成功了，此時我們在6380和6381的實例上執(zhí)行get msg的命令，如下所示：

可以看到，雖然我們只是在6379的實例上設置了msg這條數(shù)據(jù)，但是在6380和6381的實例上也存有了相應的數(shù)據(jù)，說明我們成功配置了redis的主從模式。另外，如果不在配置文件中指定主從節(jié)點的關(guān)系，也可以在啟動相關(guān)redis實例之后使用slaveof命令來指定當前節(jié)點稱為某個節(jié)點的從節(jié)點，如：

3.redis中sentinel配置

redis主從模式解決了數(shù)據(jù)備份和單例可能存在的性能問題，但是其也引入了新的問題。由于主從模式配置了三個redis實例，并且每個實例都使用不同的ip（如果在不同的機器上）和端口號，根據(jù)前面所述，主從模式下可以將讀寫操作分配給不同的實例進行從而達到提高系統(tǒng)吞吐量的目的，但也正是因為這種方式造成了使用上的不便，因為每個客戶端連接redis實例的時候都是指定了ip和端口號的，如果所連接的redis實例因為故障下線了，而主從模式也沒有提供一定的手段通知客戶端另外可連接的客戶端地址，因而需要手動更改客戶端配置重新連接。另外，主從模式下，如果主節(jié)點由于故障下線了，那么從節(jié)點因為沒有主節(jié)點而同步中斷，因而需要人工進行故障轉(zhuǎn)移工作。

為了解決這兩個問題，在2.8版本之后redis正式提供了sentinel（哨兵）架構(gòu)。關(guān)于sentinel，這里需要說明幾個概念：

每個sentinel節(jié)點其實就是一個redis實例，與主從節(jié)點不同的是sentinel節(jié)點作用是用于監(jiān)控redis數(shù)據(jù)節(jié)點的，而sentinel節(jié)點集合則表示監(jiān)控一組主從redis實例多個sentinel監(jiān)控節(jié)點的集合，比如有主節(jié)點master和從節(jié)點slave-1、slave-2，為了監(jiān)控這三個主從節(jié)點，這里配置N個sentinel節(jié)點sentinel-1，sentinel-2，...，sentinel-N。如下圖是sentinel監(jiān)控主從節(jié)點的示例圖：

從圖中可以看出，對于一組主從節(jié)點，sentinel只是在其外部額外添加的一組用于監(jiān)控作用的redis實例。在主從節(jié)點和sentinel節(jié)點集合配置好之后，sentinel節(jié)點之間會相互發(fā)送消息，以檢測其余sentinel節(jié)點是否正常工作，并且sentinel節(jié)點也會向主從節(jié)點發(fā)送消息，以檢測監(jiān)控的主從節(jié)點是否正常工作。

前面講到，sentinel架構(gòu)的主要作用是解決主從模式下主節(jié)點的故障轉(zhuǎn)移工作的。這里如果主節(jié)點因為故障下線，那么某個sentinel節(jié)點發(fā)送檢測消息給主節(jié)點時，如果在指定時間內(nèi)收不到回復，那么該sentinel就會主觀的判斷該主節(jié)點已經(jīng)下線，那么其會發(fā)送消息給其余的sentinel節(jié)點，詢問其是否“認為”該主節(jié)點已下線，其余的sentinel收到消息后也會發(fā)送檢測消息給主節(jié)點。

如果其認為該主節(jié)點已經(jīng)下線，那么其會回復向其詢問的sentinel節(jié)點，告知其也認為主節(jié)點已經(jīng)下線，當該sentinel節(jié)點最先收到超過指定數(shù)目（配置文件中配置的數(shù)目和當前sentinel節(jié)點集合數(shù)的一半，這里兩個數(shù)目的較大值）的sentinel節(jié)點回復說當前主節(jié)點已下線，那么其就會對主節(jié)點進行故障轉(zhuǎn)移工作，故障轉(zhuǎn)移的基本思路是在從節(jié)點中選取某個從節(jié)點向其發(fā)送slaveof no one（假設選取的從節(jié)點為127.0.0.1:6380），使其稱為獨立的節(jié)點（也就是新的主節(jié)點），然后sentinel向其余的從節(jié)點發(fā)送slaveof 127.0.0.1 6380命令使它們重新成為新的主節(jié)點的從節(jié)點。

重新分配之后sentinel節(jié)點集合還會繼續(xù)監(jiān)控已經(jīng)下線的主節(jié)點（假設為127.0.0.1:6379），如果其重新上線，那么sentinel會向其發(fā)送slaveof命令，使其成為新的主機點的從節(jié)點，如此故障轉(zhuǎn)移工作完成。

上面我們講到了，每個sentinel節(jié)點在本質(zhì)上還是一個redis實例，只不過和redis數(shù)據(jù)節(jié)點不同的是，其主要作用是監(jiān)控redis數(shù)據(jù)節(jié)點。在redis安裝目錄下有個默認的sentinel配置文件sentinel.conf，和配置主從節(jié)點類似，這里復制三個配置文件：sentinel-26379.conf，sentinel-26380.conf和sentinel-26381.conf。分別按照如下示例編輯這三個配置文件：

對于端口為26380和26381的sentinel，其配置和上述類似，只需要把相應的端口號修改為對應的端口號即可。這里注意兩點：

• 每個sentinel的myid參數(shù)也要進行修改，因為sentinel之間是通過該屬性來唯一區(qū)分其他sentinel節(jié)點的；

• 參數(shù)中sentinel monitor mymaster 127.0.0.1 6379 2這里的端口號6379是不用更改的，因為sentinel是通過檢測主節(jié)點的狀態(tài)來得知當前主節(jié)點的從節(jié)點有哪些的，因而設置為主節(jié)點的端口號即可。

配置完成后我們首先啟動三個主從節(jié)點，然后分別使用三個配置文件使用如下命令啟用sentinel：

由于sentinel節(jié)點也是一個redis實例，因而我們可以通過如下命令使用redis-cli連接sentinel節(jié)點：

連上sentinel節(jié)點之后我們可以通過如下命令查看sentinel狀態(tài)：

結(jié)果如下：

可以看到，sentinel檢測到主從節(jié)點總共有三個，其中一個主節(jié)點，兩個從節(jié)點，并且sentinel節(jié)點總共也有三個。啟動完成之后，我們可以通過主動下線主節(jié)點來模擬sentinel的故障轉(zhuǎn)移過程。首先我們連接上端口為6379的主節(jié)點，使用如下命令查看主從節(jié)點狀態(tài)：

結(jié)果如下：

可以看到，當前主節(jié)點有兩個從節(jié)點，端口分別為6380和6381。然后我們對主節(jié)點執(zhí)行如下命令：

然后我們連接上端口號為6380的從節(jié)點，并執(zhí)行如下命令：

結(jié)果如下：

可以看到，當端口為6379的實例下線之后，端口為6380的實例被重新競選為新的主節(jié)點，并且端口為6381的實例被設置為6380的實例的從節(jié)點。如果我們此時重新啟用端口為6379的節(jié)點，然后再查看主從狀態(tài)，結(jié)果如下：

可以看到，端口為6379的redis實例重新連接后，sentinel節(jié)點檢測到其重新連接，那么對其發(fā)送命令，使其成為新的主節(jié)點的從節(jié)點。

4.redis集群的配置

redis集群是在redis 3.0版本推出的一個功能，其有效的解決了redis在分布式方面的需求。當遇到單機內(nèi)存，并發(fā)和流量瓶頸等問題時，可采用Cluster方案達到負載均衡的目的。并且從另一方面講，redis中sentinel有效的解決了故障轉(zhuǎn)移的問題，也解決了主節(jié)點下線客戶端無法識別新的可用節(jié)點的問題，但是如果是從節(jié)點下線了，sentinel是不會對其進行故障轉(zhuǎn)移的，并且連接從節(jié)點的客戶端也無法獲取到新的可用從節(jié)點，而這些問題在Cluster中都得到了有效的解決。

redis集群中數(shù)據(jù)是和槽（slot）掛鉤的，其總共定義了16384個槽，所有的數(shù)據(jù)根據(jù)一致哈希算法會被映射到這16384個槽中的某個槽中；另一方面，這16384個槽是按照設置被分配到不同的redis節(jié)點上的。

比如啟動了三個redis實例：cluster-A，cluster-B和cluster-C，這里將0-5460號槽分配給cluster-A，將5461-10922號槽分配給cluster-B，將10923-16383號槽分配給cluster-C（總共有16384個槽，但是其標號類似數(shù)組下標，是從0到16383）。也就是說數(shù)據(jù)的存儲只和槽有關(guān)，并且槽的數(shù)量是一定的，由于一致hash算法是一定的，因而將這16384個槽分配給無論多少個redis實例，對于確認的數(shù)據(jù)其都將被分配到確定的槽位上。redis集群通過這種方式來達到redis的高效和高可用性目的。

這里需要進行說明的一點是，一致哈希算法根據(jù)數(shù)據(jù)的key值計算映射位置時和所使用的節(jié)點數(shù)量有非常大的關(guān)系。一致哈希分區(qū)的實現(xiàn)思路是為系統(tǒng)中每個節(jié)點分配一個token，范圍一般在0~2^32，這些token構(gòu)成一個哈希環(huán)，數(shù)據(jù)讀寫執(zhí)行節(jié)點查找操作時，先根據(jù)key計算hash值，然后順時針找到第一個大于等于該hash值的token節(jié)點，需要操作的數(shù)據(jù)就保存在該節(jié)點上。通過分析可以發(fā)現(xiàn)，一致哈希分區(qū)存在如下問題：

• 加減節(jié)點會造成哈希環(huán)中部分數(shù)據(jù)無法命中，需要手動處理或忽略這部分數(shù)據(jù)；

• 當使用少量節(jié)點時，節(jié)點變化將大范圍影響環(huán)中數(shù)據(jù)映射，因此這種方式不適合少量節(jié)點的分布式方案；

• 普通的一致性哈希分區(qū)在增減節(jié)點時需要增加一倍或減去一半節(jié)點才能保證數(shù)據(jù)和負載的平衡。

正是由于一致哈希分區(qū)的這些問題，redis使用了虛擬槽來處理分區(qū)時節(jié)點變化的問題，也即將所有的數(shù)據(jù)映射到16384個虛擬槽位上，當redis節(jié)點變化時數(shù)據(jù)映射的槽位將不會變化，并且這也是redis進行節(jié)點擴張的基礎。

對于redis集群的配置，首先將redis安裝目錄下的redis.conf文件復制六份，分別取名為：cluster-6379.conf、cluster-6380.conf、cluster-6381.conf、cluster-6382.conf、cluster-6383.conf、cluster-6384.conf。對于一個高可用的集群方案，集群每個節(jié)點都將為其分配一個從節(jié)點，以防止數(shù)據(jù)節(jié)點因為故障下線，這里使用六份配置文件定義六個redis實例，其中三個作為主節(jié)點，剩余三個分別作為其從節(jié)點。對于這六份配置文件，以其中一份為例，以下是其需要修改的參數(shù)：

對于其余的配置文件，只需要將其中對應項的端口號和帶有端口號的文件名修改為當前要指定的端口號和端口號的文件名即可。配置文件配置好之后使用如下命令啟動集群中的每個實例：

仔細閱讀上述配置文件可發(fā)現(xiàn)，當前配置和啟動過程中并沒有指定這六個實例的主從關(guān)系，也沒有對16384個槽位進行分配。因而我們還需要進行進一步的配置，槽位的分配和主從關(guān)系的設定有兩種方式進行，一種是使用redis-cli連接到集群節(jié)點上后使用cluster meet命令連接其他的節(jié)點，如我們首先執(zhí)行如下命令連接到6379端口的節(jié)點：

連接上后使用cluster meet命令分別連接其余節(jié)點：

連接好后可以使用cluster nodes命令查看當前集群狀態(tài)：

可以看到配置的六個節(jié)點都已經(jīng)加入到了集群中，但是其現(xiàn)在還不能使用，因為還沒有將16384個槽分配到集群節(jié)點中。虛擬槽的分配可以使用redis-cli分別連接到6379，6380和6381端口的節(jié)點中，然后分別執(zhí)行如下命令：

添加完槽位后可使用cluster info命令查看當前集群狀態(tài)：

這里我們將16384個虛擬槽位分配給了三個節(jié)點，而剩余的三個節(jié)點我們通過如下命令將其配置為這三個節(jié)點的從節(jié)點，從而達到高可用的目的：

如此，所有的集群節(jié)點都配置完畢，并且處于可用狀態(tài)。這里可以使用cluster nodes命令查看當前節(jié)點的狀態(tài)：

我們使用redis-cli使用如下命令連接集群：

注意連接集群模式的redis實例時需要加上參數(shù)-c，表示連接的是集群模式的實例。連接上后執(zhí)行get命令：

可以看到，在6380端口的實例上執(zhí)行get命令時，其首先會為當前的鍵通過一致哈希算法計算其所在的槽位，并且判斷該槽位不在當前redis實例中，因而重定向到目標實例上執(zhí)行該命令，最后發(fā)現(xiàn)沒有該鍵對應的值，因而返回了一個（nil）。