我对微服务架构中的可伸缩性有疑问：
独立于服务间通信风格（ REST HTTP 或 基于消息），如果一项服务可以扩展，则意味着 服务即将启动，共享主内存如何 更准确地说， instance1如何访问对象的内存 instance2？
我问这个问题是因为在服务的所有实例之间共享一个非内存数据库可能会减慢读写过程。
一些设计可伸缩系统架构的专家可以解释一下， 使用（开源） Redis 有什么区别 解决方案或对此使用（开源） Hazlecast 解决方案 有问题吗？
作为另一个可能的解决方案：使用 Rabbitmq 设计可扩展系统：
是否可以将消息队列用作共享内存解决方案，方法是 将消息中的大/中型对象发送到工作人员队列？
感谢您的帮助。
答案 0 :(得分：1)
该服务的几个实例将被启动，共享的主存储器如何实现？更确切地说，instance1如何访问instance2的内存？
你不知道。 无状态工作负载通过添加更多副本来扩展。重要的是，这些副本实际上是无状态和松散耦合的-不共享任何内容。所有副本仍可以与内存中的服务或数据库进行通信，但是有状态服务是它自己的独立服务（在微服务体系结构中）。
针对此问题，使用（开源）Redis解决方案或使用（开源）Hazlecast解决方案到底有什么区别？
两者都是有效的解决方案。哪种最适合您取决于哪种图书馆，协议或集成模式最适合您。
通过将消息中的大/中型对象发送到工作人员队列，将消息队列用作共享内存解决方案是否可行？
是的，那很好。或者，您可以使用分布式发布订阅消息平台，例如Apache Kafka或Apache Pulsar