Redis5.0之Stream案例應(yīng)用解讀

非常高興有機(jī)會(huì)和大家在這里交流Redis5.0之Stream應(yīng)用。今天的分享更多的是一個(gè)拋磚引玉，歡迎大家提出更多關(guān)于Redis的思考。

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

這種數(shù)據(jù)的特點(diǎn)是什么呢？產(chǎn)生是一次產(chǎn)生的，但是我們會(huì)希望經(jīng)?？吹剑Ｍ麑⑦@種美好填充到各種東西中。而杯子本身也可以說是一個(gè)生產(chǎn)-消費(fèi)模型：數(shù)據(jù)出現(xiàn)，然后被各種消費(fèi)。

消費(fèi)的一種情況

因此，杯子不僅僅是一個(gè)杯子，實(shí)際上背后的可挖掘的東西非常多。意義越多，連接越多，關(guān)系越復(fù)雜，我們數(shù)據(jù)量也越大，所以，希望價(jià)值最大化的我們，就產(chǎn)生了大量希望被高速處理的數(shù)據(jù)，這數(shù)據(jù)體現(xiàn)在系統(tǒng)上，往往就成了數(shù)據(jù)洪峰，成了系統(tǒng)難以承受之重。

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

巨大的、網(wǎng)狀的互聯(lián)互通，需要帶寬巨大、順暢的管道；這么多的數(shù)據(jù)，會(huì)形成巨大的數(shù)據(jù)洪流，采集完成后在云端進(jìn)行分析，也可以產(chǎn)生巨大的用戶價(jià)值。

區(qū)域檢測監(jiān)控

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

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

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

我們來回顧一下其中Redis的使用：快，Redis的性能很高；小，輕便簡潔，對內(nèi)存和CPU要求?。回S富，數(shù)據(jù)結(jié)構(gòu)豐富，用法多樣；時(shí)序，流是為時(shí)序應(yīng)用設(shè)計(jì)的；支持Lua腳本，能自定義邏輯。

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

我這里截取的是空氣監(jiān)測的存儲(chǔ)和處理。我們來看一下示意圖，儀器上報(bào)數(shù)據(jù)，Redis接收數(shù)據(jù)流，并且提供給存儲(chǔ)、分析消費(fèi)，同時(shí)供應(yīng)用使用。

檢測數(shù)據(jù)產(chǎn)生，組別建立

首先來了一條空氣數(shù)據(jù)，檢測數(shù)據(jù)產(chǎn)生，存儲(chǔ)、分析消費(fèi)組也建立起來了?？諝鈹?shù)據(jù)包含了hcho和tvoc污染物值。我們看看命令，這里有個(gè)maxlen，這是為了避免隊(duì)列過長，所以設(shè)置的最大長度。為什么需要這么設(shè)置呢？因?yàn)镽edis的流順序消費(fèi)后，甚至xdel后，數(shù)據(jù)并不會(huì)被清理，隊(duì)列會(huì)越來越長，所以這里我們設(shè)置個(gè)最大長度，避免溢出。

這里有兩個(gè)存儲(chǔ)服務(wù)。假設(shè)存儲(chǔ)相對比較慢，為了能及時(shí)處理，我們構(gòu)建了更多的存儲(chǔ)服務(wù)。

我們看看存儲(chǔ)和分析服務(wù)消費(fèi)數(shù)據(jù)的過程。這里兩個(gè)存儲(chǔ)服務(wù)都嘗試獲取數(shù)據(jù)，但是很明顯，只有一個(gè)獲取到了數(shù)據(jù)進(jìn)行處理。分析在這時(shí)嘗試取3條數(shù)據(jù)加入分析處理，但是因?yàn)閟tream里只有1條，所以這里只取到1條。

存儲(chǔ)、分析服務(wù)消費(fèi)數(shù)據(jù)

分析服務(wù)率先完成了數(shù)據(jù)的消費(fèi)，所以在分析服務(wù)里馬上答復(fù)了一個(gè)ack給stream，告訴它，已經(jīng)消費(fèi)完成了。隨后存儲(chǔ)服務(wù)也完成了存儲(chǔ)，存儲(chǔ)服務(wù)也發(fā)送了個(gè)ack給stream。

消費(fèi)完成，答復(fù)ACK

分析服務(wù)剛剛答復(fù)完ack，因?yàn)槟承┰颍貑⒘?。分析服?wù)啟動(dòng)的時(shí)候，不清楚消費(fèi)到哪里了，所以嘗試從初始位置開始消費(fèi)。這里因?yàn)榍懊嬉呀?jīng)消費(fèi)過并且返回了ack，所以沒有取到任何可消費(fèi)的數(shù)據(jù)。如果有數(shù)據(jù)沒消費(fèi)完成的，通過這種方式可以進(jìn)行再次消費(fèi)，所以服務(wù)在消費(fèi)時(shí)需要能夠處理重入。

分析服務(wù)重啟，開頭消費(fèi)起

在這里我們看到，檢測數(shù)據(jù)也在不停地到來，存儲(chǔ)和分析服務(wù)同樣按照前面的規(guī)則消費(fèi)。分析服務(wù)按照自己的能力，依然嘗試一次取用3條，根據(jù)結(jié)果我們可以看到，這次分析服務(wù)取到了兩條消費(fèi)數(shù)據(jù)。

新檢測數(shù)據(jù)

分析服務(wù)消費(fèi)數(shù)據(jù)

存儲(chǔ)服務(wù)呢？兩個(gè)存儲(chǔ)服務(wù)也都取到了數(shù)據(jù)進(jìn)行消費(fèi)。

存儲(chǔ)服務(wù)消費(fèi)數(shù)據(jù)

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

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

應(yīng)用使用xread方式讀取數(shù)據(jù)

應(yīng)用使用xrange方式截取數(shù)據(jù)

從這里可以感受到，雖然我們的日子，在時(shí)間的流里面一往無前，一去不返了，但幸運(yùn)的是，在Redis的流里面，我們?nèi)匀豢梢詮倪^往里截取出任意一段，重新品嘗，溫故知新。

回到例子。用戶刷完兩次后，存儲(chǔ)和分析服務(wù)處理好數(shù)據(jù)了，所以存儲(chǔ)和分析服務(wù)再次向stream發(fā)送ack消息，示意已經(jīng)處理完成。

消費(fèi)完畢，返回ack

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

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

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

也歡迎大家到華為云分布式緩存免費(fèi)領(lǐng)取Redis 5.0?，F(xiàn)在Redis 5.0是公測階段，可以免費(fèi)體驗(yàn)。領(lǐng)取也非常簡單，申請公測，然后花費(fèi)幾秒創(chuàng)建Redis 5.0實(shí)例，就可以了。