建站
咨詢
售后
建站咨詢
新聞中心
?雖然流可以是處理大量數(shù)據(jù)的有效方式，但它們也有自己的挑戰(zhàn)。讓我們看看其中的一些。
成都做網(wǎng)站、網(wǎng)站建設(shè)服務(wù)團(tuán)隊(duì)是一支充滿著熱情的團(tuán)隊(duì)，執(zhí)著、敏銳、追求更好，是創(chuàng)新互聯(lián)的標(biāo)準(zhǔn)與要求，同時(shí)竭誠(chéng)為客戶提供服務(wù)是我們的理念。成都創(chuàng)新互聯(lián)把每個(gè)網(wǎng)站當(dāng)做一個(gè)產(chǎn)品來(lái)開(kāi)發(fā)，精雕細(xì)琢，追求一名工匠心中的細(xì)致，我們更用心！
1. 如果消費(fèi)者無(wú)法像制作人創(chuàng)建塊那樣快速處理塊，會(huì)發(fā)生什么？一個(gè)例子：如果消費(fèi)者比生產(chǎn)者慢50%，會(huì)怎么樣？如果我們從一個(gè)10GB的文件開(kāi)始，這意味著當(dāng)生產(chǎn)者處理完所有10GB時(shí)，消費(fèi)者只處理了5GB。剩余的5GB在等待處理時(shí)會(huì)發(fā)生什么情況？突然之間，分配給仍然需要處理的數(shù)據(jù)的50到100字節(jié)必須擴(kuò)展到5GB。
圖1：如果消費(fèi)者的速度比生產(chǎn)者慢，則需要額外的內(nèi)存
2. 這只是一個(gè)噩夢(mèng)場(chǎng)景。還有其他的。例如，如果消費(fèi)者在處理一條生產(chǎn)線時(shí)突然失效，會(huì)發(fā)生什么情況？你需要一種跟蹤正在處理的行的方法，以及一種允許重新讀取該行和隨后的所有行的機(jī)制。
圖2：當(dāng)消費(fèi)者失效時(shí)
3. 最后，如果你需要能夠處理不同的事件并將其發(fā)送給不同的消費(fèi)者，會(huì)發(fā)生什么？此外，如果增加額外的復(fù)雜性，一個(gè)消費(fèi)者的進(jìn)程依賴于另一個(gè)消費(fèi)者，那么就有相互依賴的進(jìn)程，會(huì)怎么樣？一個(gè)真正的風(fēng)險(xiǎn)是，你最終會(huì)遇到一個(gè)復(fù)雜的、緊耦合的、難以管理的單體系統(tǒng)——隨著不斷添加和刪除不同的生產(chǎn)者和消費(fèi)者，這些需求將不斷變化。
舉個(gè)例子（圖3），假設(shè)我們有一家大型零售店，擁有數(shù)千臺(tái)服務(wù)器，支持通過(guò)網(wǎng)絡(luò)應(yīng)用和移動(dòng)應(yīng)用進(jìn)行購(gòu)物。
假設(shè)我們正在處理三種與支付、庫(kù)存和Web服務(wù)器日志相關(guān)的數(shù)據(jù)，每種數(shù)據(jù)都有一個(gè)相應(yīng)的消費(fèi)者：“支付處理器”、“庫(kù)存處理器”和“Web服務(wù)器事件處理器”。此外，兩個(gè)消費(fèi)者之間存在著重要的相互依賴關(guān)系。在處理庫(kù)存之前，需要先驗(yàn)證付款。最后，每種類型的數(shù)據(jù)都有不同的目的地。如果是支付事件，則將輸出發(fā)送到所有系統(tǒng)，如數(shù)據(jù)庫(kù)、電子郵件系統(tǒng)、CRM等。如果是Web服務(wù)器事件，則僅將其發(fā)送到數(shù)據(jù)庫(kù)。如果是庫(kù)存事件，則將其發(fā)送到數(shù)據(jù)庫(kù)和CRM。
你可以想象，這很快就會(huì)變得非常復(fù)雜和混亂。這還不包括我們需要為每個(gè)消費(fèi)者處理的慢消費(fèi)者和容錯(cuò)問(wèn)題。
圖3：緊耦合的挑戰(zhàn)，因?yàn)橛卸鄠€(gè)生產(chǎn)者和消費(fèi)者
當(dāng)然，所有這些都假設(shè)你正在處理一個(gè)單體架構(gòu)，你有一臺(tái)服務(wù)器接收和處理所有事件。你將如何處理微服務(wù)架構(gòu)？在這種情況下，許多小型服務(wù)器，即微服務(wù)，將處理事件，它們都需要能夠相互通信。突然間，你不僅僅有多個(gè)生產(chǎn)者和消費(fèi)者，它們還分散在多個(gè)服務(wù)器上。
微服務(wù)的一個(gè)關(guān)鍵好處是，它們解決了根據(jù)不斷變化的需求擴(kuò)展特定服務(wù)的問(wèn)題。不幸的是，微服務(wù)只解決了一些問(wèn)題。我們的生產(chǎn)者和消費(fèi)者之間仍然存在緊耦合，我們保留了庫(kù)存微服務(wù)和支付服務(wù)之間的依賴關(guān)系。我們?cè)谧畛醯牧髅襟w示例中指出的問(wèn)題仍然存在：
- 我們還沒(méi)有弄清楚當(dāng)消費(fèi)者崩潰時(shí)該怎么辦。
- 我們還沒(méi)有找到一種管理慢消費(fèi)者、不會(huì)迫使我們大幅擴(kuò)大緩沖區(qū)規(guī)模的方法。
- 我們還沒(méi)有辦法確保數(shù)據(jù)不會(huì)丟失。
這些只是一些主要挑戰(zhàn)。讓我們看看如何解決這些問(wèn)題。
圖4：微服務(wù)世界中緊耦合的挑戰(zhàn)
專用流處理系統(tǒng)
正如我們所看到的，流可以非常適合處理大量數(shù)據(jù)，但也帶來(lái)了一系列挑戰(zhàn)。為了解決這些挑戰(zhàn)，引入了新的專用系統(tǒng)，如Apache Kafka和Redis Streams。在Kafka和Redis流的世界中，服務(wù)器不再像流那樣位于中心，其他一切都圍繞著它們。
數(shù)據(jù)工程師和數(shù)據(jù)架構(gòu)師經(jīng)常共享這種以流為中心的世界觀。當(dāng)流成為中心時(shí)，一切都是流水線型的，這并不奇怪。
圖5顯示了前面看到的緊耦合示例的直接映射。讓我們看看它在高層次上是如何工作的。
- 在這里，流和數(shù)據(jù)（事件）是一等公民，而不是處理它們的系統(tǒng)。
- 任何有興趣發(fā)送數(shù)據(jù)（生產(chǎn)者）、接收數(shù)據(jù)（消費(fèi)者）或同時(shí)發(fā)送和接收數(shù)據(jù)（生產(chǎn)者和消費(fèi)者）的系統(tǒng)都連接到流處理系統(tǒng)。
- 由于生產(chǎn)者和消費(fèi)者是解耦的，因此可以隨意添加其他消費(fèi)者或生產(chǎn)者。你可以聽(tīng)任何你想聽(tīng)的事件。這使得它非常適合微服務(wù)架構(gòu)。
- 如果消費(fèi)者速度較慢，則可以通過(guò)添加更多消費(fèi)者來(lái)增加消費(fèi)。
- 如果一個(gè)消費(fèi)者依賴于另一個(gè)消費(fèi)者，你可以簡(jiǎn)單地監(jiān)聽(tīng)該消費(fèi)者的輸出流，然后進(jìn)行處理。例如，在上圖中，庫(kù)存服務(wù)在處理庫(kù)存事件之前從庫(kù)存流（紫色）和支付處理流（橙色）的輸出接收事件。這就是解決相互依賴問(wèn)題的方法。
- 流中的數(shù)據(jù)是持久的（與在數(shù)據(jù)庫(kù)中一樣）。任何系統(tǒng)都可以隨時(shí)訪問(wèn)任何數(shù)據(jù)。如果由于某種原因數(shù)據(jù)沒(méi)有被處理，你可以重新處理它。
許多流挑戰(zhàn)一度看似艱巨，甚至無(wú)法克服，但只要把流放在中心，就可以輕易解決。這就是為什么越來(lái)越多的人在他們的數(shù)據(jù)層中使用Kafka和Redis Streams，這也是為什么數(shù)據(jù)工程師將流視為世界的中心。
本文題目：Kafka和Redis如何解決流處理挑戰(zhàn)
文章出自：http://www.dlmjj.cn/article/dppdhps.html
