GCP Pub/Sub Order Key属性未正常工作，消息接收顺序异常

碰到过类似的问题，结合你给出的代码和场景，咱一步步拆解可能的原因和排查方向：

一、先确认订阅的核心配置是否拉满 #

你提到已经开启了Order Key，但再仔细核对下这两个关键配置：

• 订阅的**交付顺序（Delivery ordering）**必须设为ENABLED，且层级是「按消息键（Per message key）」——要是选了其他层级，顺序保障就不会生效。
• 推送订阅的接收端点（你的FastAPI服务）必须能正确处理消息确认：如果端点返回非2xx状态码，Pub/Sub会把这条消息标记为未确认，后续会重试投递。这时候旧消息的重试投递就会和新消息“插队”，看起来像是乱序。

二、你的发布逻辑有没有隐藏的时序问题？ #

看你的代码，是同步调用future.result()等待发布完成，这部分本身没问题，但要注意：
你按顺序调用了两次fire_event_to_pubsub，但Pub/Sub的消息发布时间（publish_time）是按Pub/Sub服务器接收到消息的时间计算的，不是你本地调用的顺序。要是网络有波动，第二次调用的请求反而先到Pub/Sub服务器，那第二条消息的publish_time就会更早，Pub/Sub就会优先投递它——这就会出现你看到的“后发的消息先被接收”的情况。

三、FastAPI接收端的并发可能是“假乱序”的元凶 #

这是最容易踩的坑，也是高概率导致你这个问题的原因：

• 如果你用Uvicorn/Gunicorn启动FastAPI时开了多Worker或多线程，那两个消息可能被不同的线程/Worker处理。哪怕Pub/Sub是按顺序投递的，只要某个Worker处理消息的日志打印得晚，就会在日志里呈现乱序。
• 另外，要是第一个消息的Payload处理逻辑更耗时（比如要读取GCS上的文件），那它的日志会比第二个消息晚打出来，看起来像是乱序，但实际投递顺序是对的。

四、给你几个针对性的排查动作 #

1. 在接收端打全Pub/Sub的投递头：
   把FastAPI端点收到的X-Goog-Publish-Time（Pub/Sub的实际投递时间）和X-Goog-Order-Key打出来，这才是最准确的投递顺序依据，别只看本地日志的打印时间。
2. 临时关掉接收端的并发：
   用单线程单Worker启动FastAPI（比如uvicorn main:app --workers 1 --loop asyncio），如果这时候乱序消失了，那就是并发导致的日志视觉乱序，不是Pub/Sub的问题。
3. 检查订阅的重试和死信配置：
   去Pub/Sub控制台看订阅的重试规则，如果有消息因为端点报错被反复重试，就会出现旧消息插队的情况。建议配置死信队列（DLQ），把重试多次失败的消息转存，避免干扰正常消息的顺序。
4. 用Pub/Sub监控指标排查：
   重点看这两个指标：
   • subscription/ordered_messages_delayed_by_ordering：有没有因为顺序规则被延迟的消息
   • subscription/oldest_unacked_ordered_message_age：未确认的有序消息的最长等待时间
     这些能帮你确认是不是Pub/Sub本身的顺序保障出了问题。

结合你说的“1/4概率乱序”，大概率是接收端并发或者重试逻辑导致的，先从这两个方向入手排查，应该能很快定位到问题~

备注：内容来源于stack exchange，提问作者bioniclebeastmaster