Redmi Buds 4開箱簡(jiǎn)評(píng)：才199還有降噪 可以無(wú)腦入
在上個(gè)月舉辦的Redmi Note11T Pro系列新機(jī)發(fā)布會(huì)上，除了兩款手機(jī)新品之外，Redmi還帶來(lái)了兩款TWS真無(wú)線藍(lán)牙耳機(jī)產(chǎn)品，Redmi Buds 4和Redmi Buds 4 Pro，此前我們?cè)赗edmi Note11T
作為后端開發(fā)人員，有一天你需要回答這個(gè)問(wèn)題：
我需要構(gòu)建一個(gè)使用分布式隊(duì)列的異步應(yīng)用程序，我應(yīng)該使用哪個(gè)代理？ 作為工程師，我們的本能是列出我們了解或希望熟悉的工具（如果它是一種新的和已知的技術(shù)），然后開始使用它。不幸的是，在那個(gè)時(shí)刻，我們錯(cuò)過(guò)了第一個(gè)最重要的問(wèn)題，這個(gè)問(wèn)題需要在所有其他問(wèn)題之前得到答案：我們的現(xiàn)有和有時(shí)未來(lái)的用例/需求是什么，什么工具能最好地解決它們？ 這是我們?cè)谠O(shè)計(jì)一個(gè)重要功能時(shí)的起點(diǎn)，當(dāng)時(shí)工程師的本能占了上風(fēng)。我們的第一個(gè)問(wèn)題不是最重要的問(wèn)題，從那時(shí)開始，我們選擇正確工具的過(guò)程變得不太有效。我們的團(tuán)隊(duì)開了幾次會(huì)，討論了我們對(duì)分布式隊(duì)列的需求，不同技術(shù)的不同限制和特性（來(lái)自不同的范例）讓關(guān)注點(diǎn)遠(yuǎn)離了我們最重要的需求，也遠(yuǎn)離了決策和共識(shí)的實(shí)現(xiàn)。 在那個(gè)時(shí)候，我們決定回到基本問(wèn)題，問(wèn)：我們?cè)噲D解決的用例是什么，沒(méi)有讓步的余地在哪些領(lǐng)域？一如既往，讓我們從需求開始。
在選擇消息代理或事件代理時(shí)，有很多事情要考慮：高可用性、容錯(cuò)性、多租戶、多云區(qū)域支持、能夠支持高吞吐量和低延遲等等，列舉不勝枚舉。
大多數(shù)情況下，當(dāng)閱讀有關(guān)事件代理或消息代理的主要特性時(shí)，我們都是以大多數(shù)公司或產(chǎn)品從未完全使用或需要的最復(fù)雜用例為例的。
作為工程師，生活中有一句常用的話語(yǔ)：
上帝在細(xì)節(jié)中，但魔鬼隱藏在細(xì)節(jié)之間。
在選擇事件代理與消息代理兩個(gè)范式之間，"魔鬼"隱藏在更多的低層技術(shù)考慮因素中，比如：消息的消耗或生成確認(rèn)方法、去重、消息的優(yōu)先級(jí)、消費(fèi)者線程模型、消息的消耗方法、消息的分發(fā)/擴(kuò)散支持、毒藥藥處理等等。
(1) 事件代理
存儲(chǔ)一系列事件。通常，事件會(huì)按到達(dá)事件代理的順序附加到日志（隊(duì)列或主題）上。主題或隊(duì)列中的事件是不可變的，其順序不能更改。
當(dāng)事件發(fā)布到隊(duì)列或主題時(shí)，代理識(shí)別主題或隊(duì)列的訂閱者，并使事件可供多種類型的訂閱者使用。
生產(chǎn)者和消費(fèi)者不需要彼此熟悉。
事件潛在地可以存儲(chǔ)數(shù)天或數(shù)周，因?yàn)樗鼈円坏┍怀晒ο模筒粫?huì)從隊(duì)列/主題中刪除。
(2) 消息代理
用于服務(wù)或組件之間的通信。它通過(guò)異步方式在應(yīng)用程序之間傳輸由生產(chǎn)者接收的消息。
它通常支持隊(duì)列的概念，其中消息通常存儲(chǔ)一段時(shí)間。隊(duì)列中消息的目的是在消費(fèi)者可用于處理消息并在成功消耗后刪除消息。
不能保證隊(duì)列中消息處理的順序，并且可以更改。
通常，在處理短命令或面向任務(wù)的處理時(shí)，我們會(huì)傾向于使用消息代理。
例如，假設(shè)你在一家電子商務(wù)公司工作，想要將新產(chǎn)品添加到公司的網(wǎng)站。這可能意味著多個(gè)服務(wù)需要知道并以異步方式處理此請(qǐng)求。
上圖顯示了RabbitMQ扇出消息分發(fā)的使用，其中每個(gè)服務(wù)都有自己的隊(duì)列連接到扇出交換機(jī)。
產(chǎn)品服務(wù)發(fā)送包含新產(chǎn)品信息的消息到交換機(jī)，交換機(jī)將消息發(fā)送到所有連接的隊(duì)列。
在從隊(duì)列成功消耗消息后，它將被刪除，因?yàn)樯婕暗姆?wù)不需要保留或重新處理消息。
在處理當(dāng)前或歷史事件時(shí)，通常涉及大量數(shù)據(jù)，需要以單個(gè)或批量方式處理這些數(shù)據(jù)，我們會(huì)傾向于使用事件代理。
例如，假設(shè)你在一個(gè)娛樂(lè)評(píng)級(jí)網(wǎng)站工作，你想為用戶添加一個(gè)新功能，用來(lái)顯示電影的編劇和導(dǎo)演。這些信息雖然歷史存儲(chǔ)，但不對(duì)負(fù)責(zé)提供這些數(shù)據(jù)的服務(wù)可用。
上圖顯示了使用Kafka作為事件代理，它能夠從數(shù)據(jù)倉(cāng)庫(kù)中提取數(shù)億部電影，以為每個(gè)服務(wù)存儲(chǔ)的電影信息附加所需的信息。
Kafka可以在相對(duì)短的時(shí)間內(nèi)接受大量的數(shù)據(jù)，而消費(fèi)者可以有一個(gè)獨(dú)立的消費(fèi)者組來(lái)單獨(dú)處理電影主題流。
正如我之前提到的，選擇合適的范式時(shí)有很多事情要考慮。
我想討論一些關(guān)鍵的差異，這些差異通?？赡艹删突蚱茐哪鷮?duì)技術(shù)的決策。
在這一部分，我將比較迄今為止最流行的兩種技術(shù)：Kafka（事件代理）和RabbitMQ（消息代理），它們分別代表了這兩個(gè)范式，我對(duì)它們都有實(shí)際經(jīng)驗(yàn)。
我強(qiáng)烈鼓勵(lì)您在技術(shù)選擇過(guò)程中考慮以下幾點(diǎn)。
Kafka消費(fèi)者的工作方式是通過(guò)輪詢一個(gè)主題中按順序分區(qū)劃分的消息的塊，每個(gè)消費(fèi)者負(fù)責(zé)從一個(gè)或多個(gè)分區(qū)中消費(fèi)消息，其中分區(qū)用作消費(fèi)者的并行機(jī)制（隱式線程模型）。
這意味著通常負(fù)責(zé)管理主題的生產(chǎn)者會(huì)隱式知道可以訂閱主題的消費(fèi)者實(shí)例的最大數(shù)量。
消費(fèi)者負(fù)責(zé)處理消息處理的成功和失敗情況。由于消息是從分區(qū)中批量輪詢的，所以消息處理順序在分區(qū)級(jí)別是有保證的。
RabbitMQ消費(fèi)者從隊(duì)列中接收消息的方式是通過(guò)代理將消息推送給它們。
每條消息都以一種獨(dú)立的方式進(jìn)行處理，消費(fèi)者可以采用顯式線程模型，而不需要生產(chǎn)者知道消費(fèi)者實(shí)例的數(shù)量。
成功的消息處理是消費(fèi)者的責(zé)任，而處理失敗主要由消息代理完成。
消息分發(fā)由代理進(jìn)行管理。
如延遲消息和消息優(yōu)先級(jí)等功能是開箱即用的，因?yàn)橄⑻幚眄樞蛟陉?duì)列中通常是不保證的。
Kafka處理消息處理錯(cuò)誤的方式是將處理錯(cuò)誤的責(zé)任委托給消費(fèi)者。
如果某條消息被處理了幾次但失?。ǘ舅幩帲?，消費(fèi)者應(yīng)用程序需要跟蹤處理嘗試的數(shù)量，然后生成一條消息到一個(gè)單獨(dú)的DLQ（死信隊(duì)列）主題，以便以后檢查/重新運(yùn)行。
就錯(cuò)誤處理而言，消費(fèi)者是承擔(dān)所有責(zé)任的一方。
這意味著如果您希望具有重試/DLQ功能，您需要提供重試機(jī)制，并在發(fā)送消息到DLQ主題時(shí)充當(dāng)生產(chǎn)者，這在某些極端情況下可能導(dǎo)致消息丟失。
RabbitMQ處理消息處理錯(cuò)誤的方式是跟蹤處理消息失敗。一旦一條消息被視為毒藥藥，它將被路由到一個(gè)DLQ交換機(jī)。
這允許重新排隊(duì)消息或?qū)⑵渎酚傻綄Ｓ肈LQ以進(jìn)行檢查。
通過(guò)這種方式，RabbitMQ提供了保證未成功處理的消息不會(huì)丟失。
Kafka處理消費(fèi)者確認(rèn)的方式是由消費(fèi)者提交從主題分區(qū)中輪詢的消息的偏移量。
開箱即用，Kafka客戶端會(huì)自動(dòng)提交偏移量，無(wú)論消息是否成功處理，這可能導(dǎo)致消息丟失，如下圖所示。
通過(guò)消費(fèi)者代碼負(fù)責(zé)手動(dòng)提交獲取的消息的偏移量，包括處理消息消費(fèi)失敗的情況，可以更改此行為。
RabbitMQ處理消費(fèi)者確認(rèn)的方式是消費(fèi)者以每條消息的方式進(jìn)行“確認(rèn)”或“否認(rèn)”，允許由消息代理處理重試策略/DLQ，如果需要，可以由消息代理進(jìn)行管理。
開箱即用，RabbitMQ客戶端自動(dòng)進(jìn)行確認(rèn)，無(wú)論消息是否成功處理，可以通過(guò)消費(fèi)者端的配置手動(dòng)控制確認(rèn)，允許消息在失敗/超時(shí)時(shí)重新推送給消費(fèi)者。
RabbitMQ和Kafka在大多數(shù)情況下都提供至少一次消息/事件處理的保證，這意味著消費(fèi)者應(yīng)該是冪等的，以處理同一消息/事件的多次處理。
對(duì)我們來(lái)說(shuō)，最重要的部分是編制我們解決方案的技術(shù)標(biāo)準(zhǔn)清單，并為我們作為團(tuán)隊(duì)和產(chǎn)品不能缺少的要求分配“不可接受”。
回到基礎(chǔ)精神，我使用了一個(gè)普通的表格來(lái)編制和比較不同的標(biāo)準(zhǔn)，并提到了一些需要注意的地方。記住，“細(xì)節(jié)藏在細(xì)節(jié)之中”。
這真的幫助我們組織并集中精力關(guān)注對(duì)我們至關(guān)重要的內(nèi)容以及我們無(wú)法缺少的內(nèi)容。
例如，我們的“不可接受”要求之一是，如果在處理過(guò)程中發(fā)生錯(cuò)誤，我們不能承受丟失消息。
正如您可能從上面的部分中記得的，當(dāng)使用需要DLQ的Kafka時(shí)，消費(fèi)者也是DLQ的生產(chǎn)者。這意味著在消費(fèi)者發(fā)生故障的某些情況下，消息將不會(huì)被發(fā)送到DLQ主題，可能導(dǎo)致消息丟失。
在這一點(diǎn)上，正如您可能已經(jīng)猜到的那樣，我們決定選擇消息代理。
我們的功能包括面向命令/任務(wù)的處理用例，消息代理滿足了我們的產(chǎn)品/數(shù)據(jù)容量要求，也滿足了我們團(tuán)隊(duì)的需求。
消息和事件流生態(tài)系統(tǒng)包括許多解決方案，每個(gè)解決方案都有許多不同的方面需要考慮和熟悉。
重要的是我們要睜大眼睛進(jìn)入每個(gè)生態(tài)系統(tǒng)，并對(duì)這些不同的范式有清晰的理解。它們將對(duì)我們工程師的日常生活（有時(shí)是夜間生活）產(chǎn)生重大影響。
本文鏈接：http://www.tebozhan.com/showinfo-26-20048-0.html消息代理與事件代理：何時(shí)使用它們
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： DeepFlow 是如何通過(guò) Wasm Plugin 實(shí)現(xiàn)業(yè)務(wù)可觀測(cè)性？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)