在程式設計師這個圈子打拼了太多年，見過太多的程式設計師使用redis，其中一部分喜歡把redis做快取（cache）使用，其中最典型的當屬儲存使用者session，除此之外，把redis作為訊息佇列使用也不在少數，可見redis在網際網路中應用是多麼的廣泛。
redis作為訊息佇列使用，redis支援的資料結構是可以支撐這類業務，主要是利用了list這種資料結構的特性。redis的列表相當於程式語言裡面的 linkedlist，是乙個雙向的列表結構，這意味著列表新增和刪除元素是非常快的，時間複雜度為o(1)，但是查詢乙個元素的時候需要遍歷列表，時間複雜度為o(n)。由於列表的元素操作和訊息佇列操作類似，所以redis可以適用於訊息佇列的場景，當然，在適用於的棧的場景下也可以勝任。
需要提醒一下，生產環境中如果對訊息的可靠性有十分高的要求（比如訂單支付的消費訊息），請使用專業的訊息佇列（例如：rmq，amq等），對訊息的丟失有一定容忍度的程式完全可以使用redis，例如我們的日誌收集程式列表這種資料結構的命令為
缺陷移出並獲取列表的第乙個元素， 如果列表沒有元素會阻塞列表直到等待超時或發現可彈出元素為止。blpop key1 [key2 ] timeout
移出並獲取列表的最後乙個元素， 如果列表沒有元素會阻塞列表直到等待超時或發現可彈出元素為止。
brpop key1 [key2 ] timeout
從列表中彈出乙個值，將彈出的元素插入到另外乙個列表中並返回它； 如果列表沒有元素會阻塞列表直到等待超時或發現可彈出元素為止。
brpoplpush source destination timeout
通過索引獲取列表中的元素
lindex key index
在列表的元素前或者後插入元素
linsert key before|after pivot value
獲取列表長度
llen key
移出並獲取列表的第乙個元素
lpop key
將乙個或多個值插入到列表頭部
lpush key value1 [value2]
將乙個值插入到已存在的列表頭部
lpushx key value
獲取列表指定範圍內的元素
lrange key start stop
移除列表元素
lrem key count value
通過索引設定列表元素的值
lset key index value
對乙個列表進行修剪(trim)，就是說，讓列表只保留指定區間內的元素，不在指定區間之內的元素都將被刪除。
ltrim key start stop
移除列表的最後乙個元素，返回值為移除的元素。
rpop key
移除列表的最後乙個元素，並將該元素新增到另乙個列表並返回
rpoplpush source destination
在列表中新增乙個或多個值
rpush key value1 [value2]
為已存在的列表新增值
rpushx key value
訊息佇列的本質還是消費者和生產者的問題，只要是這樣的場景，就會涉及到兩端不平衡的情況，具體可表現為：
生產者生產速度大於消費者消費速度，面臨訊息不斷堆積的問題，隨著訊息資料的堆積，佇列是開啟限流措施，還是丟棄某些訊息，更或者是把訊息資料進行持久化。對於基於redis實現的訊息佇列，一般為可忍受部分訊息丟失的業務，所以很多人選擇丟棄訊息的方案。另一種方案是基於redis單執行緒機制，可以增加消費者數量，這也是僅僅針對訊息只被消費一次的場景。當然也可以選擇持久化方案，但是會對redis的效能產生影響。
消費者消費速度大於生產者生產速度，有的同學會說，這樣挺好啊，是，在某種意義上是比反過來的那個場景要好一些，畢竟可以避免產生訊息的堆積問題。但是消費者沒有訊息消費，會導致消費者程序一直在那裡浪費cpu資源，而且還會把redis的qps拉高。類似於這種死迴圈的場景，一般而且最常用的解決方案是讓執行緒sleep 一小段時間，既降低了消費端cpu也降低了redis的qps。 但是sleep會有乙個問題，會導致處理訊息的延遲，例如sleep了一秒，那訊息的延遲處理就有可能會延遲一秒，雖然在大部分場景下這都不是什麼問題，但是作為程式設計師怎麼能不追求極致和完美呢？
關於訊息延遲的問題，最暴力簡單的方式就是增加消費客戶端，這樣可用多消費端交錯的方式來縮小延遲的間隔，當然redis的設計者也考慮了這個問題，所有有了blpop 命令
redis blpop 命令移出並獲取列表的第乙個元素， 如果列表沒有元素會阻塞列表直到等待超時或發現可彈出元素為止。redis 127.0.0.1:6379> blpop list1 list2 .. listn timeout而且還可以設定超時自動返回，豈不是完美。但是還要順便一句，redis的連線在空閒一段時間後，服務端可能會主動斷開，blpop命令會丟擲異常，所以還要做好了重試或者其他策略為好。如果作為專業的訊息佇列，乙個訊息被多個不同的業務消費（乙個訊息被消費多次）是必須要支援的，但是redis是基於自己的list資料結構來實現的偽佇列，所以這種業務場景下就不要考慮redis了，或者自己封裝乙個類似分發器的中介軟體也可以。
基於redis的訊息佇列沒有ack的保證，換句話說，乙個訊息是否被正常處理redis是不知道的，這在很大程度上限制了它的適用場景。
我還是建議不要用redis做專業的mq使用，畢竟mq這種場景不是redis的設計初衷，但是太多人把redis做mq使用，於是redis的作者基於redis的核心**實現了乙個訊息佇列：disque，也許未來會作為redis的核心元件,位址為
除了disque，redis stream也是乙個把redis作為mq的比較好的解決方案，有興趣的同學可以研究一下。
千萬不要把任何乙個業務場景想象的太簡單過關斬將 zabbix你都監控哪些引數
面試中經常會被問到一些技術問題，面試官一方面是看你對於當前技術的點的掌握情況，另一方面是判斷你是否在公司裡幹過，畢竟很多技術只要自學一下就能應付面試。今天我們來聊聊，面試中那些高頻的問題，比如zabbix你都監控哪些引數。一.原理解釋 說到監控，在運維這個行業其實有很多開源的監控方案，目前最常見的就...
過關斬將 專欄改名為 運維面試秘籍 公告
我們的專欄改名了，一開始的名字叫 過關斬將 但從今天起，我們的專欄名字改為 運維面試秘籍 其實說是運維面試，但裡面很多面試技巧是相通的，不管你從事的是運維還是開發，都會對你有所幫助。不管你是運維小白，還是運維老鳥，這個系列的運維技巧都會適合你，尤其是剛從培訓機構培訓出來，準備包裝經驗的小夥伴，這個專...
程式設計師眼中的Redis
redis 是用c語言編寫的記憶體中的資料結構儲存系統，可以用來作資料庫 快取 訊息中介軟體.資料結構 字串 strings 值是任何種類的字串 雜湊 hashs 值是map 字典，陣列 鍊錶，不管讀多還是寫多都能很好的效能 列表 lists 鍊錶或佇列或棧 集合 sets 無序集合，可用交集 差集...