微服务的rabbitmq消息会话粘性

我在读关于单片应用程序会话粘性的文章。想了解微服务的可行性

问题1。特别是对于微服务来说，会话粘性的缺点是什么？互联网上没有太多关于这件事的讨论！由于同一实例可能过载（取决于应用程序的其他设计因素），这似乎严重影响了可伸缩性。有什么好处吗？请解释一下

如果rabbitMQ消息用于微服务间通信，是否可能具有路由到工作队列的rabbitMQ消息的会话粘性。i、 例如，消息中的头可能具有

session=xxx

，并且具有到达该队列的相同会话的所有消息都被路由到相同的客户端

RabbitMQ或AMQP似乎没有这样的配置

可能的客户端实现：

Publisher使用路由键

握手

和会话id有效负载发布握手消息

使用者创建

auto\u delete

队列和与主题

topic.sessionid的绑定

Publisher使用路由键发布邮件，

topic.sessionid

相应地清理

---

有人能指出这里的错误吗？

RabbitMQ团队监视并有时只回答有关StackOverflow的问题

---

你的方法似乎是合理的。主题交换和绑定到该主题的队列是我的建议。流程的第1步确实需要一个队列来将握手消息与所有用户同步，这可能会成为一个瓶颈，具体取决于您的消息速率

请记住，无法路由到任何地方的消息将丢失，因此我建议在此处阅读有关备用交换的信息-