Redmi Buds 4開箱簡評：才199還有降噪 可以無腦入
在上個月舉辦的Redmi Note11T Pro系列新機發布會上，除了兩款手機新品之外，Redmi還帶來了兩款TWS真無線藍牙耳機產品，Redmi Buds 4和Redmi Buds 4 Pro，此前我們在Redmi Note11T
適用于性能要求不高，所有的消息嚴格按照先進先出（FIFO）的原則來發布和消費的場景。
例如，在證券處理中，以人民幣兌換美元為Topic，在價格相同的情況下，先出價者優先處理，則可以按照FIFO的方式發布和消費全局順序消息。
要實現全局有序，必須控制Topic只有一個隊列queue，才能實現全局有序。
由于只有一個隊列存在，這種方式雖然保證了全局有序，但是性能不高，無法擴展。
適用于性能要求高，以Sharding Key作為分區字段，在同一個隊列queue中嚴格地按照FIFO原則進行消息發布和消費的場景。
例如，用戶注冊需要發送發驗證碼，以用戶ID作為Sharding Key，那么同一個用戶發送的消息都會按照發布的先后順序來消費。
保證「消息生產」的順序性，則必須滿足以下條件：
滿足以上條件的生產者，將 「順序消息」 發送至服務端后，會保證設置了同一分區鍵的消息，按照發送順序存儲在同一隊列中。
局部有序（分區有序）
注意，在RocketMQ 5.x版本中，新增了「消息組」概念，順序消息發送必須要設置消息組。
保證「消息消費」的順序性，則必須滿足以下條件：
對于需要嚴格保證消費順序的場景，請務必設置合理的重試次數，避免參數不合理導致消息亂序。
如果一個Broker掉線，那么此時隊列總數是否會發化？
如果發生變化，那么同一個 ShardingKey 的消息就會發送到不同的隊列上，造成亂序。
如果不發生變化，那消息將會發送到掉線Broker的隊列上，必然是失敗的。
因此 Apache RocketMQ 提供了兩種模式，如果要保證嚴格順序而不是可用性，創建 Topic 是要指定 -o 參數（--order）為true，表示順序消息:
$ sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -o true -n 127.0.0.1:9876create topic to 127.0.0.1:10911 success.TopicConfig [topicName=TopicTest, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=true, attributes=null]其次，要保證NameServer中的配置 orderMessageEnable 和 returnOrderTopicConfigToBroker 必須是 true。
如果上述任意一個條件不滿足，則是保證可用性而不是嚴格順序。
同一條消息是否可以既是順序消息，又是定時消息和事務消息？
不可以。順序消息、定時消息、事務消息是不同的消息類型，三者是互斥關系，不能疊加在一起使用。
為什么全局順序消息性能一般？
全局順序消息是嚴格按照FIFO的消息阻塞原則，即上一條消息沒有被成功消費，那么下一條消息會一直被存儲到Topic隊列中。
本文鏈接：http://www.tebozhan.com/showinfo-26-10904-0.html三分鐘白話RocketMQ系列—— 如何保證消息順序性
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號