Передовий досвід функціонального програмування Scala або Clojure

Я багато робив кодування для самостійного вивчення, мав певний досвід роботи з моделями паралельного програмування: Актори, Пам'ять транзакційних програм, Потік даних.

Коли я намагаюся застосувати ці архітектури до реального життя - до веб-додатків із високим навантаженням - будь-яка модель не підтримує довговічність та стійкість даних. Реальні життєві завдання потребують збереження даних наприкінці. Це означає, що мені все ж доводиться використовувати DB і захоплювати синхронізацію БД, можливі масштабування шийок пляшок тощо.

Хтось знає хороший приклад архітектури (src, текст, діаграма чи креслення), яка використовує Akka Actors або Software Transaction Memory і впроваджує стійкість в кінці?

Будь-який хороший приклад / ідея для транзакційної пам’яті, акторів, потоку даних, просторів у реальному застосуванні вітається.

Моделі Actor / STM та наполегливість баз даних є дещо ортогональними - ви можете легко мати одне без іншого, і я думаю, що існує небезпека сплутати їх.

Досягнення міцності (D у ACID) є надзвичайно складним у трансакційній обстановці, особливо в розподіленій обстановці, де у вас дійові особи / процеси координуються шляхом передачі повідомлення. Ви потрапляєте у тернисті проблеми, такі як проблема візантійських генералів .

Як результат, я думаю, що завжди існує певна ступінь адаптації рішення, щоб відповідати вашим вимогам стійкості specifc. Не існує рішень "один розмір, який підходить усім".

Варто розглянути (перспектива Clojure):

• /programming/4522796/how-should-i-make-a-clojure-stm-program-persistent
• Корма - SQL DSL
• Тему додайте наполегливості STM Clojure

Модель актора прекрасно працює з сегрегацією відповідальності за команду / запит (CQRS) , оскільки повідомлення акторам, які здійснюють маніпуляцію з даними, можуть використовуватися як еквіваленти "команди".

Отже, що це стосується вашої наполегливої ​​проблеми? Ну, ви працюєте над пам'яттю і записуєте всі команди в журнал, що є більш дешевою операцією, оскільки це лише додавання, і час від часу знімайте знімки, щоб зменшити час, необхідний для перезавантаження бази даних, якщо це необхідно (плюс, що дозволяє відновити простір, що використовується журналом).

Це досить поширена техніка. Подивіться на VoltDB та Redis для подальшого натхнення.

Rich Hickey має абсолютно нове дітище під назвою Datomic. Це новий підхід до збереження, роз'єднання сховища, управління транзакціями та запитів. Він заснований на незмінних записах і використовує мову запитів під назвою Datalog (ділиться функціями з Prolog). Основна мета полягала в тому, щоб дозволити легке розповсюдження та хмарне розгортання. Він покладається на сховище як на сервіс (тому не на одну конкретну реалізацію, а вільно поєднану через провідний API).

У Clojure у нас є STM, який дає нам ACI, D відсутній. Datomic додає D.