① redis sentinel 哨兵，看這一篇就夠啦！
redis集群模式，丟失master主伺服器是無法繼續工作的，所以隨時都需要一個master節點。但是伺服器宕機是經常出現的事情，集群本身是無法完成故障轉移的，所以需要一個第三方的解決方案，幫redis集群完成故障轉移（選擇主節點、通知從節點修改同步master地址，讓原來的主節點成為從節點）。
（1）首先sentinel也屬於一種redis伺服器，只不過啟動時載入的配置文件不同。配置文件里包括了監控的主伺服器列表（對，可以是多個主伺服器，即就是多個集群）。
（2）sentinel通過配置文件中的主伺服器IP：埠號，建立鏈接和訂閱，就是一個雙向的通道
（3）sentinel默認每10秒，向建立鏈接的主伺服器，發送INFO命令；主伺服器收到命令，返回主伺服器信息。
可以看到，返回了主伺服器的運行ID，重要的是：同步主伺服器的從節點信息
（4）從步驟（3）中獲取到的從節點信息，從節點的IP和埠。sentinel和從節點建立鏈接和訂閱
（5）sentinel默認每10秒，向建立鏈接的從伺服器，發送INFO命令，從伺服器接收到命令後，返回從伺服器信息
主要包括了從伺服器對應的master節點的地址：埠號，偏移量
（6）sentinel與主伺服器和從伺服器建立了鏈接和訂閱，可以向主從伺服器發送命令，也可以接收主從伺服器的廣播
訂閱命令：subscribe _sentinel_:hello
通道名：hello
sentinel對hello頻道的訂閱會一直持續到sentinel和伺服器之間的鏈接斷開為止
sentinel向伺服器通道發送的消息，其他與該伺服器建立訂閱關系的sentinel也會收到訂閱通知，sentinel自己也會收到自己發出的消息的訂閱通知
（7）sentinel默認會每兩秒一次，向所有建立鏈接和訂閱的主從伺服器，發送廣播消息
命令：publish_sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"
可以看到主要包含
s_ip : sentinel自己 IP地址
s_port : sentinel自己埠號
s_runid : sentinel自己的運行ID
s_epoch : sentinel當前的配置紀元
m_name, m_ip, m_port, m_epoch : 當前監控伺服器的名稱（主或者從）、IP地址、埠號、當前配置紀元
這個消息，也會被其他訂閱該通道的sentinel收到
sentinel在接收到訂閱消息後（就是上文中自己與別的sentinel，publish的消息），首先過濾掉自己發，然後接收別人的消息，就能獲取監聽改主伺服器的所有sentinel節點
（8）通過上一步，sentinel能夠感知到其他監控主伺服器的sentinel節點，然後和其他sentinel建立連接，最終，所有監視主伺服器的sentinel節點組成了一個相關連接的網路！
sentinel會默認每1s向自己所建立連接的伺服器發送PING命令，這些伺服器包括（監視master的其他sentinel，master、salve伺服器），根據收到的返回值，來確定目標伺服器的狀態
常見返回值：+PONG、-LOADING、-MASTERDOWN，含義在此處先不關注
判定條件：目標伺服器在一定的時間內（配置文件欄位：down-after-milliseconds的值），一直返回「失敗」
對失敗的定義：
（1）目標伺服器沒有在規定時間內返回（該時間可配置）
（2）目標伺服器返回了上述三種返回值之外的值
確定一個目標伺服器失敗之後，會在sentinel自己的實例表中記錄該實例的狀態，用：
SRI_S_DOWN表示，S=subjective客觀
註：一個master伺服器會被多個sentinel監控，多個sentinel可能設置了不同的
down-after-milliseconds
和我們設想的一樣，單一的sentinel並不能決定目標master伺服器的生死存亡，會拿著自己實例表裡的「客觀」下線的伺服器地址和埠，去向同樣監控這台伺服器的sentinel詢問，看看「別人」這個伺服器到底下線沒？ 當能夠從別的sentinel那裡詢問到「足夠數量」的已下線（客觀下線或者主觀下線）結果後，sentinel就可以判斷目標伺服器真的下線了，就可以執行故障轉移了。
（1）sentinel發送命令is-master-down-by-addr
SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>
發送的目標：監控master伺服器的其他sentinel
參數解析：ip、port=自己監控的master伺服器的IP，埠，current_epoch=源sentinel當前的配置紀元，runid=源sentinel的唯一標識ID
（2）sentinel對命令is-master-dowm-by-addr的回復
1) <down_state> ：下線的狀態，0-未下線，1-已下線
2) <leader_runid> ：當前sentinel的局部leader，為 「*」 時表示沒有leader
3) <leader_epoch> ：當前sentinel的局部leader的配置紀元，當沒有leader時，該項為0
（3）sentinel收到命令is-master-down-by-addr的回復後
sentinel收到足夠數量（可配置）的「已下線」回復（即down_state=1），就會在自己的實例表裡將對應的master伺服器狀態（flags）設置為 SRI_O_DOWN，O=Objective。
監控同一個master伺服器的sentinel，對客觀下線的條件可以不一致，即收到多少已下線回復才認定客觀下線，可以不盡相同。
由於監控同一個master伺服器的sentinel有很多，並不能決定是哪個sentinel去執行故障轉移，所以需要多個sentinel進行選leader頭結點。
具體步驟：
(1)sentinel通過向其他sentinel節點發送is-master-down-by-addr命令，已經可以判斷當前master伺服器是否客觀下線
（2）已經判斷master伺服器客觀下線的sentinel，再次向其他節點發送
is-master-down-by-addr命令，攜帶自己的runId和配置紀元
這里再復習一遍命令 ：
sentinel is-master-down-by-addr <ip>,<port>,<cur_epoch>,<runid>
（3）目標sentinel收到源sentinel的 is-master…命令之後，執行以下判斷
1>判斷epoch和自己的紀元是否相等，不相等直接舍棄這條命令
2>判斷自己的配置表裡是否有局部leader，沒有的話，將源sentinel的runid設置為自己的局部了leader
如果已經有了局部leader，那麼會返回自己的局部leader的信息
3>對源sentinel的is-master-down-by-addr命令進行回復
示例：
源sentinel向目標sentinel發送命令，
SENTINEL is-master-down-by-addr 127.0.0.1 8080 0 11522852334a
源sentinel收到命令的回復
1
11522852334a
0
表示有一個sentinel將自己成功設置成為leader（需要把返回的runid和自己的runid比對）
4>當過半的sentinel將自己成功設置為局部leader，標識選主成功，如果在一段時間內沒有收到過半的成功數，那麼會進行下一輪命令的發送，epoch遞增+1
例如，共有10個sentinel監視同一個master伺服器，其中一個sentinel必須收到10/2+1=6個及以上的成功數，才能認為自己成功當選leader
（1）篩選master節點的備胎（即就是哪些slave節點可以成為新的master）
選擇master節點備胎就一個要求，數據盡量完整，狀態盡量好
1>刪除，客觀下線或者主觀下線的slave伺服器
2>刪除，在最近5s沒有回復過頭sentinel節點的INFO命令的slave伺服器
剩下的slave伺服器，根據優先順序進行排序，遇到優先順序一樣的，再根據偏移量排序（目的是篩選出和master伺服器數據較同步的slave伺服器）。再遇到偏移量一樣的，繼續根據runid排序，找出runid最小的（沒有什麼依據，只是個排序），至此，可以作為master的slave伺服器就篩選好了。
（2）slave伺服器升級為master
頭sentinel向步驟（1）中篩選出來的slave伺服器發送slaveof_no_one，發送完該轉移命令。之後，頭sentinel每秒一次的頻率向上述slave伺服器發送INFO命令，觀察INFO命令返回的role欄位，看是否變為master，變為master表示成功升級為master伺服器。
（3）修改原slave伺服器列表的復制/同步目標
頭sentinel向原slave伺服器列表發送命令：
slave of 127.0.0.1:8080，修改slave的復制目標
（4）修改已下線的master伺服器為新master的slave節點
頭sentinel保持對已下線master的監控，當已下線master重新上線（對PING命令有回復），就對他發送slave of 127.0.0.1命令，讓其成為slave。
至此，故障轉移全部結束。
② rediserach有大公司用嗎
你好，問的是redisearch吧。不知道你指的大公司是什麼，但是現在還蠻多人在用的。
RediSearch是一個高性能的全文搜索引擎，可作為一個RedisMole運行在Redis上，是由RedisLabs團隊開發的。特點是：Faster,in-memory,highlyavailablefulltextsearch。
RediSearch是在Redis基礎上從0開始開發的一個全文搜索索引，使用新的RedisMolesAPI來擴展Redis新命令和能力，它的主要特性包括：
簡單，快速索引和搜索
數據存儲在內存中，使用內存-有效的自定義數據結構
支持多種使用UTF-8編碼的語言
文檔和欄位評分
結果的數值過濾
通過詞干擴展查詢
精確的短語搜索
按特定屬性過濾結果（例如僅在標題中搜索「foo」
強大的自動提示引擎
增量索引（不需要對索引進行優化和壓縮）
支持用作存儲在另一資料庫中的文檔的搜索索引
支持已經在Redis中存在的HASH對象作為文件的索引
擴展到多個Redis實例
③ 布隆過濾器
[TOC]
通過解決方案：
Java中如將數據存儲在內存中，最簡單的演算法結構是HashMap。通過HashMap判斷key是否存在，來判斷數據是否存在。通過hash演算法查找元素，時間復雜度基本是 O(1) （可能存在hash沖突後轉換成鏈表或紅黑樹的情況，時間復雜度的影響可以忽略）。
使用HashMap速度很快，存儲簡單，絕大部分場景可以使用。但是HashMap 佔用的空間比較大 ：
為什麼出現布隆過濾器：
舉例：
如1000萬個Integer存儲在內存中，佔用空間為：4x32x10000000位，即1220兆。如布隆過濾器通過4位元組存儲（布隆過濾器通過多次hash對數據計算後-->幾次hash根據數據量指定，得到多個數據， 佔用多個位 ），則佔用空間為610M。比原有空間少一半。
個人覺得，此比較在字元等的比較中尤為有效。
一個字元串多個字元，根據編碼方式，一個字元兩個或三個位元組，如10個字元，字元串存儲佔用20個位元組，還有相關字元串相關的類信息的內存佔用。
位存儲，根據數據量的大小，hash的位數，靈活計算。如4個位元組，則是原hashMap佔用空間的五分之一。
（1）定義位元組向量
先定義一個指定長度的位元組數組（位元組數組，數組內每個元素的值）。
如長度為8（一個位元組大小），默認所有元素值均為0，如下：
（2）計算哈希值
將要寫入過濾器的數據，根據一定數量的哈希函數，得到多個哈希值，再依次判斷每個哈希值對應的索引。
如使用3個哈希函數，計算得到3個哈希值，判定哈希值對應的位元組向量為為1，3，7。
（3）更新位元組向量
將計算出的位元組向量的索引， 對應的位元組向量中的元素值更高為1 （無論之前為0或者為1，均更改為1）。如下：
（1）計算哈希值
將要判斷過濾器中是否存在的數據，根據一定數量的哈希函數，得到多個哈希值，再依次判斷每個哈希值對應的索引。
如使用3個哈希函數，計算得到3個哈希值，判定哈希值對應的位元組向量為為1，3，7。
注意：哈希函數的判斷方式和計算索引的方式，需和寫入數據時完全一致。
（2）判斷是否存在
如原位元組數組中，對應1，3，7中存在的元素的值都為1。則判定為此元素 可能存在 ，但凡有一個元素的值不為1，則判定此元素 一定不存在 。
布隆過濾器，主要需實現的目標是， 在指定的數據個數范圍內，滿足誤判率在設定的范圍內 ，誤判率太高的話，無法起到過濾數據的情況，誤判率不能為0。
因此需要計算兩個數據來滿足 存儲數據的個數 和 誤判率 ：
使用布隆過濾器的決定性因素之一，就是此演算法插入數據和查詢數據的速度必須非常快。因此在對數據進行哈希運算的時候， 需選擇計算快的哈希演算法 。
而且， 寫入數據以及查詢數據的哈希演算法，順序和演算法都需完全一致 。
待完善。。。。。
可以通過google的 guava ，在內存中輕松實現布隆過濾器。
無需手動計算滿足位元組數組的長度和哈希個數，只需要輸入 擬輸入數據的個數 和 期望誤判率 即可。
不輸入期望誤判率的情況下，誤判率為0.03，即100個非范圍內的數據進行校驗時，約三個數據會判定為存在。
多次執行，結果一致，根據結果判定：
內存的存儲存在局限性，可以使用redis中的bitMap來實現位元組數組的存儲。
使用redis實現布隆過濾器。需要根據公式，手動計算位元組數組的長度和哈希的個數。
實現過程，待完善。。。。。。
④ 布隆過濾器詳解
布隆過濾器 （英語：Bloom Filter）是 1970 年由布隆提出的。它實際上是一個很長的二進制向量和一系列隨機映射函數。主要用於判斷一個元素是否在一個集合中。
通常我們會遇到很多要判斷一個元素是否在某個集合中的業務場景，一般想到的是將集合中所有元素保存起來，然後通過比較確定。鏈表、樹、散列表（又叫哈希表，Hash table）等等數據結構都是這種思路。但是隨著集合中元素的增加，我們需要的存儲空間也會呈現線性增長，最終達到瓶頸。同時檢索速度也越來越慢，上述三種結構的檢索時間復雜度分別為 ， ， 。
這個時候，布隆過濾器（Bloom Filter）就應運而生。
了解布隆過濾器原理之前，先回顧下 Hash 函數原理。
哈希函數的概念是：將任意大小的輸入數據轉換成特定大小的輸出數據的函數，轉換後的數據稱為哈希值或哈希編碼，也叫散列值。下面是一幅示意圖：
所有散列函數都有如下基本特性：
但是用 hash表存儲大數據量時，空間效率還是很低，當只有一個 hash 函數時，還很容易發生哈希碰撞。
BloomFilter 是由一個固定大小的二進制向量或者點陣圖（bitmap）和一系列映射函數組成的。
在初始狀態時，對於長度為 m 的位數組，它的所有位都被置為0，如下圖所示：
當有變數被加入集合時，通過 K 個映射函數將這個變數映射成點陣圖中的 K 個點，把它們置為 1（假定有兩個變數都通過 3 個映射函數）。
查詢某個變數的時候我們只要看看這些點是不是都是 1 就可以大概率知道集合中有沒有它了
為什麼說是可能存在，而不是一定存在呢？那是因為映射函數本身就是散列函數，散列函數是會有碰撞的。
布隆過濾器的誤判是指多個輸入經過哈希之後在相同的bit位置1了，這樣就無法判斷究竟是哪個輸入產生的，因此誤判的根源在於相同的 bit 位被多次映射且置 1。
這種情況也造成了布隆過濾器的刪除問題，因為布隆過濾器的每一個 bit 並不是獨占的，很有可能多個元素共享了某一位。如果我們直接刪除這一位的話，會影響其他的元素。(比如上圖中的第 3 位)
相比於其它的數據結構，布隆過濾器在空間和時間方面都有巨大的優勢。布隆過濾器存儲空間和插入/查詢時間都是常數 ，另外，散列函數相互之間沒有關系，方便由硬體並行實現。布隆過濾器不需要存儲元素本身，在某些對保密要求非常嚴格的場合有優勢。
布隆過濾器可以表示全集，其它任何數據結構都不能；
但是布隆過濾器的缺點和優點一樣明顯。誤算率是其中之一。隨著存入的元素數量增加，誤算率隨之增加。但是如果元素數量太少，則使用散列表足矣。
另外，一般情況下不能從布隆過濾器中刪除元素。我們很容易想到把位數組變成整數數組，每插入一個元素相應的計數器加 1, 這樣刪除元素時將計數器減掉就可以了。然而要保證安全地刪除元素並非如此簡單。首先我們必須保證刪除的元素的確在布隆過濾器裡面。這一點單憑這個過濾器是無法保證的。另外計數器回繞也會造成問題。
在降低誤算率方面，有不少工作，使得出現了很多布隆過濾器的變種。
在程序的世界中，布隆過濾器是程序員的一把利器，利用它可以快速地解決項目中一些比較棘手的問題。
如網頁 URL 去重、垃圾郵件識別、大集合中重復元素的判斷和緩存穿透等問題。
布隆過濾器的典型應用有：
知道了布隆過濾去的原理和使用場景，我們可以自己實現一個簡單的布隆過濾器
分布式環境中，布隆過濾器肯定還需要考慮是可以共享的資源，這時候我們會想到 Redis，是的，Redis 也實現了布隆過濾器。
當然我們也可以把布隆過濾器通過 bloomFilter.writeTo() 寫入一個文件，放入OSS、S3這類對象存儲中。
Redis 提供的 bitMap 可以實現布隆過濾器，但是需要自己設計映射函數和一些細節，這和我們自定義沒啥區別。
Redis 官方提供的布隆過濾器到了 Redis 4.0 提供了插件功能之後才正式登場。布隆過濾器作為一個插件載入到 Redis Server 中，給 Redis 提供了強大的布隆去重功能。
在已安裝 Redis 的前提下，安裝 RedisBloom，有兩種方式
直接編譯進行安裝
使用Docker進行安裝
使用
布隆過濾器基本指令：
我們只有這幾個參數，肯定不會有誤判，當元素逐漸增多時，就會有一定的誤判了，這里就不做這個實驗了。
上面使用的布隆過濾器只是默認參數的布隆過濾器，它在我們第一次 add 的時候自動創建。
Redis 還提供了自定義參數的布隆過濾器， bf.reserve 過濾器名 error_rate initial_size
但是這個操作需要在 add 之前顯式創建。如果對應的 key 已經存在，bf.reserve 會報錯
我是一名 Javaer，肯定還要用 Java 來實現的，Java 的 Redis 客戶端比較多，有些還沒有提供指令擴展機制，筆者已知的 Redisson 和 lettuce 是可以使用布隆過濾器的，我們這里用 Redisson
為了解決布隆過濾器不能刪除元素的問題，布穀鳥過濾器橫空出世。論文《Cuckoo Filter：Better Than Bloom》作者將布穀鳥過濾器和布隆過濾器進行了深入的對比。相比布穀鳥過濾器而言布隆過濾器有以下不足：查詢性能弱、空間利用效率低、不支持反向操作（刪除）以及不支持計數。
由於使用較少，暫不深入。
https://www.cs.cmu.e/~dga/papers/cuckoo-conext2014.pdf
http://www.justdojava.com/2019/10/22/bloomfilter/
https://www.cnblogs.com/cpselvis/p/6265825.html
https://juejin.im/post/5cc5aa7ce51d456e431adac5
⑤ redis主從和哨兵
主從復制：主節點負責寫數據，從節點負責讀數據，主節點定期把數據同步到從節點保證數據的一致性
a,配置主從復制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379啟動完後再啟6380，完成配置；
b,配置主從復制方式二、redis-server --slaveof 192.168.152.128 6379 臨時生效
c,查看狀態：info replication
d,斷開主從復制：在slave節點，執行6380:>slaveof no one
e,斷開後再變成主從復制：6380:> slaveof 192.168.152.128 6379
f,數據較重要的節點，主從復制時使用密碼驗證： requirepass
e, 從節點建議用只讀模式slave-read-only=yes, 若從節點修改數據，主從數據不一致
h,傳輸延遲：主從一般部署在不同機器上，復制時存在網路延時問題，redis提供repl-disable-tcp-nodelay參數決定是否關閉TCP_NODELAY,默認為關閉
參數關閉時：無論大小都會及時發布到從節點，占帶寬，適用於主從網路好的場景，
參數啟用時：主節點合並所有數據成TCP包節省帶寬，默認為40毫秒發一次，取決於內核，主從的同步延遲40毫秒，適用於網路環境復雜或帶寬緊張，如跨機房
a)一主一從：用於主節點故障轉移從節點，當主節點的「寫」命令並發高且需要持久化，可以只在從節點開啟AOF（主節點不需要），這樣即保證了數據的安全性，也避免持久化對主節點的影響
b)一主多從：針對「讀」較多的場景，「讀」由多個從節點來分擔，但節點越多，主節點同步到多節點的次數也越多，影響帶寬，也加重主節點的穩定
c)樹狀主從：一主多從的缺點（主節點推送次數多壓力大）可用些方案解決，主節點只推送一次數據到從節點B，再由從節點B推送到C，減輕主節點推送的壓力。
redis 2.8版本以上使用psync命令完成同步，過程分「全量」與「部分」復制
全量復制：一般用於初次復制場景（第一次建立SLAVE後全量）
部分復制：網路出現問題，從節點再次連接主節點時，主節點補發缺少的數據，每次數據增量同步
心跳：主從有長連接心跳，主節點默認每10S向從節點發ping命令，repl-ping-slave-period控制發送頻率
a)主從復制，若主節點出現問題，則不能提供服務，需要人工修改配置將從變主
b)主從復制主節點的寫能力單機，能力有限
c)單機節點的存儲能力也有限
a)主節點(master)故障，從節點slave-1端執行 slaveof no one後變成新主節點；
b)其它的節點成為新主節點的從節點，並從新節點復制數據；
c)需要人工干預，無法實現高可用。
1. 為什麼要有哨兵機制？
原理：當主節點出現故障時，由Redis Sentinel自動完成故障發現和轉移，並通知應用方，實現高可用性。
其實整個過程只需要一個哨兵節點來完成，首先使用Raft演算法（選舉演算法）實現選舉機制，選出一個哨兵節點來完成轉移和通知
任務1：每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最拓撲結構圖，哨兵配置時只要配置對主節點的監控即可，通過向主節點發送info，獲取從節點的信息，並當有新的從節點加入時可以馬上感知到
任務2：每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對於主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的
任務3：每隔1秒每個哨兵會向主節點、從節點及其餘哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據
客觀下線：當主觀下線的節點是主節點時，此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷，當超過quorum（選舉）個數，此時哨兵節點則認為該主節點確實有問題，這樣就客觀下線了，大部分哨兵節點都同意下線操作，也就說是客觀下線
a)每個在線的哨兵節點都可以成為領導者，當它確認（比如哨兵3）主節點下線時，會向其它哨兵發is-master-down-by-addr命令，徵求判斷並要求將自己設置為領導者，由領導者處理故障轉移；
b)當其它哨兵收到此命令時，可以同意或者拒絕它成為領導者；
c)如果哨兵3發現自己在選舉的票數大於等於num(sentinels)/2+1時，將成為領導者，如果沒有超過，繼續選舉…………
a)由Sentinel節點定期監控發現主節點是否出現了故障
sentinel會向master發送心跳PING來確認master是否存活，如果master在「一定時間范圍」內不回應PONG 或者是回復了一個錯誤消息，那麼這個sentinel會主觀地(單方面地)認為這個master已經不可用了
b) 當主節點出現故障，此時3個Sentinel節點共同選舉了Sentinel3節點為領導，負載處理主節點的故障轉移
c) 由Sentinel3領導者節點執行故障轉移，過程和主從復制一樣，但是自動執行
流程：
1. 將slave-1脫離原從節點，升級主節點，
d) 故障轉移後的redis sentinel的拓撲結構圖
a) 過濾掉不健康的（下線或斷線），沒有回復過哨兵ping響應的從節點
b) 選擇salve-priority從節點優先順序最高（redis.conf）的
c) 選擇復制偏移量最大，指復制最完整的從節點
以3個Sentinel節點、2個從節點、1個主節點為例進行安裝部署
1. 前提： 先搭好一主兩從redis的主從復制，和之前的主從復制搭建一樣，搭建方式如下：
A）主節點6379節點（/usr/local/bin/conf/redis6379.conf）：
修改 requirepass 12345678，注釋掉#bind 127.0.0.1
B) 從節點redis6380.conf和redis6381.conf: 配置都一樣
修改 requirepass 12345678 ,注釋掉#bind 127.0.0.1,
加上訪問主節點的密碼masterauth 12345678 ,加上slaveof 192.168.152.128 6379
2. redis sentinel哨兵機制核心配置 (也是3個節點)：
將三個文件的埠改成: 26379 26380 26381
然後：sentinel monitor mymaster 192.168.152.128 6379 2 //監聽主節點6379
三個配置除埠外，其它一樣。
3. 哨兵其它的配置 ：只要修改每個sentinel.conf的這段配置即可：
sentinel monitor mymaster 192.168.152.128 6379 2
//監控主節點的IP地址埠，sentinel監控的master的名字叫做mymaster，2代表，當集群中有2個sentinel認為master死了時，才能真正認為該master已經不可用了
sentinel auth-pass mymaster 12345678 //sentinel連主節點的密碼
sentinel config-epoch mymaster 2 //故障轉移時最多可以有2從節點同時對新主節點進行數據同步
sentinel leader-epoch mymaster 2
sentinel failover-timeout mymasterA **180000 **//故障轉移超時時間180s，
a,如果轉移超時失敗，下次轉移時時間為之前的2倍；
b,從節點變主節點時，從節點執行slaveof no one命令一直失敗的話，當時間超過 180S 時，則故障轉移失敗
c,從節點復制新主節點時間超過 180S 轉移失敗
sentinel down-after-milliseconds mymasterA 300000 //sentinel節點定期向主節點ping命令，當超過了 300S 時間後沒有回復，可能就認定為此主節點出現故障了……
sentinel parallel-syncs mymasterA 1 //故障轉移後， 1 代表每個從節點按順序排隊一個一個復制主節點數據，如果為3，指3個從節點同時並發復制主節點數據，不會影響阻塞，但存在網路和IO開銷
4. 啟動redis服務和sentinel服務:
a)先把之前安裝的redis裡面的標綠色的文件都拷貝到 usr/local/bin目錄下，然後再再bin目錄下新建一個conf文件夾存放配置好的redis主從配置文件和哨兵配置文件
b)啟動主從復制服務，先啟動主再啟動從
主：./redis-server conf/redis6379.conf &
從：
./redis-server conf/redis6380.conf &
./redis-server conf/redis6381.conf &
c）啟動sentinel服務:
./redis-sentinel conf/sentinel_26381.conf &
到此服務全部啟動完畢
連接到6379的redis的服務，可看到6379就是主節點，他有6380和6381兩個從節點
5. 測試： kill -9 6379 殺掉6379的redis服務
可以看到殺掉6379以後6380變為了主節點，6381變為了6380的從節點
重新啟動6379以後變為6380的從節點
看日誌是分配6380 是6381的主節點，當6379服務再啟動時，已變成從節點
假設6380升級為主節點:進入6380>info replication 可以看到role:master
打開sentinel_26379.conf等三個配置，sentinel monitor mymaster 192.168.152.128 6380 2
打開redis6379.conf等三個配置, slaveof 192.168.152.128 6380,也變成了6380
注意：生產環境建議讓redis Sentinel部署到不同的物理機上。
a，sentinel節點應部署在多台物理機（線上環境）
b，至少三個且奇數個sentinel節點
c，通過以上我們知道，3個sentinel可同時監控一個主節點或多個主節點
sentinel參考資料：
redis sentinel的機制與用法一： https://segmentfault.com/a/1190000002680804
redis sentinel的機制與用法二： https://segmentfault.com/a/1190000002685515
⑥ 怎樣基於Redis實現模糊查詢
模糊查詢不是這類資料庫的強項。如果一定要這樣查詢，可以使用Rula寫過程來查詢，或把數據取到內存再寫程序代碼過濾。服務本身並沒有提供模糊查詢的功能。
⑦ Redis哨兵機制原理淺析
上一篇文章Redis主從復制原理中簡要地說明了主從復制的一個基本原理，包含全量復制、復制積壓緩沖區與增量復制等內容，有興趣的同學可以先看下。
利用主從復制，可以實現讀寫分離、數據備份等功能。但如果主庫宕機後，需要運維人員手動地將一個從庫提升為新主庫，並將其他從庫slaveof新主庫，以此來實現故障恢復。
因此， 主從模式的一個缺點，就在於無法實現自動化地故障恢復 。Redis後來引入了哨兵機制，哨兵機制大大提升了系統的高可用性。
哨兵，就是站崗放哨的，時刻監控周圍的一舉一動，在第一時間發現敵情並發出及時的警報。
Redis中的哨兵（Sentinel）， 則是一個特殊的Redis實例 ，不過它並不存儲數據。也就是說，哨兵在啟動時，不會去載入RDB文件。
關於Redis的持久化，可以參考我的另外一篇文章 談談Redis的持久化——AOF日誌與RDB快照
上圖就是一個典型的哨兵架構，由數據節點與哨兵節點構成，通常會部署多個哨兵節點。
哨兵主要具有三個作用， 監控、選主與通知 。
監控：哨兵會利用心跳機制，周期性不斷地檢測主庫與從庫的存活性
選主：哨兵檢測到主庫宕機後，選擇一個從庫將之切換為新主庫
通知：哨兵會將新主庫的地址通知到所有從庫，使得所有從庫與舊主庫slaveof新主庫，也會將新主庫的地址通知到客戶端上
我會在下文詳細講一下監控與選主的過程
哨兵系統是通過3個定時任務，來完成對主庫、從庫與哨兵之間的探活。
首先我們會在配置文件中配置主庫地址，這樣哨兵在啟動後，會以 每隔10秒 的頻率向主庫發送info命令，從而獲得當前的主從拓撲關系，這樣就拿到了所有從庫的地址。
接著 每隔2秒 ，會使用pub/sub（發布訂閱）機制，在主庫上的 sentinel :hello的頻道上發布消息，消息內容包括哨兵自己的ip、port、runid與主庫的配置。
每個哨兵都會訂閱該頻道，在該頻道上發布與消費消息，從而實現哨兵之間的互相感知。
利用啟動配置與info命令可以獲取到主從庫地址，利用發布訂閱可以感知到其餘的哨兵節點。
在此基礎上，哨兵會 每隔1秒 向主庫、從庫與其他哨兵節點發送PING命令，因此來進行互相探活。
當某個哨兵在 **down-after-milliseconds（默認是30秒） **配置的連續時間內，仍然沒有收到主庫的正確響應，則當前哨兵會認為主庫 主觀下線 ，並將其標記為sdown（subjective down）
為了避免當前哨兵對主庫的誤判，因此這個時候還需要參考其他哨兵的意見。
接著當前哨兵會向其他哨兵發送 sentinel is-master-down-by-addr 命令， 如果有半數以上（由quorum參數決定）的哨兵認為主庫確實處於主觀下線狀態，則當前哨兵認為主庫客觀下線 ，標記為odown（objective down）
一旦某個主庫被認定為客觀下線時，這個時候需要進行哨兵選舉，選舉出一個領導者哨兵，來完成主從切換的過程。
哨兵A在向其他哨兵發送 sentinel is-master-down-by-addr 命令時，同時要求其他哨兵同意將其設置為Leader，也就是想獲得其他哨兵的投票。
在每一輪選舉中，每個哨兵僅有一票。投票遵循先來先到的原則，如果某個哨兵沒有投給別人，就會投給哨兵A。
首先獲得半數以上投票的哨兵，將被選舉稱為Leader。
這里的哨兵選舉，採用的是Raft演算法。這里不對Raft做詳細的探討，有興趣的同學，可以參考我的另外一篇文章 22張圖，帶你入門分布式一致性演算法Raft
該文章採用大量的圖例，相信你可以從中學習到全新的知識，從而打開分布式一致性演算法的大門，大夥們記得等我搞完Paxos與Zab。
過半投票機制也常用於很多演算法中，例如RedLock，在半數以上的節點上加鎖成功，才代表申請到了分布式鎖，具體可參考這篇文章的最後 我用了上萬字，走了一遍Redis實現分布式鎖的坎坷之路，從單機到主從再到多實例，原來會發生這么多的問題
在Zookeeper選舉中，同樣也用到了過半投票機制，在這篇文章中 面試官：能給我畫個Zookeeper選舉的圖嗎？ 我從源碼角度分析了Zookeeper選舉的過程。
在選舉到領導者哨兵後，將由該哨兵完成故障恢復工作。
故障恢復分為以下兩步：
詳細說一下第一步，挑選是有條件的。首先要過濾出不健康的節點，再按某種規則排序，最後取第一個從庫，我們直接從源碼入手：
因此，以下從庫會被過濾出：
剩下的節點，就是健康的節點，此時再執行一次快速排序，排序的規則如下：
本文算是Redis哨兵的一個入門文章，主要講了哨兵的作用，例如監控、選主和通知。
在Redis讀寫分離的情況下，使用哨兵可以很輕松地做到故障恢復，提升了整體的可用性。
但哨兵無法解決Redis單機寫的瓶頸，這就需要引入集群模式，相應的文章也被列為明年的寫作計劃中。
</article>
⑧ 藉助Redis Bitmap實現簡單的布隆過濾器
在之前的 一篇文章 中，我們已經深入理解了布隆過濾器的基本原理，並且了解到它在緩存系統中有較多的應用。Redis提供的Bitmap正好能夠作為布隆過濾器所需要的位數組的基礎，本文先簡要介紹Bitmap，然後給出基於它的布隆過濾器實現。
Bitmap在Redis中並不是一個單獨的數據類型，而是由字元串類型（Redis內部稱Simple Dynamic String，SDS）之上定義的與比特相關的操作實現的，此時SDS就被當做位數組了。下面是在redis-cli中使用getbit和setbit指令的操作示例。
Redis的Bitmap是自動擴容的，亦即get/set到高位時，就會主動填充0。此外，還有bitcount指令用於計算特定位元組范圍內1的個數，bitop指令用來執行位運算（支持and、or、xor和not）。相應的用法可以查詢Redis官方文檔等。
下面我們基於Redis（Codis）實現布隆過濾器RedisBloomFilter。根據之前講解布隆過濾器的文章，要初始化一個布隆過濾器的話，需要兩個參數：預估的元素數量，以及可接受的最大誤差（即假陽性率）。另外，我們也需要傳入Jodis的連接池實例JedisResourcePool，以方便在Redis上操作。RedisBloomFilter類的成員和構造方法如下所示。
為了區分出布隆過濾器對應的Key，在原始Key的前面都加上"bf:"前綴。Bitmap長度bitmapLength和哈希函數個數numHashFunctions則利用Guava版實現中的方法來計算。
然後，我們需要計算一個元素被k個哈希函數散列後，對應到Bitmap的哪些比特上。這里仍然借鑒了Guava的BloomFilterStrategies實現，採用MurmurHash和雙重哈希進行散列。為了應用簡單，假設所有元素固定為字元串類型，不用泛型。
然後我們就可以通過Jedis的setbit()和getbit()方法來實現向布隆過濾器中插入元素與查詢元素是否存在的邏輯了。一個元素會對應多個比特，為了提高效率，流水線就派上用場了。另外，setbit指令不會重置對應Key的過期時間戳。
完畢，寫個簡單的單元測試吧。假設現在用布隆過濾器來存儲已讀帖子的ID，Key中包含用戶ID和時間。每天預估的每用戶最大閱讀量是3000篇，最大誤差3%。
觀察輸出。
⑨ Redis底層數據結構解密
一：摘要概述
很多 redis 的使用者都可以清晰明白的道出Redis中常用的對象如string、list、hash、set、zset,一些場景比較豐富的使用者可能會說布隆過濾器、geo、Hash等。但是對於這些對象底層實現的數據結構卻是知之甚少,將會詳細闡述redis中的底層數據結構。為了彌補大家的創傷，今天分享Redis底層數據結構內容。
二：SDS
string作為redis中常用對象之一,普遍用於用戶信息緩存等場景。當string對象中encoding編碼為embstr或raw時都是採用sds作為其底層實現
2.1 SDS結構
源碼文件位於redis安裝目錄src下的sds.h,sds聲明了五種頭部類型,分別為sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64。根據字元串長度創建不同頭部的sds實例
struct __attribute__ ((__packed__)) sdshdr8 {
uint8_t len;
uint8_t alloc;
unsigned char flags;
char buf[];
};
屬性名稱作用含義
len字元串長度
alloc預分配空間大小
flags低三位用於表示sds類型,可以查看sds.h文件76-82行定義
buf[]存儲字元串用數組
2.2 SDS與C字元串區別
區別描述
長度計算 c中的字元串長度計算需要數組遍歷,但是redis中的sds自身維護了len屬性。所以O(1)時間復雜度即可
緩沖區溢出c中字元串更改如果未提前做好內存分配則會內存溢出,但是sds則會根據alloc與len計算預留內存是否足夠分配重新申請內存
動態擴展 緩沖區溢出已經闡述這個概念,sds的內存空間會在字元串內容變更時自動擴展計算。策略為當字元換小於1M時*2翻倍,大於1M時每次擴容1M
惰性釋放 與空間預分配相似操作的還有內存惰性釋放,即字元串刪除某些內容後所佔用的內存空間並不會立即釋放,後續字元串變更擴展就無需再申請內存
二：ZipList
ziplist可以說把redis對於內存的極致操作體現的淋漓盡致,鏈表除了節點值之外還需要維護前後節點兩個指針,並且還會造成內存碎片。壓縮列表緊湊的內存布局,所有節點都維護在整塊內存中處理
2.1 ZipList結構
屬性名稱作用含義
zlbytes列表健佔用內存的總位元組數,在對列表健內存重分配或者是計算zlend的時候使用
zltail 指向壓縮列表起始地址的指針
zllen 壓縮列表的節點數量
entry壓縮列表保存的節點數據
zlend壓縮列表的尾節點
2.2 Entry節點結構
屬性名稱作用含義
previous_entry_length 位元組為單位記錄上一個節點的長度,如果上一個位元組長度小於254佔用1位元組。大於254佔用5位元組,第一個位元組設置為OxFE(十進制254),後面四個位元組儲存長度
encoding 記錄content記錄的數據類型以及長度。長度一、二、五位元組,值的最高位為00、01、10表示類型為位元組數組,長度使用除去最高位的其它位記錄。11開頭表示儲存整數,除去最高位其他位置表示content數據長度
content 記錄壓縮列表記錄的數據