时间戳

首页 > 解决方案 > 可扩展微服务架构中的 Rabbitmq、Redis 和 Hazlecast

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

问题描述

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

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

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

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

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

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

谢谢你的帮助。

标签： redisrabbitmqmicroservicesscalabilityhazelcast

解决方案

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

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

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

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

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

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

推荐阅读