最佳實(shí)踐

來源：官方文檔

1 生產(chǎn)者

1.1 發(fā)送消息注意事項(xiàng)

1 Tags的使用

一個(gè)應(yīng)用盡可能用一個(gè)Topic，而消息子類型則可以用tags來標(biāo)識(shí)俗或。tags可以由應(yīng)用自由設(shè)置市怎，只有生產(chǎn)者在發(fā)送消息設(shè)置了tags，消費(fèi)方在訂閱消息時(shí)才可以利用tags通過broker做消息過濾：message.setTags("TagA")辛慰。

2 Keys的使用

每個(gè)消息在業(yè)務(wù)層面的唯一標(biāo)識(shí)碼要設(shè)置到keys字段区匠，方便將來定位消息丟失問題。服務(wù)器會(huì)為每個(gè)消息創(chuàng)建索引（哈希索引）帅腌，應(yīng)用可以通過topic驰弄、key來查詢這條消息內(nèi)容麻汰，以及消息被誰(shuí)消費(fèi)。由于是哈希索引戚篙，請(qǐng)務(wù)必保證key盡可能唯一五鲫，這樣可以避免潛在的哈希沖突。

   // 訂單Id   
   String orderId = "20034568923546";   
   message.setKeys(orderId);   

3 日志的打印

?消息發(fā)送成功或者失敗要打印消息日志岔擂，務(wù)必要打印SendResult和key字段臣镣。send消息方法只要不拋異常，就代表發(fā)送成功智亮。發(fā)送成功會(huì)有多個(gè)狀態(tài)忆某，在sendResult里定義。以下對(duì)每個(gè)狀態(tài)進(jìn)行說明：

• SEND_OK

消息發(fā)送成功阔蛉。要注意的是消息發(fā)送成功也不意味著它是可靠的弃舒。要確保不會(huì)丟失任何消息，還應(yīng)啟用同步Master服務(wù)器或同步刷盤状原，即SYNC_MASTER或SYNC_FLUSH聋呢。

• FLUSH_DISK_TIMEOUT

消息發(fā)送成功但是服務(wù)器刷盤超時(shí)。此時(shí)消息已經(jīng)進(jìn)入服務(wù)器隊(duì)列（內(nèi)存）颠区，只有服務(wù)器宕機(jī)削锰，消息才會(huì)丟失。消息存儲(chǔ)配置參數(shù)中可以設(shè)置刷盤方式和同步刷盤時(shí)間長(zhǎng)度毕莱，如果Broker服務(wù)器設(shè)置了刷盤方式為同步刷盤器贩，即FlushDiskType=SYNC_FLUSH（默認(rèn)為異步刷盤方式），當(dāng)Broker服務(wù)器未在同步刷盤時(shí)間內(nèi)（默認(rèn)為5s）完成刷盤朋截，則將返回該狀態(tài)——刷盤超時(shí)蛹稍。

• FLUSH_SLAVE_TIMEOUT

消息發(fā)送成功，但是服務(wù)器同步到Slave時(shí)超時(shí)部服。此時(shí)消息已經(jīng)進(jìn)入服務(wù)器隊(duì)列唆姐，只有服務(wù)器宕機(jī)，消息才會(huì)丟失廓八。如果Broker服務(wù)器的角色是同步Master奉芦，即SYNC_MASTER（默認(rèn)是異步Master即ASYNC_MASTER），并且從Broker服務(wù)器未在同步刷盤時(shí)間（默認(rèn)為5秒）內(nèi)完成與主服務(wù)器的同步剧蹂，則將返回該狀態(tài)——數(shù)據(jù)同步到Slave服務(wù)器超時(shí)声功。

• SLAVE_NOT_AVAILABLE

消息發(fā)送成功，但是此時(shí)Slave不可用国夜。如果Broker服務(wù)器的角色是同步Master减噪，即SYNC_MASTER（默認(rèn)是異步Master服務(wù)器即ASYNC_MASTER），但沒有配置slave Broker服務(wù)器，則將返回該狀態(tài)——無Slave服務(wù)器可用筹裕。

1.2 消息發(fā)送失敗處理方式

Producer的send方法本身支持內(nèi)部重試醋闭，重試邏輯如下：

