Информация об изменениях

Сообщение Re[6]: Eventual consistency от 10.07.2018 6:26

Изменено 10.07.2018 6:30 takTak

Re[6]: Eventual consistency
я сам с этом не работал, но у майкрософта не так давно в их Service Fabric появились reliable dictionary and reliable queue classes, это типа загруженные в память коллекции , с которыми непосредственно работа происходит, как потом эти штуки сохраняются — дело десятое, важно что все узлы работают с ними, по сути это распределённый кэш в памяти, т.е. специально создан дополнительный слой, который решает проблемы о которых ты говоришь

если опыта с нет, то я бы не рекомендовал туда сразу бросаться, ты можешь на досуге сам потренироваться на кошечках, погугли , попробуй найти готовые примеры https://technology.amis.nl/2018/05/22/simple-cqrs-tweets-to-apache-kafka-to-elastic-search-index-using-a-little-node-code/

обычно вкупе с CQRS нужно выстраивать свою архитектуру по мониторингу сообщений, чтобы отслеживать застрявшие где-то сообщения, это тоже довольно нетривиально
Re[6]: Eventual consistency
я сам с этом не работал, но у майкрософта не так давно в их Service Fabric появились reliable dictionary and reliable queue classes, это типа загруженные в память коллекции , с которыми непосредственно работа происходит, как потом эти штуки сохраняются — дело десятое, важно что все узлы работают с ними, по сути это распределённый кэш в памяти, т.е. специально создан дополнительный слой, который решает проблемы о которых ты говоришь

если опыта с CQRS нет, то я бы не рекомендовал туда сразу бросаться, ты можешь на досуге сам потренироваться на кошечках, погугли , попробуй найти готовые примеры https://technology.amis.nl/2018/05/22/simple-cqrs-tweets-to-apache-kafka-to-elastic-search-index-using-a-little-node-code/

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