ServiceBus如何保证FIFO顺序？Azure Function崩溃后消息处理问询

让我逐个拆解你的问题，结合Service Bus和Azure Function的默认行为来详细说明：

1. Azure Function崩溃时，未处理消息会放回队列头部吗？ #

不会。Azure Function的Service Bus触发器默认采用PeekLock模式：当函数获取到消息时，会先持有一个锁（默认时长60秒），如果函数崩溃且没有调用消息的Complete方法，这个锁会超时失效。此时，这条未处理的消息会被重新放回队列，但不是回到队列头部，而是被追加到队列的尾部，同时消息的DeliveryCount（交付次数）会自动加1。

2. 这条失败消息会不会晚于后续消息被处理？ #

完全有可能。因为失败消息被放到了队列尾部，后续正常入队的消息会优先被其他Function实例获取并处理。只有当队列中排在它前面的消息都处理完毕后，这条失败的消息才会被再次尝试交付。

不过这里有个特殊场景：如果你的Service Bus队列启用了会话（Session），那么同一会话内的消息会严格保持FIFO顺序——即使某条消息重试，它也会在同会话的后续消息之前被处理，但这个规则仅适用于启用会话的队列。

3. 当Azure Function停止运行时，Service Bus如何保证FIFO顺序？ #

当所有Azure Function实例都停止运行时，Service Bus队列会严格按照消息的**原始入队时间（EnqueueTime）**来存储所有消息，不会改变它们的顺序。一旦Function实例恢复运行，触发器会从队列中最早入队的消息开始，按FIFO顺序依次拉取处理。

Service Bus队列的核心特性之一就是保证FIFO（除非你启用了消息优先级或会话，后者是保证同会话内的FIFO），所以即使Function停止期间有大量消息涌入，恢复后依然会从最早的消息开始处理，不会出现乱序的情况。

内容的提问来源于stack exchange，提问作者Kzryzstof