Синхронизация данных в распределенной системе

Question

У нас есть приложение на основе REST, построенное на платформе Restlet, которое поддерживает операции CRUD.Он использует локальный файл для хранения данных.

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

Мы решили решить эту проблему - отправитьнесколько сообщений POST (для всех других приложений), когда операция обновления происходит в данной виртуальной машине.Здесь предполагается, что у каждого приложения есть список / URL-адреса всех других приложений.

Есть ли лучший способ решить эту проблему?

Answer 1

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

Краткий рассказ: получите вашу любимую СУБД (например, mysql популярна) и подключите свои серверы приложений к так называемой трехуровневой модели . Обязательно выполняйте сложные обновления в транзакциях , что обеспечит приемлемую модель согласованности.

Долгосрочная история: Трехуровневая модель хорошо подходит для веб-сайтов / услуг малого и среднего масштаба. В конечном итоге вы обнаружите, что единственная база данных становится узким местом. Для сервисов, трафик чтения которых значительно больше трафика записи, общая оптимизация заключается в создании механизма репликации базы данных с одним или несколькими подчиненными, где все записи идут на один мастер (требуется для согласованности с нераспределенными транзакциями), но более распространенные операции чтения могут передаваться любому из считанных рабов.

Для служб с равномерно смешанным трафиком чтения / записи вы можете лучше обойтись, если отбросите некоторые удобства (и сопутствующие ограничения), которые предоставляет формальный SQL, и вместо этого используйте одно из различных хранилищ данных «nosql», которые недавно возникла. Их относительные достоинства и пригодность для решения различных проблем сами по себе являются глубокой темой.

Answer 2

Я вижу 7 основных вариантов на данный момент.Вы должны узнать больше деталей и решить, подходят ли средства / компромиссы для вашей цели

1. Выполните операцию CRUD на общей СУБД.Простейшая и наиболее согласованная
2. Выполнение операций CRUD на общей СУБД, которая работает как быстрая СУБД в памяти.например, TimesTen от Oracle и т. д.
3. Выполните CRUD для распределенного кэша или собственной распределенной хеш-таблицы домашнего приготовления, которая может гарантировать синхронизацию, например Hazelcast / ehcache и другие
4. Используйте быстрый сервер общего состояния, такой как REDIS/ memcached и выполнять ваши обновления синхронизированным способом на нем и записывать успешные операции в БД ленивым образом, если требуется.
5. Распределите серверы REST таким образом, чтобы операции CRUD над одним объектом выполнялись только одним ведущим.Как только это будет сделано, подробности об изменениях могут быть переданы всем остальным, используя надежную шину сообщений или распределенную базу данных (например, postgres), которая работает под ним и довольно быстро синхронизирует все ваши обновления.
6. Нацеленность на конечную согласованность и использование распределенного хранилища данных, такого как Cassandra, которое позволяет нацеливать на требуемую согласованность
7. Использование алгоритмов распределенного консенсуса, таких как Paxos или RAFT, или реализациято же самое (рекомендуется), как zookeeper или etcd соответственно, и становится владельцем элемента, который вы хотите изменить с каждого сервера REST перед выполнением операции CRUD, - может быть немного медленным, и Cassandra может дать вам то же самое.