Redis5.0之Stream案例應用解讀

非常高興有機會和大家在這里交流Redis5.0之Stream應用。今天的分享更多的是一個拋磚引玉，歡迎大家提出更多關于Redis的思考。

首先，我們來個假設，這里有個杯子，這個杯子是去年我老婆送的，送的原因是我以前的杯子保溫性能太好，導致我很少能喝上水，而這樣敞口的杯子能促使我多喝水。雖然這杯子在商家的貨架上只是千千萬萬只杯子中的一只，但是它對我來說仍然是不同的。不同的是過往，是記憶。這記憶說起來是數據的一類，這類數據也讓我們生活更美好。

這種數據的特點是什么呢？產生是一次產生的，但是我們會希望經常看到，希望將這種美好填充到各種東西中。而杯子本身也可以說是一個生產-消費模型：數據出現，然后被各種消費。

消費的一種情況

因此，杯子不僅僅是一個杯子，實際上背后的可挖掘的東西非常多。意義越多，連接越多，關系越復雜，我們數據量也越大，所以，希望價值最大化的我們，就產生了大量希望被高速處理的數據，這數據體現在系統上，往往就成了數據洪峰，成了系統難以承受之重。

在很多情況下，我們采集端所包含的信息可能遠遠超出這個數值。例如，霧霾天里，我們的房間，我們的位置，它的空氣質量是怎樣的，各項污染物參數是多少？我們這個辦公區，這棟樓，這個房間的空氣質量又是怎樣的，電力消耗是怎樣的，行人狀況，車輛數據，等等。上億的數據，涉及互聯互通，需要保證高并發可靠傳輸。同時數據收集上來后要進行處理和存儲、分析，對系統的挑戰都是巨大的。

巨大的、網狀的互聯互通，需要帶寬巨大、順暢的管道；這么多的數據，會形成巨大的數據洪流，采集完成后在云端進行分析，也可以產生巨大的用戶價值。

區域檢測監控

這些數據雖然形式各不相同，但是也有共同的特點，就是和時間有關。例如，一戶人家，從主臥到書房，從客廳到餐廳，不同的房間不同的位置放置一些空氣監測儀，監測儀里面的化學藥劑接觸空氣中的各種成分，隨時間緩慢變化，變化過程中產生信號，這些信號經過初步整理計算，形成一個平面的空氣質量數據；從清晨到傍晚，從春到秋，不同的時間點，甲醛、TVOC等各種污染物成分的數值也不一樣，因此平面的數據在這里形成了時序數據。

湊巧的是，Redis的流就是專門為時序數據設計的。我們回顧一下Redis的流的存儲設計：主線是一個消息鏈表，將所有消息按照順序串起來。因此Redis的流在這方面支持度是非常不錯的，我們可以將平面內的數據按照時間序列加入到Redis流里面。當然這些數據我們可能需要初步處理，因此我們也可以使用Redis的其它數據結構，例如list，再憑借Redis對Lua腳本的支持，用很少的外部應用邏輯驅動它完成處理。這處理因為是在Redis內部完成，所以整體上來說，計算消耗是比較低的。Redis原本憑借它原生C的優勢，還有內存實現和數據結構的優化，內存占用就比較小，CPU要求也低，使它在小型設備上高效率的運行成為可能。未來可能會有萬億級的智能設備基于ARM平臺，前景還是非常廣闊的。

所以從設備端，我們已經可以使用Redis來完成數據的臨時存儲和基本的處理，加入Redis流后，再使用MQTT、TCP、808等協議，通過網絡上傳數據。通常我們需要采集的區域會比較廣，設備數量很多，因此數據也比較多，那數據可能還需要在局部，進行初步的匯總處理。這里數據洪峰往往就開始顯露了。如果我們期望保存進mysql等數據庫，通常是頂不住壓力的。因為數據庫的原子性、一致性、隔離性、持久性等，對性能的損耗是比較大的。所以這里我們可以使用Redis來接收洪峰監測數據，然后分發給存儲服務、處理服務、展示服務，等等。在分發處理完成前，Redis本身作為高速內存存儲，流里面的數據也是可以作為普通的緩存數據，被反復訪問的，所以也在一定程度上，對消息消費前的空檔期，做了補充，也給予了后臺更寬裕一些的處理時間。

我們來回顧一下其中Redis的使用：快，Redis的性能很高；小，輕便簡潔，對內存和CPU要求小；豐富，數據結構豐富，用法多樣；時序，流是為時序應用設計的；支持Lua腳本，能自定義邏輯。

飯要一口一口吃，路得一步一步走。讓我們回到技術本身，從巨大的洪流里截取出一部分和Redis有關的，還原成基本的工作流程。

