Как платежные системы решают вопросы сохранности данных при использовании очередей?

Question

[Crash]

Практически все платежные системы представляют собой высоконагруженные сервисы. Почти всегда атрибутом такого проекта являются очереди сообщений для асинхронной работы с данными. Очереди как правило работают с данными в оперативной памяти. Но сервер, на котором находится брокер сообщений, может неожиданно упасть. Сохранность данных в этом случае может обеспечить их выгрузка в файловую систему. Но с другой стороны, активная работа с файловой системой существенно снизит производительность.

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

Answer 1

[Иван Шумов]

Очереди как правило работают с данными в оперативной памяти

Вот тут и вся проблема наличия данного вопроса. Нет и еще раз нет. Практически никто не работает напрямую из памяти и вообще есть несколько подходов к реализации. Разумеется в HA используются подходы с сохранением на диск данных по аналогии с Kafka. А что до платежных систем так там все иначе работает, абсолютно. Ну, то есть очереди присутствуют все еще, но транзакционность достигается не за их счет

Comments

[Crash]

Спасибо за ответ! У платежных систем работает все иначе - не могли бы вы коротко рассказать, как у них там устроено? Очень интересно

[Иван Шумов]

Crash, короткий ответ займет 4-часовую лекцию про отказоустойчивые системы и распределенные транзакции, поэтому не могу) И не советую туда погружаться. Даже зная как я предпочитаю не работать в финтехе из-за огромного числа нюансов

[Crash]

Иван Шумов, думаю здесь главное быть юридически защищенным, чтобы не попасть на деньги) Насчет инструментов по работе с очередями - я правильно понял, что все инструменты используют файловую систему и никак иначе? Т.е. можно не париться с выбором, RabbitMQ использовать или Redis.

[Иван Шумов]

Crash,

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

это нас вообще не должно волновать как IT-специалистов. Это головная боль юристов.

все инструменты используют файловую систему и никак иначе

не обязательно, но чаще всего да. Главное где-то хранить данные. Только надо учитывать что 100% отказоустойчивость не существуют. Сообщения все-равно будут теряться и этого избежать невозможно

[Crash]

это нас вообще не должно волновать как IT-специалистов. Это головная боль юристов.

Я работал в обменном сервисе, который работал по серой схеме, в качестве разработчика бекенда) Ушел в том числе из-за того, что меня запросто могли сделать крайним при разборе полетов.

[Иван Шумов]

Crash, учитывая что самостоятельно подписался на неуплату налогов то получил бы по заслугам. Не надо так

[Crash]

Иван Шумов, так-то да)

[DevMan]

Иван Шумов, с чего вдруг? мож ещё и производителей оружия/вилок/ножей/etc судить за убийства?

[Иван Шумов]

DevMan, можно сказать что несколько верю в эффект бумеранга)

[DevMan]

Иван Шумов, эффекты тут не при чем.
ты в теме и имеешь с этого свой профит – это одно.
ты тупо делаешь тз – это совершенно другое.

Answer 2

[bugbuster]

Исходный вопрос вместил в себя слишком много разнородных тем и он немного сложнее, чем просто выбор между хранением данных в памяти и на диске. Все-таки, насколько я понимаю вопрос в архитектуре очередей в высоконагруженной системе?
Если да, то во-первых, в необходимо использовать очередь, состоящую из кластера узлов.
Во-вторых, надо определиться, что именно важнее для вашей системы: согласованность или доступность кластера.
Например, с RabbitMQ можно выбирать в какую сторону проводить оптимизацию.