Redis Stream應用案例

時間 2019-11-12

原文原文鏈接

摘要： Redis Stream Redis最新的大版本5.0已經RC1了，其中最重要的Feature莫過於Redis Stream了，關於Redis Stream的基本使用介紹和設計理念能夠看我以前的一篇文章（Redis Stream簡介）。web

Redis Stream

Redis最新的大版本5.0已經RC1了，其中最重要的Feature莫過於Redis Stream了，關於Redis Stream的基本使用介紹和設計理念能夠看我以前的一篇文章（Redis Stream簡介）。Redis Stream本質上是在Redis內核上（非Redis Module）實現的一個消息發佈訂閱功能組件。相比於現有的PUB/SUB、BLOCKED LIST，其雖然也能夠在簡單的場景下做爲消息隊列來使用，可是Redis Stream無疑要完善不少。Redis Stream提供了消息的持久化和主備複製功能、新的RadixTree數據結構來支持更高效的內存使用和消息讀取、甚至是相似於Kafka的Consumer Group功能。今天咱們重點關注怎麼在實際業務場景下去使用Redis Stream。網絡

Redis Stream實戰——IRC系統

相信你們對IRC都比較瞭解了（還記得被和諧掉的xx聊天室嗎:-)），不少知名的開源項目（包括Redis）都有本身的IRC頻道，方便開發者和使用者實時的進行思想火花的碰撞，咱們今天介紹的主角——Redis Stream，自己就是起源於IRC中一個用戶的idea。IRC的模型以下，數據結構

在某個IRC頻道中的用戶，既能夠向全部的其餘用戶自由的發送消息，也能夠接收其餘全部用戶發送的消息。若是要基於Redis來構建一個IRC系統，那咱們不禁自主的會想到使用Redis的PUB/SUB功能，架構

能夠看到，基於PUB/SUB，只須要全部的用戶(client)都訂閱(subscribe)同一個IRC頻道(channel1)，就能夠接收全部用戶發出的消息了。發出消息時，只需使用發佈命令(publish)命令便可。整個業務邏輯很是的清晰簡單，這也是Redis強大和流行的重要緣由——提供的功能和數據結構能儘量提高開發者的開發效率。異步

可是基於PUB/SUB構建的IRC，有一個問題是PUB/SUB的消息模型是Fire and Forgot。也就是說Redis自己並不保存任何歷史消息，若是IRC中某個用戶的網絡鏈接出現異常，從新加入IRC後，他是看不到斷鏈期間的聊天記錄的，新加入的用戶一樣也看不到最近一段時間的歷史記錄，這個對用戶迅速的理解當前討論的問題很是不便。此外，若是Redis發生了重啓，全部的用戶也須要從新訂閱頻道。ide

那若是基於Redis Stream來構建IRC呢？阿里雲

建立頻道

發送消息

接收消息

獲取歷史消息
前面咱們提到了，Redis Stream和PUB/SUB相比，一個重要的區別是，Redis Stream能夠獲取歷史發送的消息，因此當一個用戶斷開鏈接從新加入IRC時，能夠經過以下方式獲取歷史消息：

Redis Stream實戰——IoT數據採集

Redis除了強大並且豐富的數據結構支持，還有一個很重要的能力是跨平臺，甚至是做爲一個嵌入式的存儲系統跑在基於ARM的平臺上，好比做者以前就宣稱，Redis成功的跑在了「樹莓派」上。idea

試想一下，在IoT時代，會有無數隨時隨地能夠接入互聯網的智能設備，你家裏的冰箱會實時的彙報，冰箱裏面有哪些食物，數量多少，新鮮程度如何，空調會彙報如今溫度多少，空氣質量如何，你的車會不斷的彙報發動機的各項數據，變速箱的各項數據，車內空氣的各項數據。這麼多的IoT設備會造成巨大的數據洪流，採集完成後在雲端進行分析，產生巨大的用戶價值。spa

這些數據雖然內容各個不一樣，可是都有一個共同的特色，都是一種時序數據。看到這裏，你可能會忽然發現，Redis Stream從設計初就是爲了支持時間序列數據而生（見第一部分Redis Stream介紹），Redis又成功的跑在了ARM平臺，而將來物聯網會有萬億級的設備基於ARM平臺。因此，咱們不禁自主的能夠猜測，除了如今在各類互聯網服務中做爲Cache和KV存儲普遍應用，Redis下一個大放異彩的領域也許就在物聯網。設計

上面這個圖，就是一個典型的物聯網設備信息採集，分析，展現的架構。Redis做爲一個嵌入式的存儲系統跑在各個IoT設備上，各個設備使用Redis Stream暫存產生的時序數據，而後再異步的推送到雲端。雲上部署的各個業務程序，會讀取推送的原始數據，基於必定的規則進行分析，而後將結果寫入可靠的數據存儲系統。用戶讀取結果，在APP或者web頁面上進行展現，從而整個系統造成一個閉環。