1

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

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

每家公司将有一个中央后台办公室。

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

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

商店经纪人有一个扇出交换。当一个 till 连接到存储代理时，它会创建（如果尚不存在）一个持久队列。

我已经设置了从后台存储队列到存储交换的动态铲子。由于直到队列都是持久的并且消息是持久的，所以这应该是可靠的，不是吗？

我希望我已经充分解释了我想要实现的目标。这似乎是一个不错的解决方案？或者，还有更好的方法？

4

1 回答 1

1

首先，这个问题非常模糊，因为需要考虑大量信息。回答它 - 我将尝试指出您应该考虑的一些问题：

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

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

于 2014-06-03T09:41:20.930 回答