java - MQ 与 REST 多线程性能对比

Question

目前我有一个消息引擎，每秒处理数千个请求，性能很差，因为当前的实现正在消耗 REST 服务，这是一个阻塞操作，因此它最终会耗尽线程池中的线程，因为消费 REST 服务在 HTTP 之上运行，我的理解是，我无法触发“即发即忘”请求，至少我需要等待 HTTP 响应，即使使用 Future 这也会在不同的线程中运行，所以即使主线程没有被阻塞，它最终也会导致线程池饥饿，所以我的问题是，如果我有这么高的并发数，那么将其发送到一个线程池不是更好吗？换成MQ？这样就不再是阻塞操作，对吗？该应用程序当前在 Akka 框架上运行。

Answer 1

所以初始数据如下:

• 您的程序每秒向 REST 服务发出数千个请求，
• POST 请求花费的时间超过 1 秒，
• 最终耗尽了线程池中的线程。

您应该检查的第一件事:REST 服务能够承受多少个并发请求？难道每秒无法处理上千个请求，单个请求的大时序是服务重载的结果吗？然后你必须设置一个机制来限制你的请求的速率。实际上，在任何情况下设置这样的限制都是一个好主意。

其次，您应该决定是否可以通过同步或异步 I/O 来实现这样的访问速率。同步I/O更简单、更快，但需要更多的线程内存消耗。粗略估计如下:

• 并发请求少于 100 个:使用同步
• 超过 10000 个并发请求:使用异步
• 介于两者之间:无论哪种方式

如果您决定使用同步 I/O，那么设置请求速率限制的最简单、最自然的方法是使用信号量:想要发出下一个请求的线程获取信号量对象，并在收到回复后释放它。保持线程池中的线程数等于请求限制。

如果您决定使用异步 I/O，则没有通用机制来设置此类限制，因为开发人员通常无法使用异步信号量。如果您的异步 I/O 库具有反应式接口(interface)，请使用它(异步信号量是背压机制的一部分)。如果没有，您可以使用以下组件创建这样的机制:

• 异步请求的阻塞队列
• 限制信号量
• 一个线程，它在循环中执行以下操作:获取信号量，从队列中获取下一个请求，然后发出它。当请求完成时(无论成功与否)，信号量都会被请求的回调释放。

这种机制对所有异步请求使用单线程，因此消耗的内存不多，并且工作速度足够快。但是，如果您需要它更快地工作，只需增加线程数即可。