我這里截取的是空氣監測的存儲和處理。我們來看一下示意圖，儀器上報數據，Redis接收數據流，并且提供給存儲、分析消費，同時供應用使用。

檢測數據產生，組別建立

首先來了一條空氣數據，檢測數據產生，存儲、分析消費組也建立起來了。空氣數據包含了hcho和tvoc污染物值。我們看看命令，這里有個maxlen，這是為了避免隊列過長，所以設置的最大長度。為什么需要這么設置呢？因為Redis的流順序消費后，甚至xdel后，數據并不會被清理，隊列會越來越長，所以這里我們設置個最大長度，避免溢出。

這里有兩個存儲服務。假設存儲相對比較慢，為了能及時處理，我們構建了更多的存儲服務。

我們看看存儲和分析服務消費數據的過程。這里兩個存儲服務都嘗試獲取數據，但是很明顯，只有一個獲取到了數據進行處理。分析在這時嘗試取3條數據加入分析處理，但是因為stream里只有1條，所以這里只取到1條。

存儲、分析服務消費數據

分析服務率先完成了數據的消費，所以在分析服務里馬上答復了一個ack給stream，告訴它，已經消費完成了。隨后存儲服務也完成了存儲，存儲服務也發送了個ack給stream。

消費完成，答復ACK

分析服務剛剛答復完ack，因為某些原因，重啟了。分析服務啟動的時候，不清楚消費到哪里了，所以嘗試從初始位置開始消費。這里因為前面已經消費過并且返回了ack，所以沒有取到任何可消費的數據。如果有數據沒消費完成的，通過這種方式可以進行再次消費，所以服務在消費時需要能夠處理重入。

分析服務重啟，開頭消費起

在這里我們看到，檢測數據也在不停地到來，存儲和分析服務同樣按照前面的規則消費。分析服務按照自己的能力，依然嘗試一次取用3條，根據結果我們可以看到，這次分析服務取到了兩條消費數據。

新檢測數據

分析服務消費數據

存儲服務呢？兩個存儲服務也都取到了數據進行消費。

存儲服務消費數據

這時候用戶開始訪問應用了，他打算看下污染情況是怎樣的。我們都能理解，剛剛購買一件新東西的時候，我們會更傾向于馬上看看，所以這里用戶肯定是期望看到污染物情況的。但是這時數據既沒有分析完畢，也沒有存儲完畢，我們需要怎么處理呢？

應用服務可以先檢測狀態，發現需要的數據還沒有處理完成，因此從常規緩存里面獲取明顯是獲取不到的。所以應用直接從stream里獲取了，我們可以看到，用戶順利地秒看到了監測數值，對身邊的狀況馬上有了一個了解。用戶想看看還有沒有新數據，所以在應用上點了下刷新，我們看到，這次仍然能從stream中獲取到需要的數據。當然，如果用戶想針對性地看看情況，應用中也可以指定ID讀取。那還有沒有其它方式呢？xrange也是批量取出需要消息的一種方法。

應用使用xread方式讀取數據

應用使用xrange方式截取數據

從這里可以感受到，雖然我們的日子，在時間的流里面一往無前，一去不返了，但幸運的是，在Redis的流里面，我們仍然可以從過往里截取出任意一段，重新品嘗，溫故知新。

回到例子。用戶刷完兩次后，存儲和分析服務處理好數據了，所以存儲和分析服務再次向stream發送ack消息，示意已經處理完成。

消費完畢，返回ack

當然，這些Redis里面的處理，都是一如既往地高性能、高效的。

這里只是一個簡單的截面，一個示意。實際上，Redis原本的使用場景就非常豐富，例如，作為會話緩存，作為頁面的全頁緩存，手機或者網頁的驗證碼，服務訪問的頻率限制，密碼防暴力破解，競技場、吃雞、短視頻女神榜等各種排行榜，點贊、閱讀數等計數器和排行，關注某個標簽、或者某個明星的人，限時優惠活動，證券的實時指標計算，號碼發放器，甚至還有geo地理信息，基于LUA的自定義邏輯，還有訂閱發布，等等，非常豐富。這些都是基于Redis豐富的數據結構，開發出來的使用方式。

羅胖在時間的朋友演講說，大趨勢往往不是一個小趨勢逐步成長起來的，而是趨勢撞擊趨勢，改變帶來改變，逐漸滾動、交織變大的。那么Redis的流，能在這些已經存在的應用場景里，提供怎樣的碰撞？又能在新的領域里，帶來怎樣的趨勢？歡迎大家前來共同討論。

也歡迎大家到華為云分布式緩存免費領取Redis 5.0。現在Redis 5.0是公測階段，可以免費體驗。領取也非常簡單，申請公測，然后花費幾秒創建Redis 5.0實例，就可以了。