SQS消息转发方案：如何按验证请求类型路由至对应服务？

这其实是个相当常见的消息路由场景，两种方案都能搞定，但各有各的适用场景，我给你掰扯清楚：

这种就是最直白的思路，生产者根据验证请求的类型，直接把消息发送到对应服务的专属队列里，每个消费者只盯着自己的队列就行。

优点 #

• 逻辑简单到爆：生产者不用搞复杂的路由判断，发消息的时候直接按类型选队列；消费者也不用管其他类型的消息，专注处理自己队列里的内容，出错概率极低，后期排查问题也方便
• 隔离性拉满：各个服务的消息流完全独立，哪怕某个服务挂了或者消费速度慢，也不会牵连其他服务。比如支付验证的服务出问题了，身份验证的消息照样能正常处理
• 权限管控省心：可以给不同的消费者只开放对应队列的访问权限，避免越权访问，安全性更高

缺点 #

• 管理成本会随服务数量上涨：要是以后新增个10种8种验证类型，你就得新建10个8个队列，还要同步更新生产者的路由配置、权限策略啥的，时间长了容易乱
• 有点资源冗余：虽然SQS是托管服务不用你管服务器，但每个队列都有自己的配置项，多了之后维护起来还是有点麻烦

这种方案是把所有验证消息都塞到同一个队列里，生产者发消息的时候给消息加个自定义属性（比如叫ValidationType，值设成payment、identity这类），然后利用SQS的消息过滤功能，让每个消费者只接收自己关心类型的消息。

优点 #

• 维护起来贼轻松：只需要管一个队列，新增服务类型的时候，只要在生产者那边加个属性值，再给新消费者配好过滤规则就行，不用折腾新队列
• 灵活性超强：要是以后想加个监控或者日志服务，直接搞个不设过滤规则的消费者，就能拿到所有消息，完全不用改动现有架构
• 资源利用率更高：单个队列集中管理所有消息，不用分散维护多个队列的配置

缺点 #

• 初期要花点功夫搞过滤规则：虽然SQS是在服务端帮你过滤消息，但消费者的过滤策略得配对，要是规则写错了，要么收不到消息要么收错消息，得仔细测试
• 要留意消息堆积风险：如果某个类型的消息突然爆量，或者对应的消费者挂了，这些消息会堆在主队列里，虽然SQS的可见性超时能缓解，但还是得做好监控，别让一堆无效消息占着队列

• 如果你的验证服务类型不多（比如5个以内），或者各个服务的消息量差异极大、必须严格隔离，选多队列方案，省心省力，不容易踩坑
• 如果服务类型可能会频繁新增，或者需要灵活调整路由规则，选单队列+消息过滤方案，长期来看管理成本更低

另外提个关键注意点：不管选哪种方案，一定要做好消息幂等性处理！SQS偶尔会出现重复投递的情况，每个消费者处理消息的时候，得确保重复处理不会搞出问题（比如用唯一ID去重）。

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