• 至多重試2次（同步發(fā)送為2次，異步發(fā)送為0次）朝卒。
• 如果發(fā)送失敗证逻，則輪轉(zhuǎn)到下一個(gè)Broker。這個(gè)方法的總耗時(shí)時(shí)間不超過sendMsgTimeout設(shè)置的值抗斤，默認(rèn)10s囚企。
• 如果本身向broker發(fā)送消息產(chǎn)生超時(shí)異常，就不會(huì)再重試瑞眼。

以上策略也是在一定程度上保證了消息可以發(fā)送成功龙宏。如果業(yè)務(wù)對(duì)消息可靠性要求比較高，建議應(yīng)用增加相應(yīng)的重試邏輯：比如調(diào)用send同步方法發(fā)送失敗時(shí)伤疙，則嘗試將消息存儲(chǔ)到db银酗，然后由后臺(tái)線程定時(shí)重試，確保消息一定到達(dá)Broker徒像。

上述db重試方式為什么沒有集成到MQ客戶端內(nèi)部做黍特，而是要求應(yīng)用自己去完成，主要基于以下幾點(diǎn)考慮：首先锯蛀，MQ的客戶端設(shè)計(jì)為無狀態(tài)模式灭衷，方便任意的水平擴(kuò)展，且對(duì)機(jī)器資源的消耗僅僅是cpu旁涤、內(nèi)存翔曲、網(wǎng)絡(luò)。其次拭抬，如果MQ客戶端內(nèi)部集成一個(gè)KV存儲(chǔ)模塊部默，那么數(shù)據(jù)只有同步落盤才能較可靠，而同步落盤本身性能開銷較大造虎，所以通常會(huì)采用異步落盤，又由于應(yīng)用關(guān)閉過程不受MQ運(yùn)維人員控制纷闺，可能經(jīng)常會(huì)發(fā)生 kill -9 這樣暴力方式關(guān)閉算凿，造成數(shù)據(jù)沒有及時(shí)落盤而丟失。第三犁功，Producer所在機(jī)器的可靠性較低氓轰，一般為虛擬機(jī)，不適合存儲(chǔ)重要數(shù)據(jù)浸卦。綜上署鸡，建議重試過程交由應(yīng)用來控制。

1.3選擇oneway形式發(fā)送

通常消息的發(fā)送是這樣一個(gè)過程：

• 客戶端發(fā)送請(qǐng)求到服務(wù)器
• 服務(wù)器處理請(qǐng)求
• 服務(wù)器向客戶端返回應(yīng)答

所以，一次消息發(fā)送的耗時(shí)時(shí)間是上述三個(gè)步驟的總和靴庆，而某些場(chǎng)景要求耗時(shí)非常短时捌，但是對(duì)可靠性要求并不高，例如日志收集類應(yīng)用炉抒，此類應(yīng)用可以采用oneway形式調(diào)用奢讨，oneway形式只發(fā)送請(qǐng)求不等待應(yīng)答，而發(fā)送請(qǐng)求在客戶端實(shí)現(xiàn)層面僅僅是一個(gè)操作系統(tǒng)系統(tǒng)調(diào)用的開銷焰薄，即將數(shù)據(jù)寫入客戶端的socket緩沖區(qū)拿诸，此過程耗時(shí)通常在微秒級(jí)。

2 消費(fèi)者

2.1 消費(fèi)過程冪等

RocketMQ無法避免消息重復(fù)（Exactly-Once）塞茅，所以如果業(yè)務(wù)對(duì)消費(fèi)重復(fù)非常敏感亩码，務(wù)必要在業(yè)務(wù)層面進(jìn)行去重處理∫笆荩可以借助關(guān)系數(shù)據(jù)庫(kù)進(jìn)行去重蟀伸。首先需要確定消息的唯一鍵，可以是msgId缅刽，也可以是消息內(nèi)容中的唯一標(biāo)識(shí)字段啊掏，例如訂單Id等。在消費(fèi)之前判斷唯一鍵是否在關(guān)系數(shù)據(jù)庫(kù)中存在衰猛。如果不存在則插入迟蜜，并消費(fèi)，否則跳過啡省。（實(shí)際過程要考慮原子性問題娜睛，判斷是否存在可以嘗試插入，如果報(bào)主鍵沖突卦睹，則插入失敗畦戒，直接跳過）

