什么样的线程模型变化导致了DMLC
What kind of threading model changes led to DMLC
文档解释了为什么在版本 2 中引入 DMLC:
https://docs.spring.io/spring-amqp/reference/html/#choose-container
This architecture was required because, in early versions of the RabbitMQ client, multiple concurrent deliveries were not possible. Newer versions of the client have a revised threading model and can now support concurrency. This has allowed the introduction of the DMLC where the listener is now invoked directly on the RabbitMQ Client thread. Its architecture is, therefore, actually “simpler” than the SMLC.
如文档中所述:修改后的线程模型,现在可以支持并发。
我可以这样简单理解吗:
之前版本的客户端不会并发调用handleDelivery
方法,所以我们需要使用队列:只需要将消息放入队列中等待其他线程消费即可,所以handleDelivery
方法会立即return,避免阻塞后续投递,但是新版本的rabbit客户端会并发调用handleDelivery
方法,所以不需要使用队列来支持并发。
有人可以更详细地解释什么样的线程模型变化导致了 DMLC 吗?
我不记得哪个版本的 amqp-client
改进了线程,但那是我加入该项目的时候(10 多年前)。
我们花了几年时间才开始重写容器(2016 年)。
我们保留了旧版 SMLC,它仍然有一些好处,例如消费者端批处理。
文档解释了为什么在版本 2 中引入 DMLC: https://docs.spring.io/spring-amqp/reference/html/#choose-container
This architecture was required because, in early versions of the RabbitMQ client, multiple concurrent deliveries were not possible. Newer versions of the client have a revised threading model and can now support concurrency. This has allowed the introduction of the DMLC where the listener is now invoked directly on the RabbitMQ Client thread. Its architecture is, therefore, actually “simpler” than the SMLC.
如文档中所述:修改后的线程模型,现在可以支持并发。
我可以这样简单理解吗:
之前版本的客户端不会并发调用handleDelivery
方法,所以我们需要使用队列:只需要将消息放入队列中等待其他线程消费即可,所以handleDelivery
方法会立即return,避免阻塞后续投递,但是新版本的rabbit客户端会并发调用handleDelivery
方法,所以不需要使用队列来支持并发。
有人可以更详细地解释什么样的线程模型变化导致了 DMLC 吗?
我不记得哪个版本的 amqp-client
改进了线程,但那是我加入该项目的时候(10 多年前)。
我们花了几年时间才开始重写容器(2016 年)。
我们保留了旧版 SMLC,它仍然有一些好处,例如消费者端批处理。