GCP Pub/Sub发布时是否支持复合键作为idempotency key防重复入队

结论先说在前面：GCP Pub/Sub服务端原生的发布幂等校验逻辑，不支持自动识别复合结构的键作为幂等校验依据，没法直接传多字段组合的复合键让服务端自动拆分、校验、去重。

具体规则和可行方案如下：

• 服务端原生幂等校验只认单字符串格式的幂等标识：不管是普通发布场景通过请求头传publish_request_id做幂等，还是有序消息场景下绑定排序键的幂等判断，服务端都只会对传入的单值字符串做等值匹配，不会主动解析键内部的组合结构，也不会自动提取消息里的多个字段拼成复合键做去重。
• 有复合键幂等需求的话，可以在客户端提前做一层转换：把组成复合键的多个业务字段，按固定顺序、固定规则处理（比如用不会出现在字段值里的特殊分隔符拼接、对组合后的内容做确定性哈希生成固定长度字符串），转成全局唯一的单值字符串，再把这个字符串作为幂等键传给Pub/Sub服务端就行。在幂等键默认10分钟的有效期内，传了相同字符串的重复发布请求会被服务端直接拦截，不会重复把消息写入主题队列，接口会直接返回第一次请求成功时生成的消息ID。
• 用这种自定义转换的复合键做幂等，有几个坑要注意：
  • 复合键的转换规则必须完全固定，一旦字段顺序、分隔符、哈希算法变了，同一个业务语义的请求会生成不同的幂等字符串，服务端会当成全新请求处理，直接导致重复消息入队。
  • 服务端的幂等去重有明确时间窗口，超过有效期之后再传相同的幂等键，服务端不会再做去重，会按新的发布请求执行入队。
  • 如果开了消息有序性（配置enableMessageOrdering=true），幂等校验是和排序键绑定生效的，转换后的复合幂等键要和对应排序键一一对应，不然可能出现消息排序乱序、去重失效的问题。

别想着靠服务端自动生成的消息ID做业务幂等，这个ID是消息成功入队之后服务端才生成的，重复请求要是在入队前没被幂等逻辑拦住，会生成不同的消息ID，根本起不到去重作用。

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