msgId一定是全局唯一標(biāo)識(shí)符，但是實(shí)際使用中结序，可能會(huì)存在相同的消息有兩個(gè)不同msgId的情況（消費(fèi)者主動(dòng)重發(fā)障斋、因客戶端重投機(jī)制導(dǎo)致的重復(fù)等），這種情況就需要使業(yè)務(wù)字段進(jìn)行重復(fù)消費(fèi)徐鹤。

2.2 消費(fèi)速度慢的處理方式

1 提高消費(fèi)并行度

絕大部分消息消費(fèi)行為都屬于 IO 密集型垃环，即可能是操作數(shù)據(jù)庫(kù)，或者調(diào)用 RPC返敬，這類消費(fèi)行為的消費(fèi)速度在于后端數(shù)據(jù)庫(kù)或者外系統(tǒng)的吞吐量遂庄，通過增加消費(fèi)并行度，可以提高總的消費(fèi)吞吐量劲赠，但是并行度增加到一定程度涛目，反而會(huì)下降秸谢。所以，應(yīng)用必須要設(shè)置合理的并行度霹肝。 如下有幾種修改消費(fèi)并行度的方法：

• 同一個(gè) ConsumerGroup 下估蹄，通過增加 Consumer 實(shí)例數(shù)量來提高并行度（需要注意的是超過訂閱隊(duì)列數(shù)的 Consumer 實(shí)例無效）“⒙酰可以通過加機(jī)器元媚，或者在已有機(jī)器啟動(dòng)多個(gè)進(jìn)程的方式。
• 提高單個(gè) Consumer 的消費(fèi)并行線程苗沧，通過修改參數(shù) consumeThreadMin刊棕、consumeThreadMax實(shí)現(xiàn)。

2 批量方式消費(fèi)

某些業(yè)務(wù)流程如果支持批量方式消費(fèi)待逞，則可以很大程度上提高消費(fèi)吞吐量甥角，例如訂單扣款類應(yīng)用，一次處理一個(gè)訂單耗時(shí) 1 s识樱，一次處理 10 個(gè)訂單可能也只耗時(shí) 2 s嗤无，這樣即可大幅度提高消費(fèi)的吞吐量，通過設(shè)置 consumer的 consumeMessageBatchMaxSize 返個(gè)參數(shù)怜庸，默認(rèn)是 1当犯，即一次只消費(fèi)一條消息，例如設(shè)置為 N割疾，那么每次消費(fèi)的消息數(shù)小于等于 N嚎卫。

3 跳過非重要消息

發(fā)生消息堆積時(shí)，如果消費(fèi)速度一直追不上發(fā)送速度宏榕，如果業(yè)務(wù)對(duì)數(shù)據(jù)要求不高的話拓诸，可以選擇丟棄不重要的消息。例如麻昼，當(dāng)某個(gè)隊(duì)列的消息數(shù)堆積到100000條以上奠支，則嘗試丟棄部分或全部消息，這樣就可以快速追上發(fā)送消息的速度抚芦。示例代碼如下：

    public ConsumeConcurrentlyStatus consumeMessage(
            List<MessageExt> msgs,
            ConsumeConcurrentlyContext context) {
        long offset = msgs.get(0).getQueueOffset();
        String maxOffset =
                msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);
        long diff = Long.parseLong(maxOffset) - offset;
        if (diff > 100000) {
            // TODO 消息堆積情況的特殊處理
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        }
        // TODO 正常消費(fèi)過程
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }    

4 優(yōu)化每條消息消費(fèi)過程

舉例如下倍谜，某條消息的消費(fèi)過程如下：

• 根據(jù)消息從 DB 查詢【數(shù)據(jù) 1】
• 根據(jù)消息從 DB 查詢【數(shù)據(jù) 2】
• 復(fù)雜的業(yè)務(wù)計(jì)算
• 向 DB 插入【數(shù)據(jù) 3】
• 向 DB 插入【數(shù)據(jù) 4】

