K60 Pro官方停產(chǎn) 第三方瞬間漲價
雖然沒有官方宣布，但Redmi的一些高管也已經(jīng)透露了，Redmi K60 Pro已經(jīng)停產(chǎn)且不會補貨，這一切都是為了即將到來的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機在停產(chǎn)之后
適用于性能要求不高，所有的消息嚴格按照先進先出（FIFO）的原則來發(fā)布和消費的場景。
例如，在證券處理中，以人民幣兌換美元為Topic，在價格相同的情況下，先出價者優(yōu)先處理，則可以按照FIFO的方式發(fā)布和消費全局順序消息。
要實現(xiàn)全局有序，必須控制Topic只有一個隊列queue，才能實現(xiàn)全局有序。
由于只有一個隊列存在，這種方式雖然保證了全局有序，但是性能不高，無法擴展。
適用于性能要求高，以Sharding Key作為分區(qū)字段，在同一個隊列queue中嚴格地按照FIFO原則進行消息發(fā)布和消費的場景。
例如，用戶注冊需要發(fā)送發(fā)驗證碼，以用戶ID作為Sharding Key，那么同一個用戶發(fā)送的消息都會按照發(fā)布的先后順序來消費。
保證「消息生產(chǎn)」的順序性，則必須滿足以下條件：
滿足以上條件的生產(chǎn)者，將 「順序消息」 發(fā)送至服務(wù)端后，會保證設(shè)置了同一分區(qū)鍵的消息，按照發(fā)送順序存儲在同一隊列中。
局部有序（分區(qū)有序）
注意，在RocketMQ 5.x版本中，新增了「消息組」概念，順序消息發(fā)送必須要設(shè)置消息組。
保證「消息消費」的順序性，則必須滿足以下條件：
對于需要嚴格保證消費順序的場景，請務(wù)必設(shè)置合理的重試次數(shù)，避免參數(shù)不合理導(dǎo)致消息亂序。
如果一個Broker掉線，那么此時隊列總數(shù)是否會發(fā)化？
如果發(fā)生變化，那么同一個 ShardingKey 的消息就會發(fā)送到不同的隊列上，造成亂序。
如果不發(fā)生變化，那消息將會發(fā)送到掉線Broker的隊列上，必然是失敗的。
因此 Apache RocketMQ 提供了兩種模式，如果要保證嚴格順序而不是可用性，創(chuàng)建 Topic 是要指定 -o 參數(shù)（--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。
如果上述任意一個條件不滿足，則是保證可用性而不是嚴格順序。
同一條消息是否可以既是順序消息，又是定時消息和事務(wù)消息？
不可以。順序消息、定時消息、事務(wù)消息是不同的消息類型，三者是互斥關(guān)系，不能疊加在一起使用。
為什么全局順序消息性能一般？
全局順序消息是嚴格按照FIFO的消息阻塞原則，即上一條消息沒有被成功消費，那么下一條消息會一直被存儲到Topic隊列中。
本文鏈接：http://www.www897cc.com/showinfo-26-10904-0.html三分鐘白話RocketMQ系列—— 如何保證消息順序性
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號