分布式POS的RabbitMq架构 [英] RabbitMq Architecture for distributed POS

问题描述

我们正在开发一个杂货销售点系统来取代现有的旧系统.我们正在评估使用 RabbitMQ 将产品/价格变化发送到收银台.

We are developing a grocery Point of Sale system to replace an existing legacy system. We are evaluating using RabbitMQ for sending product/price changes down to the tills.

一家公司可能有 1-50 家商店，每家商店可能有 1-20 个收银台.商店中的每个收银台都会收到相同的数据.

A company may have anywhere from 1-50 stores, and each store may have 1-20 tills. Every till in the store will be receiving the same data.

每家公司将有一个中央后台.

There will be one central backoffice per company.

后台和每家商店都会有一个 Rabbit 经纪人.

There will be a Rabbit broker at the backoffice, and at each store.

在我当前的设计中，后台代理为每个商店设置了一个队列.后台服务器软件将更改推送到这些队列.

In my current design, the backoffice broker has a queue setup for each store. The backoffice server software pushes the changes to these queues.

商店经纪人有一个扇出交换.当 Till 连接到商店代理时，它会创建(如果尚不存在)一个持久队列.

The store broker has a fanout exchange. When a till connects to the store broker, it creates (if one does not yet exist) a durable queue.

我已经设置了从后台商店队列到商店交换的动态铲子.由于直到队列都是持久的并且消息是持久的，这应该是可靠的，不是吗?

I have setup dynamic shovels from the backoffice store queue to the store exchange. Since the till queues are all durable and the messages persistent, this should be reliable shouldn't it?

我希望我已经充分解释了我想要实现的目标.这看起来是一个不错的解决方案吗?或者有更好的方法吗?

I hope I have adequately explained what I am trying to achieve. Does this seem like a decent solution? Or is there a better way?

推荐答案

首先，这个问题相当模糊，因为有大量信息需要考虑.回答 - 我将尝试指出您应该考虑的一些问题:

First of all the question is pretty obscured since there are tons of information to consider. Answering it - i'll try to pin point some issues you should take into consideration:

1. 在连接到后台办公室的超大规模商店(数千家)中，您会遇到性能问题，试图为每个商店动态铲除 - 构建虚拟队列层次结构(区域队列，然后是商店，等等)可以是个好主意.
2. 请记住，这样的解决方案要求您在所有层上都安装兔子代理，包括直到硬件非常差并且业务功能非常需要资源.Rabbit broker 和 erlang 引擎将消耗其中的很大一部分来尝试接收/发送数据.考虑将收银台队列留在商店的代理上，并仅使用收银台上的应用程序客户端来获取运输数据.这也将减少许多收银机所需的软件维护.
3. 关于后台和商店之间的动态数据:首先，假设您将大量未处理的消息推送到商店，并且商店机器崩溃(例如硬盘问题) - 您会丢失数据，因为您已经在商店层面丢失了它们，但它们也是从后台挖出来的——所以现在你的商店和后台之间存在差异.其次，显然您的商店级机器将比后台的机器(或集群中的许多机器)弱得多 - 您的商店级可能一直忙于处理来自办公室的铲除消息.对于那些场景，您可以考虑不使用 shovel，而是再次使用商店级别的应用程序客户端来拉取或兔子的 QueuingBasicConsumer 被推到 - 这样你只有一个真相"的地方，即后台 - 消费者可以拉(或在上述消费者的情况下通过推送获取消息)，应用它们，然后才确认它们.这还可以帮助您控制商店接收数据的速度，因为它们处于控制之中.
4. 您应该考虑诸如 - 消息是否应该持久化，是否应该等待确认 (WaitForConfirmOrDie()).
5. 如果您在商店下的收银台不应该获得相同的数据(药房部分、电子部分)，会发生什么情况.这意味着您可能无法在商店中放置扇出交换.

要考虑的还有很多，我认为我们应该更具体.

There are much more to think about, i think we should get more concrete.

这篇关于分布式POS的RabbitMq架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！