构建与Shopify店铺高效同步商品价格的方案

1. 按店铺维度隔离请求流 #

不管用RabbitMQ还是Kafka，核心是把不同店铺的请求彻底拆分，避免混在一起无法精准控速：

• RabbitMQ方案：给每个绑定的Shopify店铺创建专属队列，用主题交换机（Topic Exchange），将消息按shop.{shop_id}的路由键发送到对应店铺的队列。用户绑定新店铺时自动创建队列，解绑时销毁。每个队列单独分配消费者，只处理该店铺的请求。
• Kafka方案：以店铺ID作为消息的Key，Kafka会自动将同一Key的消息路由到同一个分区。每个分区分配一个消费者组实例，该实例只处理对应店铺的请求，天然实现单店铺请求的串行化和速率控制。

2. 单店铺的精准速率控制 #

每个店铺的消费者单独维护速率控制逻辑，适配Shopify的API限制：

• 令牌桶算法：给每个店铺初始化一个令牌桶，令牌生成速率严格匹配Shopify的速率限制（比如Admin API默认是2个请求/秒）。每次处理请求前先获取令牌，没有令牌则等待，直到有可用令牌再执行API调用。
• 结合响应头动态调整：每次调用Shopify API后，解析响应头的X-Shopify-Shop-Api-Call-Limit（格式如10/40），实时计算剩余配额。如果剩余配额不足，自动延长下一次请求的延迟时间；如果配额充足，可适当加快处理速度。
• 延迟队列兜底：如果同一店铺的请求密集到达，可将后续请求放入带TTL的延迟队列，等到符合速率限制的时间点再转到处理队列。比如RabbitMQ中给消息设置TTL，配合死信队列实现延迟触发。

3. 批量请求合并优化 #

减少API调用次数是规避速率限制的关键手段：

• 监听同一店铺的队列，在固定时间窗口（比如1秒）内收集多个价格更新请求，合并成一个批量API调用。比如用Shopify的bulkOperationsRunMutation批量更新商品价格，或者批量修改变体的价格字段。
• 注意合并请求的大小，不要超过Shopify API的单请求数据限制，避免因请求过大被拒绝。

4. 429错误的重试处理 #

即使做了前置控制，仍可能触发速率限制，需正确处理：

• 捕获429响应后，读取响应头的Retry-After字段，获取需要等待的秒数，将请求重新放回该店铺的队列，并设置对应延迟时间后再重试。
• 限制重试次数，避免无效循环占用资源；如果多次重试失败，标记该请求为异常，通知人工排查。

5. 弹性调度与监控 #

• 针对请求量高的店铺，可给其队列分配多个消费者，但多个消费者必须共享同一个速率控制器（比如分布式令牌桶），避免总请求量超限制。
• 监控每个店铺的请求处理速率、剩余API配额、429错误次数，一旦某个店铺的错误率上升，自动调整该店铺的处理延迟时间。

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