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發生了重啓，所有的用戶也需要重新訂閱頻道。
那如果基於Redis Stream來構建IRC呢？
創建頻道
發送消息
接收消息
獲取歷史消息
前面我們提到了， Redis Stream 和 PUB/SUB 相比，一個重要的區別是， Redis Stream 可以獲取歷史發送的消息，所以當一個用戶斷開連接重新加入IRC時，可以通過如下方式獲取歷史消息：
Redis Stream實戰——IoT數據採集
Redis除了強大而且豐富的數據結構支持，還有一個很重要的能力是跨平臺，甚至是作爲一個嵌入式的存儲系統跑在基於ARM的平臺上，比如作者之前就宣稱， Redis成功的跑在了“樹莓派”上。
試想一下，在IoT時代，會有無數隨時隨地可以接入互聯網的智能設備，你家裏的冰箱會實時的彙報，冰箱裏面有哪些食物，數量多少，新鮮程度如何，空調會彙報現在溫度多少，空氣質量如何，你的車會不斷的彙報發動機的各項數據，變速箱的各項數據，車內空氣的各項數據。這麼多的IoT設備會形成巨大的數據洪流，採集完成後在雲端進行分析，產生巨大的用戶價值。
這些數據雖然內容各個不同，但是都有一個共同的特點，都是一種時序數據。看到這裏，你可能會突然發現，Redis Stream從設計初就是爲了支持時間序列數據而生（見第一部分Redis Stream介紹），Redis又成功的跑在了ARM平臺，而未來物聯網會有 萬億級的設備基於ARM平臺 。所以，我們不由自主的可以猜想，除了現在在各種互聯網服務中作爲Cache和KV存儲廣泛應用，Redis下一個大放異彩的領域也許就在物聯網。
上面這個圖，就是一個典型的物聯網設備信息採集，分析，展示的架構。Redis作爲一個嵌入式的存儲系統跑在各個IoT設備上，各個設備使用 Redis Stream 暫存產生的時序數據，然後再異步的推送到雲端。雲上部署的各個業務程序，會讀取推送的原始數據，基於一定的規則進行分析，然後將結果寫入可靠的數據存儲系統。用戶讀取結果，在APP或者web頁面上進行展示，從而整個系統形成一個閉環。