RabbitMq Архитектура для распределенных POS

Question

Мы разрабатываем продуктовую систему Point of Sale, чтобы заменить существующую устаревшую систему. Мы оцениваем использование RabbitMQ для отправки изменений продукта / цены вниз на счет.

Компания может иметь от 1 до 50 магазинов, и каждый магазин может иметь от 1 до 20 магазинов. Каждый кассир в магазине будет получать одни и те же данные.

В каждой компании будет один центральный офис.

Там будет Кролик-брокер в офисе и в каждом магазине.

В моем текущем проекте у брокера backoffice есть настройка очереди для каждого магазина. Программное обеспечение сервера backoffice вносит изменения в эти очереди.

У брокера магазина есть разветвленная биржа. Когда касса соединяется с брокером магазина, он создает (если он еще не существует) долговременную очередь.

Я настроил динамические экскаваторы из очереди в магазине backoffice на биржу магазина. Поскольку очереди кассовых сборов являются надежными, а сообщения - постоянными, это должно быть надежно, не так ли?

Надеюсь, я адекватно объяснил, чего я пытаюсь достичь. Это похоже на приличное решение? Или есть лучший способ?

Answer 1

Прежде всего, этот вопрос довольно запутан, так как есть масса информации для рассмотрения. Отвечая на это - я постараюсь определить некоторые вопросы, которые вы должны принять во внимание:

1. В очень большом масштабе магазинов (тысячи), подключенных к бэк-офису, вы столкнетесь с проблемами производительности, пытаясь динамически распределить данные по каждому магазину - построение иерархии виртуальных очередей (очереди для регионов, а затем магазинов и т. Д.) Может быть хорошим идея.
2. Помните, что для такого решения требуется, чтобы на всех уровнях, в том числе и на разных уровнях, был установлен кролик-брокер - обычно до тех пор, пока аппаратное обеспечение не будет очень плохим, а функциональность бизнеса будет очень требовательной. Кролик-брокер и движок erlang потребляют большую часть его, пытаясь получить / отправить данные. Подумайте о том, чтобы оставить очереди на оплату в брокере магазина и использовать только клиент приложения на счетах для получения транспортных данных. Это также сократит обслуживание программного обеспечения, необходимое для многих операций.
3. Что касается динамической лопатки между бэк-офисом и магазинами: во-первых, представьте, что у вас есть количество необработанных сообщений, перемещенных в хранилище, и машина магазина выходит из строя (например, проблемы с жестким диском) - вы потеряете данные, так как потеряли их на уровне магазина, но они также были перенесены из бэк-офиса - так что теперь у вас есть расхождение между вашим магазином и бэк-офисом. Во-вторых, очевидно, что ваш компьютер уровня магазина будет намного слабее, чем компьютер в бэк-офисе (или несколько компьютеров в кластере) - ваш уровень магазина может быть постоянно занят обработкой отправленных сообщений из офиса. Для этих сценариев вы можете рассмотреть возможность не использовать лопату, а снова использовать клиент приложения на уровне магазина, чтобы вытащить или QueuingBasicConsumer кролика, чтобы подтолкнуть - таким образом, у вас есть только одно место "правды", которое является бэк-офисом - потребитель может потянуть (получать сообщения, нажав в случае вышеупомянутого потребителя), применять их, и только затем подтверждать их. Это также поможет вам контролировать скорость получения данных в ваших магазинах, поскольку они контролируют ситуацию.
4. Вы должны думать о таких вещах, как - должны ли сообщения сохраняться или нет, ждать подтверждения (WaitForConfirmOrDie()) или нет.
5. Что произойдет, если ваши счета в магазинах не должны получать те же данные - разделы аптек, электронные разделы. Это означает, что вы, вероятно, не можете поставить обмен фанатов в магазине.

Есть еще много вопросов для размышления, я думаю, что мы должны стать более конкретными.