eardata / hutch-java Goto Github PK

类似以下 hutch 的使用:

Hutch::Config.error_handlers << Hutch::ErrorHandlers::MaxRetry.new
Hutch::Config.error_handlers << Hutch::ErrorHandlers::Honeybadger.new

使用 Hutch 的时候, 默认只向一个 rabbitmq 实例推送消息. 但有时候系统对接了多个不同 virtual host 或者连接多个不同的 rabbitmq 实例, 需要考虑如何支持进行不同 rabbitmq 实例进行消息的 publish

以此来支持 RabbitMQ mock(com.github.fridujo:rabbitmq-mock:1.1.1)

业务场景会遇到有 rate limit 的 api 调用, 当然可以直接交给外部的 rate limit 去处理. 但这样在与 mq 之间沟通的时候, 会浪费大量的计算资源在做重复的事情. 可以将任务分成两种进行考虑:

1. one shot 类型: 正常让 mq 进行主动推送到 client, 然后进行执行处理既可以. 这里的要求是拥有一定的任务堆积能力, 以及消息处理速度的快慢. 能够方便的根据情况进行 consumer 的增加减少, 能够堆叠 1000w 以内的消息量(再多, 就应该是任务消费的问题了)
2. delay 类型: 这类现在是简化的利用 mq 的 dlx 进行 retry 重试, 但因为是 push 模型, 所以无法进行主动的任务量获取的控制. 如果需要更加精确的 delay 或者 schedule 类型的任务, 则需要利用新的数据结构或者中间件来解决这个问题.

使用的时候, 无法第一时间从 console 中查看到到底是连接的哪一个 rabbitmq 实例, virtual host 是什么? Hutch.name 是什么