Я много занимался кодированием для самостоятельной работы, получил опыт работы с моделями параллельного программирования: актерами, программной транзакционной памятью, потоком данных.
Когда я пытаюсь применить эти архитектуры в реальной жизни - в веб-приложении с высокой нагрузкой - ни одна модель не поддерживает долговечность и постоянство данных. Реальные задачи требуют сохранения данных в конце. Это означает, что я все еще должен использовать DB и перехватывать синхронизацию DB, возможные узкие места масштабируемости и т. Д.
Кто-нибудь знает хороший пример архитектуры (src, текст, схема или чертежи), в которой используется Akka Actors или Software Transaction Memory и реализуется постоянство в конце?
Любой хороший пример / идея для транзакционной памяти, актеров, потока данных, пространств кортежей в реальных приложениях приветствуется.
Ответы:
Модели Actor / STM и постоянство базы данных несколько ортогональны - вы легко можете получить одно без другого, и я думаю, что есть опасность смешать два.
Достижение долговечности (D в ACID) чрезвычайно сложно в транзакционной среде, особенно в распределенной среде, в которой участники / процессы координируются передачей сообщений. Вы попадаете в острые проблемы, такие как проблема византийских генералов .
В результате я думаю, что всегда будет определенная степень адаптации решения для удовлетворения ваших конкретных требований к постоянству. Не существует единого решения для всех.
Стоит посмотреть (в перспективе Clojure):
источник
Модель актора прекрасно работает с сегрегацией ответственности «команда / запрос» (CQRS) , поскольку сообщения субъектам, которые выполняют манипуляции с данными, могут использоваться как «командные» эквиваленты.
Итак, какое это имеет отношение к вашей проблеме с постоянством? Что ж, вы работаете с памятью и записываете все команды в журнал, что является более дешевой операцией, поскольку она предназначена только для добавления, и время от времени создаете дамп-снимки, чтобы сократить время, необходимое для перезагрузки базы данных, если это необходимо (плюс возможность восстановить пространство, используемое журналом).
Это довольно распространенная техника. Посмотрите на VoltDB и Redis для дальнейшего вдохновения.
источник
У Rich Hickey появилось новое детище под названием Datomic. Это новый подход к постоянству, отделению хранилища, управлению транзакциями и запросам. Он основан на неизменяемых записях и использует язык запросов, который называется Datalog (имеет общие функции с Prolog). Основная цель состояла в том, чтобы обеспечить простое распространение и развертывание в облаке. Он опирается на хранилище как сервис (то есть не на конкретную реализацию, а на слабую связь через проводной API).
В Clojure у нас есть STM, который дает нам ACI, D отсутствует. Datomic добавляет D.
источник