Логика бронирования мест для приложения «Метеорреакция»

Question

Я работаю над приложением по бронированию метеоров, где у меня ограниченное количество мест.Мое приложение может использоваться многими пользователями параллельно, поэтому есть вероятность, что два пользователя попытаются забронировать одно и то же место.Но согласно бизнес-логике места никогда не могут быть перебронированы.В Java я мог бы ограничить параллельное бронирование, используя синхронизированный блок.У меня нет большого опыта работы с метеоритом / реакцией, поэтому я не уверен, каким должен быть правильный путь для достижения этой цели.

Моя текущая мысль - использовать реактивное логическое значение для создания блокировки, поэтому, если приложение получает два резервированиязапрос, то он обрабатывает их синхронно и не выполняет второй запрос бронирования.Так как место уже будет выделено при первом запросе.Но я боюсь, попаду ли я в тупик.Поэтому я ищу ваше мнение / помощь для правильной реализации.

Спасибо за ваш совет!

Answer 1

Если вы используете pub / sub в Meteor, работа выполнена.Ваши заказы вступают в силу в порядке очереди.Пока ваша связь включена, когда вы пишете свое первое бронирование, место занято.

Например (логическая запись)

1 Публикуйте свои заказы в желаемой области.

2.Подписаться на клиента в той же области действия.

3.Если документ bookedOn $ (дата бронирования) делает «недоступным для бронирования» / unclickable, заставляет UX показывать необходимые цвета / опыт.

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

Это было бы немного «проблемой», если бы вы не использовали пабы / сабы, а обычные... ты на Метеоре, ты должен использовать нативную реактивность Метеора.Ваш логический тип - логический (забронирован) или просто забронирован.

Answer 2

Я думаю, что метеорный способ сделать это - вызвать метеорный метод, чтобы пользователь не занимал место.В этом методе проверьте, не занято ли это место.Более подробная информация здесь: https://forums.meteor.com/t/if-multiple-users-are-trying-to-access-one-method-of-meteor-methods-how-to-make-method-as-synchronous-to-use-one-user-only-at-a-time/24969/8

Но методы от разных клиентов запускаются одновременно на сервере.Вам придется использовать что-то вроде семафора.Самым простым способом было бы написать замок в Монго и проверить, не существует ли замок для этого места.Позже блокировка может быть уничтожена монго с помощью TTL https://docs.mongodb.com/manual/tutorial/expire-data/

Подробнее о методах можно прочитать здесь https://guide.meteor.com/methods.html

Чтобы обернуть его, псевдокод будет выглядеть примерно так:

accuireLock (userId, seatId);// будет читать блокировку, если она свободна, напишите ее, а затем прочитайте снова на всякий случай.В любом случае это должно выдать ошибку

takeSeat (userId, seatId);

Answer 3

Я предполагаю, что здесь ваш бэкэнд - это node.js, который рассматривается как использование вами метеора, вы уже используете NPM, поэтому бэкэнд, использующий Node, имеет смысл.

В этом случае, скажем, вы используете Expressили KOA для обработки ваших запросов, вы можете просто связать свои задачи с помощью обещаний, это заставит задачи выполняться линейно.

Ниже приведен простой рабочий пример, если вы запустите фрагмент, вы заметите, что я добавляюзадачи каждые 700 мс, но задачи могут быть выполнены только за 1000 мс, но, как вы видите, перекрытия нет, и задачи выполняются по порядку.

const delay = (ms) => new Promise((r) => setTimeout(r, ms));

let lastTask = Promise.resolve();

async function addTask(txt) {
  const ptask = lastTask;
  lastTask = (async () => {
    await ptask;
    console.log(`starting task ${txt}`);
    await delay(1000);
    console.log(`done task ${txt}`);
  })();
}

async function test() {
  for (let l = 0; l < 5; l += 1) {
    setTimeout(() => {
      console.log(`adding task ${l}`);
      addTask(l);
    }, l * 700);
  }
}

test();