Последовательная и многопоточная обработка учетных событий. - PullRequest
1 голос
/ 31 декабря 2010

Мы работаем над механизмом учета событий, и до сих пор мы делаем все пакетно / последовательно.

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

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

Или просто лучше не рисковать и использовать последовательный / последовательный подход?

Ответы [ 3 ]

2 голосов
/ 31 декабря 2010

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

1 голос
/ 01 января 2011

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

Вам понадобится

  • новый компонент диспетчера, который будет отвечать за подачу в несколько потоков данных о событиях, подлежащих обработке, при сохранении согласованности (т. Е. Выставлять счета за каждое событие ровно один раз) и
  • новый компонент-агрегатор для изменения рейтинговых событий на счетах.

Обычно компонент агрегатора становится узким местом в вашей параллельной архитектуре.

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

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

0 голосов
/ 31 декабря 2010

Вы можете использовать несколько одновременных транзакций, если вы следуете правилам

проверить
en.wikipedia.org/wiki/Atomicity_(database_systems)
en.wikipedia.org/wiki/ACID
ru.wikipedia.org/wiki/Record_locking

или прочитайте все соответствующие статьи в этом разделе
http://en.wikipedia.org/wiki/Category:Transaction_processing

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...