可伸缩微服务体系结构中的Rabbitmq、Redis和Hazlecast

Question

关于微服务体系结构中的可伸缩性，我有一个问题：

独立于服务间通信风格(REST HTTP或基于消息的)，如果服务扩展，这意味着要启动服务的多个副本，那么是如何实现共享主存的？更准确地说，instance1如何访问instance2?的内存。

我之所以问这个问题，是因为服务的所有实例之间共享的非内存数据库可以减缓读写进程。

一些设计可伸缩系统架构的专家能否解释，在使用(开放源代码) Redis解决方案和使用(开放源代码) Hazlecast解决方案解决这个问题时，到底有什么区别？

作为另一种可能的解决方案:使用Rabbitmq设计可伸缩系统。

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

谢谢你的帮助。

Answer 1

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

无状态工作负载通过添加更多的副本来扩展。重要的是，这些副本实际上是无状态的，并且没有松散耦合的共享。所有副本仍然可以与内存服务或数据库通信，但有状态服务是它自己的独立服务(在微服务体系结构中)。

对于这个问题，使用(开放源码) Redis解决方案还是使用(开放源代码) Hazelcast解决方案到底有什么区别？

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

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

是的，那很好。或者，您可以使用分布式发布子消息平台(如阿帕奇卡夫卡或阿帕奇脉冲星 )。