上篇博客中，我們用實際的業(yè)務場景和代碼示例了Azure Messaging-ServiceBus Messaging對復雜對象消息的支持和消息的持久化：

Azure Messaging-ServiceBus Messaging消息隊列技術系列4-復雜對象消息是否需要支持序列化和消息持久化

本文中我們主要研究并介紹Azure Messaging對重復消息的支持。

MessageReceiver 對象創(chuàng)建時可以指定消息接收模式： ReceiveAndDelete 和 PeekLock （默認），其中：

1. 使用 ReceiveAndDelete 模式時，接收是單步操作，即當 Service Bus 收到請求時，它將消息標記為“正在使用”，然后將其返回給應用程序。ReceiveAndDelete 模式是最簡

單的模型，并且最適合在出現故障時應用程序能夠容許不處理消息的場景。理解此模式時，可考慮這種情況：使用者發(fā)出了接收請求，但在處理消息之前發(fā)生崩潰。由于 Service B

us已將消息標記為“正在使用”，因此當應用程序重新啟動并重新開始使用消息時，它就會錯過在崩潰前已使用的消息。

2. 在 PeekLock 模式下，接收變成兩階段操作，因此可以支持不能容許錯過消息的應用程序。當 Service Bus 收到請求時，它會找到下一條要使用的消息，將其鎖定以防止其他使

用者接收它，然后將其返回給應用程序。應用程序完成消息處理（或將消息可靠地存儲以便將來處理）后，會對收到的消息調用 Complete 以完成接收過程的第二階段。當Service

Bus 看到 Complete 時，會將該消息標記為“正在使用”。另外兩個結果也是可能的。第一個結果，如果由于某種原因應用程序無法處理該消息，它可以對收到的消息Abandon（而

不是 Complete）。這將導致 Service Bus 解鎖該消息，并使該消息可以重新被同一使用者或其他競爭的使用者接收。第二個結果，即存在與鎖定關聯的超時，如果應用程序在鎖

定超時到期前無法處理改消息（例如，應用程序崩潰）則 Service