這條消息的消費(fèi)過程中有4次與 DB的 交互，如果按照每次 5ms 計(jì)算燕垃，那么總共耗時(shí) 20ms枢劝，假設(shè)業(yè)務(wù)計(jì)算耗時(shí) 5ms，那么總過耗時(shí) 25ms卜壕，所以如果能把 4 次 DB 交互優(yōu)化為 2 次，那么總耗時(shí)就可以優(yōu)化到 15ms烙常，即總體性能提高了 40%轴捎。所以應(yīng)用如果對(duì)時(shí)延敏感的話鹤盒，可以把DB部署在SSD硬盤，相比于SCSI磁盤侦副，前者的RT會(huì)小很多侦锯。

2.3 消費(fèi)打印日志

如果消息量較少，建議在消費(fèi)入口方法打印消息秦驯，消費(fèi)耗時(shí)等尺碰，方便后續(xù)排查問題。

   public ConsumeConcurrentlyStatus consumeMessage(
            List<MessageExt> msgs,
            ConsumeConcurrentlyContext context) {
        log.info("RECEIVE_MSG_BEGIN: " + msgs.toString());
        // TODO 正常消費(fèi)過程
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }   

如果能打印每條消息消費(fèi)耗時(shí)译隘，那么在排查消費(fèi)慢等線上問題時(shí)亲桥，會(huì)更方便。

2.4 其他消費(fèi)建議

1 關(guān)于消費(fèi)者和訂閱

?第一件需要注意的事情是固耘，不同的消費(fèi)者組可以獨(dú)立的消費(fèi)一些 topic题篷，并且每個(gè)消費(fèi)者組都有自己的消費(fèi)偏移量，請(qǐng)確保同一組內(nèi)的每個(gè)消費(fèi)者訂閱信息保持一致厅目。

2 關(guān)于有序消息

消費(fèi)者將鎖定每個(gè)消息隊(duì)列番枚，以確保他們被逐個(gè)消費(fèi)，雖然這將會(huì)導(dǎo)致性能下降损敷，但是當(dāng)你關(guān)心消息順序的時(shí)候會(huì)很有用葫笼。我們不建議拋出異常，你可以返回 ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT 作為替代拗馒。

3 關(guān)于并發(fā)消費(fèi)

顧名思義路星，消費(fèi)者將并發(fā)消費(fèi)這些消息，建議你使用它來獲得良好性能瘟忱，我們不建議拋出異常奥额，你可以返回 ConsumeConcurrentlyStatus.RECONSUME_LATER 作為替代。

4 關(guān)于消費(fèi)狀態(tài)Consume Status

對(duì)于并發(fā)的消費(fèi)監(jiān)聽器访诱，你可以返回 RECONSUME_LATER 來通知消費(fèi)者現(xiàn)在不能消費(fèi)這條消息垫挨，并且希望可以稍后重新消費(fèi)它。然后触菜，你可以繼續(xù)消費(fèi)其他消息九榔。對(duì)于有序的消息監(jiān)聽器，因?yàn)槟汴P(guān)心它的順序涡相，所以不能跳過消息哲泊，但是你可以返回SUSPEND_CURRENT_QUEUE_A_MOMENT 告訴消費(fèi)者等待片刻。

5 關(guān)于Blocking

不建議阻塞監(jiān)聽器催蝗，因?yàn)樗鼤?huì)阻塞線程池切威，并最終可能會(huì)終止消費(fèi)進(jìn)程

6 關(guān)于線程數(shù)設(shè)置

消費(fèi)者使用 ThreadPoolExecutor 在內(nèi)部對(duì)消息進(jìn)行消費(fèi)，所以你可以通過設(shè)置 setConsumeThreadMin 或 setConsumeThreadMax 來改變它丙号。

7 關(guān)于消費(fèi)位點(diǎn)

當(dāng)建立一個(gè)新的消費(fèi)者組時(shí)先朦，需要決定是否需要消費(fèi)已經(jīng)存在于 Broker 中的歷史消息CONSUME_FROM_LAST_OFFSET 將會(huì)忽略歷史消息缰冤，并消費(fèi)之后生成的任何消息。CONSUME_FROM_FIRST_OFFSET 將會(huì)消費(fèi)每個(gè)存在于 Broker 中的信息喳魏。你也可以使用 CONSUME_FROM_TIMESTAMP 來消費(fèi)在指定時(shí)間戳后產(chǎn)生的消息棉浸。

