Как сохранить переменную counter в нескольких экземплярах сервера?

Question

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

В настоящее время наш контроллер узла настроен на Amazon Elastic Beanstalk и включил балансировку нагрузки для обработкилюбые скачки в запросах.Наш вопрос: как нам сохранить наши spotNumber в нескольких экземплярах нашего контроллера узла?Теперь мы построили его как локальную переменную, которая начинается с 1 и увеличивается с каждым запросом, но будет ли это сохраняться, если AWS раскрутит новый экземпляр нашего контроллера узла для обработки увеличенного трафика?Если нет, то что было бы лучшим способом сохранить наш spotNumber во всех потенциальных экземплярах нашего сервера?

Заранее спасибо!

Answer 1

Использовать базу данных.

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

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

Вы также можете использовать Redis на Elasticache , но я думаю, что это излишне для одного счетчика.

Answer 2

Сохранение точных счетчиков в разных масштабах может потребовать разных реализаций. В небольшом масштабе достаточно простой переменной сеанса и логики блокировки в приложении. Однако в более широком масштабе синхронизация и блокировка сеансов лучше управляются с помощью базы данных. В частности, для вашего случая полезны условные записи DynamoDB или счетчики Redis . Однако сохраняйте ваши требования простыми и понятными, для управления счетчиками в масштабе могут потребоваться алгоритмы и структуры данных со смешными именами, например HyperLogLog .