上篇博客中，我們用實(shí)際的業(yè)務(wù)場景和代碼示例了Azure Messaging-ServiceBus Messaging對復(fù)雜對象消息的支持和消息的持久化：
Azure Messaging-ServiceBus Messaging消息隊(duì)列技術(shù)系列4-復(fù)雜對象消息是否需要支持序列化和消息持久化
本文中我們主要研究并介紹Azure Messaging對重復(fù)消息的支持。
MessageReceiver 對象創(chuàng)建時可以指定消息接收模式： ReceiveAndDelete 和 PeekLock （默認(rèn)），其中：
1. 使用 ReceiveAndDelete 模式時，接收是單步操作，即當(dāng) Service Bus 收到請求時，它將消息標(biāo)記為“正在使用”，然后將其返回給應(yīng)用程序。ReceiveAndDelete 模式是最簡
單的模型，并且最適合在出現(xiàn)故障時應(yīng)用程序能夠容許不處理消息的場景。理解此模式時，可考慮這種情況：使用者發(fā)出了接收請求，但在處理消息之前發(fā)生崩潰。由于 Service B
us已將消息標(biāo)記為“正在使用”，因此當(dāng)應(yīng)用程序重新啟動并重新開始使用消息時，它就會錯過在崩潰前已使用的消息。
2. 在 PeekLock 模式下，接收變成兩階段操作，因此可以支持不能容許錯過消息的應(yīng)用程序。當(dāng) Service Bus 收到請求時，它會找到下一條要使用的消息，將其鎖定以防止其他使
用者接收它，然后將其返回給應(yīng)用程序。應(yīng)用程序完成消息處理（或?qū)⑾⒖煽康卮鎯σ员銓硖幚恚┖螅瑫κ盏降南⒄{(diào)用 Complete 以完成接收過程的第二階段。當(dāng)Service
Bus 看到 Complete 時，會將該消息標(biāo)記為“正在使用”。另外兩個結(jié)果也是可能的。第一個結(jié)果，如果由于某種原因應(yīng)用程序無法處理該消息，它可以對收到的消息Abandon（而
不是 Complete）。這將導(dǎo)致 Service Bus 解鎖該消息，并使該消息可以重新被同一使用者或其他競爭的使用者接收。第二個結(jié)果，即存在與鎖定關(guān)聯(lián)的超時，如果應(yīng)用程序在鎖
定超時到期前無法處理改消息（例如，應(yīng)用程序崩潰）則 Service