3 Broker

3.1 Broker 角色

? Broker 角色分為 ASYNC_MASTER（異步主機(jī)）、SYNC_MASTER（同步主機(jī)）以及SLAVE（從機(jī)）刺彩。如果對(duì)消息的可靠性要求比較嚴(yán)格迷郑，可以采用 SYNC_MASTER加SLAVE的部署方式。如果對(duì)消息可靠性要求不高创倔，可以采用ASYNC_MASTER加SLAVE的部署方式嗡害。如果只是測(cè)試方便，則可以選擇僅ASYNC_MASTER或僅SYNC_MASTER的部署方式三幻。

3.2 FlushDiskType

? SYNC_FLUSH（同步刷新）相比于ASYNC_FLUSH（異步處理）會(huì)損失很多性能就漾，但是也更可靠，所以需要根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景做好權(quán)衡念搬。

3.3 Broker 配置

4 NameServer

?RocketMQ 中爷恳，Name Servers 被設(shè)計(jì)用來做簡(jiǎn)單的路由管理有缆。其職責(zé)包括：

• Brokers 定期向每個(gè)名稱服務(wù)器注冊(cè)路由數(shù)據(jù)。
• 名稱服務(wù)器為客戶端温亲，包括生產(chǎn)者棚壁，消費(fèi)者和命令行客戶端提供最新的路由信息。
  ?
  ?

5 客戶端配置

? 相對(duì)于RocketMQ的Broker集群栈虚，生產(chǎn)者和消費(fèi)者都是客戶端袖外。本小節(jié)主要描述生產(chǎn)者和消費(fèi)者公共的行為配置。

5.1 客戶端尋址方式

RocketMQ可以令客戶端找到Name Server, 然后通過Name Server再找到Broker魂务。如下所示有多種配置方式曼验，優(yōu)先級(jí)由高到低，高優(yōu)先級(jí)會(huì)覆蓋低優(yōu)先級(jí)粘姜。

• 代碼中指定Name Server地址鬓照，多個(gè)namesrv地址之間用分號(hào)分割

producer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");  

consumer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");

• Java啟動(dòng)參數(shù)中指定Name Server地址

-Drocketmq.namesrv.addr=192.168.0.1:9876;192.168.0.2:9876  

• 環(huán)境變量指定Name Server地址

export   NAMESRV_ADDR=192.168.0.1:9876;192.168.0.2:9876   

• HTTP靜態(tài)服務(wù)器尋址（默認(rèn)）

客戶端啟動(dòng)后，會(huì)定時(shí)訪問一個(gè)靜態(tài)HTTP服務(wù)器孤紧，地址如下：http://jmenv.tbsite.net:8080/rocketmq/nsaddr豺裆，這個(gè)URL的返回內(nèi)容如下：

192.168.0.1:9876;192.168.0.2:9876   

客戶端默認(rèn)每隔2分鐘訪問一次這個(gè)HTTP服務(wù)器，并更新本地的Name Server地址号显。URL已經(jīng)在代碼中硬編碼留储，可通過修改/etc/hosts文件來改變要訪問的服務(wù)器翼抠，例如在/etc/hosts增加如下配置：

10.232.22.67    jmenv.taobao.net   

推薦使用HTTP靜態(tài)服務(wù)器尋址方式咙轩，好處是客戶端部署簡(jiǎn)單获讳，且Name Server集群可以熱升級(jí)。

5.2 客戶端配置

DefaultMQProducer活喊、TransactionMQProducer丐膝、DefaultMQPushConsumer、DefaultMQPullConsumer都繼承于ClientConfig類钾菊，ClientConfig為客戶端的公共配置類帅矗。客戶端的配置都是get煞烫、set形式浑此，每個(gè)參數(shù)都可以用spring來配置，也可以在代碼中配置滞详，例如namesrvAddr這個(gè)參數(shù)可以這樣配置凛俱，producer.setNamesrvAddr("192.168.0.1:9876")，其他參數(shù)同理料饥。

1 客戶端的公共配置

2 Producer配置

3 PushConsumer配置

