㈠ 藉助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 內存故障診斷及常用運維命令
你是否有過這種困擾：我的數據量非常小，但還是報OOM錯誤？
首先我給大家解釋下，Redis的OOM分兩種
簡短介紹下Redis內存消耗劃分情況，為下文診斷提供思路。上圖可以總結Redis消耗內存分如下幾塊：
使用redis-benchmark持續灌入數據
製造輸入緩沖區壓力（防止干擾，先清空數據再壓測）
壓測幾秒鍾後，觸發OOM
檢查輸入緩沖區內存消耗，能看到客戶端輸入緩沖區消耗總量為 2.4G左右，遠遠超過maxmemory參數設置。
可通過運行上述檢查命令，定位到各客戶端輸入緩沖區的內存消耗（由大到小排序）。
一般如果定位到有連接異常，可以使用如下命令殺掉
為測試方便，我直接把復制積壓緩沖區配置為800M。
開啟redis-benchmark壓測進程
檢查復制積壓緩沖區內存消耗，可以看到因為緩沖區設置過大，數據量才存儲190多M，Redis就無法寫入了。
若客戶端輸出緩沖區太大如何排查？一般該場景比較少見，常見於用到了redis的 monitor 命令
先開啟monitor命令
上文排查過程有些Redis運維命令我認為比較實用，整理如下
腳本執行效果：
㈢ redis布隆過濾器拆分長度
布隆過濾器是一種類似set的數據結構。
Redis布隆過濾器的基本使用
在Redis中，布隆過濾器有兩個基本命令，分別是：
bf.add：添加元素到布隆過濾器中，類似於集合的sadd命令，不過bf.add命令只能一次添加一個元素，如果想一次添加多個元素，可以使用bf.madd命令。
bf.exists：判斷某個元素是否在過濾器中，類似於集合的sismember命令，不過bf.exists命令只能一次查詢一個元素，如果想一次查詢多個元素，可以使用bf.mexists命令。
布隆過濾器的高級使用
上面的例子中使用的布隆過濾器只是默認參數的布隆過濾器，它在我們第一次使用 bf.add 命令時自動創建的。Redis還提供了自定義參數的布隆過濾器，想要盡量減少布隆過濾器的誤判，就要設置合理的參數。
在使用 bf.add 命令添加元素之前，使用 bf.reserve 命令創建一個自定義的布隆過濾器。bf.reserve命令有三個參數，分別是：
key：鍵
error_rate：期望錯誤率，期望錯誤率越低，需要的空間就越大。
capacity：初始容量，當實際元素的數量超過這個初始化容量時，誤判率上升。
如果對應的key已經存在時，在執行bf.reserve命令就會報錯。如果不使用bf.reserve命令創建，而是使用Redis自動創建的布隆過濾器，默認的error_rate是0.01，capacity是 100。
布隆過濾器的 error_rate 越小，需要的存儲空間就越大，對於不需要過於精確的場景，error_rate設置稍大一點也可以。布隆過濾器的capacity設置的過大，會浪費存儲空間，設置的過小，就會影響准確率，所以在使用之前一定要盡可能地精確估計好元素數量，還需要加上一定的冗餘空間以避免實際元素可能會意外高出設置值很多。總之，error_rate和 capacity都需要設置一個合適的數值。
㈣ redis monitor 每列什麼意思
Redis MONITOR是調試命令流回來Redis伺服器處理每一個指令。
它可以有助於理解資料庫發生了什麼事情。此命令都可以通過Redis命令行介面，並通過遠程telnet登錄使用。
為了發現在應用程序中錯誤，看到所有伺服器處理請求的能力是使用的Redis作為資料庫，並作為分布式緩存系統。
㈤ REDIS----配置文件----LATENCY MONITOR
Redis延遲監視子系統在運行時對不同的操作進行采樣，以便收集與Redis實例的可能延遲源相關的數據;
通過延遲命令，用戶可以使用此信息列印圖表和獲取報告;
系統只記錄在等於或大於通過延遲監視器閾值配置指令指定的毫秒數的時間內執行的操作。當其值設置為零時，延遲監視器將關閉;
默認情況下，延遲監視是禁用的，因為如果沒有延遲問題，則通常不需要它，而且收集數據會對性能產生影響，雖然影響很小，但可以在大負載下測量。如果需要，可以在運行時使用命令 「CONFIG SET Latency monitor threshold<millishes>」 輕松啟用延遲監視;
㈥ redis monitor界面怎麼看
/etc/sysctl.conf
添加
vm.overcommit_memory=1
刷新配置使之生效
sysctl vm.overcommit_memory=1
補充介紹：
**如果內存情況比較緊張的話，需要設定內核參數：echo 1 > /proc/sys/vm/overcommit_memory
內核參數說明如下：
overcommit_memory文件指定了內核針對內存分配的策略，其值可以是0、1、2。0， 表示內核將檢查是否有足夠的可用內存供應用進程使用；如果有足夠的可用內存，內存申請允許；否則，內存申請失敗，並把錯誤返回給應用進程。1， 表示內核允許分配所有的物理內存，而不管當前的內存狀態如何。2， 表示內核允許分配超過所有物理內存和交換空間總和的內存
**編輯redis.conf配置文件（/etc/redis.conf），按需求做出適當調整，比如：daemonize yes #轉為守護進程，否則啟動時會每隔5秒輸出一行監控信息save 60 1000 #減小改變次數，其實這個可以根據情況進行指定maxmemory 256000000 #分配256M內存
在我們成功安裝Redis後，我們直接執行redis-server即可運行Redis，此時它是按照默認配置來運行的（默認配置甚至不是後台運 行）。我們希望Redis按我們的要求運行，則我們需要修改配置文件，Redis的配置文件就是我們上面第二個cp操作的redis.conf文件，目前 它被我們拷貝到了/usr/local/redis/etc/目錄下。修改它就可以配置我們的server了。如何修改？下面是redis.conf的主 要配置參數的意義：
daemonize：是否以後台daemon方式運行
pidfile：pid文件位置
port：監聽的埠號
timeout：請求超時時間
loglevel：log信息級別
logfile：log文件位置
databases：開啟資料庫的數量
save * *：保存快照的頻率，第一個*表示多長時間，第三個*表示執行多少次寫操作。在一定時間內執行一定數量的寫操作時，自動保存快照。可設置多個條件。
rdbcompression：是否使用壓縮
dbfilename：數據快照文件名（只是文件名，不包括目錄）
dir：數據快照的保存目錄（這個是目錄）
appendonly：是否開啟appendonlylog，開啟的話每次寫操作會記一條log，這會提高數據抗風險能力，但影響效率。
appendfsync：appendonlylog如何同步到磁碟（三個選項，分別是每次寫都強制調用fsync、每秒啟用一次fsync、不調用fsync等待系統自己同步）
G
㈦ 該怎麼解決 Redis 緩存穿透和緩存雪崩問題
緩存雪崩： 由於緩存層承載著大量請求，有效地 保護了存儲層，但是如果緩存層由於某些原因不能提供服務，比如 Redis 節點掛掉了，熱點 key 全部失效了，在這些情況下，所有的請求都會直接請求到資料庫，可能會造成資料庫宕機的情況。
預防和解決緩存雪崩問題，可以從以下三個方面進行著手：
1、使用 Redis 高可用架構：使用 Redis 集群來保證 Redis 服務不會掛掉
2、緩存時間不一致： 給緩存的失效時間，加上一個隨機值，避免集體失效
3、限流降級策略：有一定的備案，比如個性推薦服務不可用了，換成熱點數據推薦服務
緩存穿透： 緩存穿透是指查詢一個根本不存在的數據，這樣的數據肯定不在緩存中，這會導致請求全部落到資料庫上，有可能出現資料庫宕機的情況。
預防和解決緩存穿透問題，可以考慮以下兩種方法：
1、緩存空對象： 將空值緩存起來，但是這樣就有一個問題，大量無效的空值將佔用空間，非常浪費。
2、布隆過濾器攔截： 將所有可能的查詢key 先映射到布隆過濾器中，查詢時先判斷key是否存在布隆過濾器中，存在才繼續向下執行，如果不存在，則直接返回。布隆過濾器有一定的誤判，所以需要你的業務允許一定的容錯性。