可扩展微服务架构中的 Rabbitmq、Redis 和 Hazlecast

Question

我有一个关于微服务架构内可扩展性的问题：

独立于服务间通信方式（REST HTTP 或 基于消息），如果服务可扩展，这意味着服务的多个副本 服务即将启动，共享主内存如何 实现了吗？ 更准确地说，instance1 怎么访问 实例2？

我问这个问题是因为服务的所有实例之间共享的非内存数据库可能会降低读写过程的速度。

设计可扩展系统架构的专家能否解释一下， 究竟有什么区别在使用（开源）Redis 解决方案或使用（开源）Hazlecast 解决方案 有问题吗？

作为另一种可能的解决方案：使用 Rabbitmq 设计可扩展系统：

将消息队列用作共享内存解决方案是否可行，通过 将消息中的大/中型对象发送到工作队列？

感谢您的帮助。

Answer 1

要启动多个服务实例，如何实现共享主存？更准确地说，instance1如何访问instance2的内存？

你没有。 无状态工作负载通过添加更多副本来扩展。重要的是，这些副本实际上是无状态且松散耦合 - 不共享任何内容。所有副本仍然可以与内存中的服务或数据库通信，但该有状态服务是它自己的独立服务（在微服务架构中）。

使用（开源）Redis 解决方案和使用（开源）Hazelcast 解决方案解决这个问题到底有什么区别？

两者都是有效的解决方案。哪个最适合您取决于哪种库、协议或集成模式最适合您。

通过将消息中的大/中大小对象发送到工作队列，将消息队列用作共享内存解决方案是否可行？

是的，这很好。或者，您可以使用分布式发布-订阅消息传递平台，例如 Apache Kafka 或 Apache Pulsar