4 PullConsumer配置

5 Message數(shù)據(jù)結(jié)構(gòu)

6 系統(tǒng)配置

本小節(jié)主要介紹系統(tǒng)（JVM/OS）相關(guān)的配置。

6.1 JVM選項(xiàng)

? 推薦使用最新發(fā)布的JDK 1.8版本询枚。通過設(shè)置相同的Xms和Xmx值來防止JVM調(diào)整堆大小以獲得更好的性能违帆。簡(jiǎn)單的JVM配置如下所示：
?
?? ?-server -Xms8g -Xmx8g -Xmn4g ?
?
?
如果您不關(guān)心RocketMQ Broker的啟動(dòng)時(shí)間，還有一種更好的選擇金蜀，就是通過“預(yù)觸摸”Java堆以確保在JVM初始化期間每個(gè)頁(yè)面都將被分配刷后。那些不關(guān)心啟動(dòng)時(shí)間的人可以啟用它：
? -XX:+AlwaysPreTouch
禁用偏置鎖定可能會(huì)減少JVM暫停，
? -XX:-UseBiasedLocking
至于垃圾回收渊抄，建議使用帶JDK 1.8的G1收集器尝胆。

-XX:+UseG1GC -XX:G1HeapRegionSize=16m   
-XX:G1ReservePercent=25 
-XX:InitiatingHeapOccupancyPercent=30

? 這些GC選項(xiàng)看起來有點(diǎn)激進(jìn)，但事實(shí)證明它在我們的生產(chǎn)環(huán)境中具有良好的性能抒线。另外不要把-XX:MaxGCPauseMillis的值設(shè)置太小班巩，否則JVM將使用一個(gè)小的年輕代來實(shí)現(xiàn)這個(gè)目標(biāo)，這將導(dǎo)致非常頻繁的minor GC，所以建議使用rolling GC日志文件：

-XX:+UseGCLogFileRotation   
-XX:NumberOfGCLogFiles=5 
-XX:GCLogFileSize=30m

如果寫入GC文件會(huì)增加代理的延遲抱慌，可以考慮將GC日志文件重定向到內(nèi)存文件系統(tǒng)：

-Xloggc:/dev/shm/mq_gc_%p.log123   

6.2 Linux內(nèi)核參數(shù)

? os.sh腳本在bin文件夾中列出了許多內(nèi)核參數(shù)逊桦，可以進(jìn)行微小的更改然后用于生產(chǎn)用途。下面的參數(shù)需要注意抑进，更多細(xì)節(jié)請(qǐng)參考/proc/sys/vm/*的文檔

• vm.extra_free_kbytes强经，告訴VM在后臺(tái)回收（kswapd）啟動(dòng)的閾值與直接回收（通過分配進(jìn)程）的閾值之間保留額外的可用內(nèi)存。RocketMQ使用此參數(shù)來避免內(nèi)存分配中的長(zhǎng)延遲寺渗。（與具體內(nèi)核版本相關(guān)）
• vm.min_free_kbytes匿情，如果將其設(shè)置為低于1024KB，將會(huì)巧妙的將系統(tǒng)破壞信殊，并且系統(tǒng)在高負(fù)載下容易出現(xiàn)死鎖炬称。
• vm.max_map_count，限制一個(gè)進(jìn)程可能具有的最大內(nèi)存映射區(qū)域數(shù)涡拘。RocketMQ將使用mmap加載CommitLog和ConsumeQueue玲躯，因此建議將為此參數(shù)設(shè)置較大的值。（agressiveness --> aggressiveness）
• vm.swappiness鳄乏，定義內(nèi)核交換內(nèi)存頁(yè)面的積極程度跷车。較高的值會(huì)增加攻擊性，較低的值會(huì)減少交換量橱野。建議將值設(shè)置為10來避免交換延遲朽缴。
• File descriptor limits，RocketMQ需要為文件（CommitLog和ConsumeQueue）和網(wǎng)絡(luò)連接打開文件描述符水援。我們建議設(shè)置文件描述符的值為655350密强。
• Disk scheduler，RocketMQ建議使用I/O截止時(shí)間調(diào)度器裹唆，它試圖為請(qǐng)求提供有保證的延遲誓斥。