PouchDB / CouchDB Разрешение конфликтов на стороне сервера

Question

Я новичок в pouch / couch и ищу несколько советов по обработке конфликтов. В частности, у меня есть расширение, запускающее pouchdb (распространяется для двух пользователей). Тогда идея состоит в том, чтобы экземпляр pouchdb-server или couchdb (это имеет значение для этого небольшого варианта использования?) Работал удаленно. Суть моей заботы - обработка конфликтов, данные будут часто меняться, и хотя расширения не будут выполнять живую синхронизацию, они будут синхронизироваться очень часто. У меня есть обработка конфликтов, записанная в функции отправки данных, однако могут возникнуть конфликты при синхронизации с несколькими пользователями.

Я смотрел на плагин pouch-resolve-conflicts и сразу вижу состояние автора:

«Разрешение конфликтов лучше выполнять на стороне сервера, чтобы избежать трудных отладочных циклов, когда несколько клиентов разрешают конфликты в одних и тех же документах».

Это имеет смысл для меня, но я не уверен, как реализовать такой конфликт разрешающая способность. Единственный способ, которым я могу думать, это разместить слой REST API. перед удаленной базой данных, которая обрабатывает все обновления / конфликты и т. д. с пользовательской логикой. Но тогда как я могу использовать функцию синхронизации мешочка? В этот момент я может также просто использовать другую базу данных.

Я просто не смог найти никаких ресурсов, обсуждающих, как реализовать разрешение конфликтов на стороне сервера, на самом деле наоборот.

Answer 1

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

Ниже представлен мой подход к решению аналогичной проблемы.

---

Я создал демон NodeJS, который автоматически разрешаетконфликты.Она объединяет deconflict , библиотеку NodeJS, которая позволяет разрешать документ тремя способами:

• Объединить все ревизии вместе
• Сохранитьпоследние ревизии (на основе пользовательского ключа. Например: updated_at)
• Выбор определенной ревизии (Здесь вы можете использовать свою собственную логику)

Деконфликт редакции

То, как я использую CouchDB, каждая запись является частичной.Мы всегда принимаем некоторые изменения и применяем их к последнему документу.При таком подходе мы можем легко принять стратегию merge all revision.

Сканер конфликтов

При загрузке демона выполняются два процесса.Тот, который проходит через все изменения.Если обнаружен конфликт, он добавляется к conflict queue.

. Другой процесс выполняется и остается активным: сканер непрерывных изменений.Он прослушивает все новые изменения и добавляет конфликтующие документы в conflict queue

Обработка очереди

Другой процесс запущен и продолжает опрос очереди для новых конфликтующих документов.Он получает конфликтующие документы в пакетном режиме и разрешает их по одному.Если нет документов, просто подождите некоторое время и снова начните опрос.

Answer 2

Немного поработав с Redux, я понял, что та же концепция однонаправленного потока поможет мне полностью избежать проблемы конфликтов.

Redux выглядит так ...

Итак, мой клиентский код никогда не записывает определенные данные в основную базу данных, вместо этого они записывают вставку / обновление / удаление запросов локально, которые PouchDB затем помещает в основную базу данных CouchDB. На том же сервере, что и главная CouchDB, у меня есть PouchDB в NodeJS, реплицирующий эти запросы. Программное обеспечение «Superviser» в NodeJS проверяет каждый новый запрос, изменяет их статус на «обработка», записывает запрошенные обновления, вставляет и удаляет, а затем отмечает запрос как «обработанный». Чтобы гарантировать, что они обрабатывают по одному коду, который получает каждый запрос, помещает их в FIFO. Код обработки тянет их с другого конца.

Я не имею дело со сверхвысоким объемом, поэтому задержка не имеет значения.

Я также не сталкиваюсь с ситуацией, когда множество людей могут пытаться обновить одну и ту же запись одновременно. Если это ваша ситуация, ваши запросы на обновление на стороне клиента должны будут указывать номер rev , а ваши «супервизоры» должны будут отклонять запросы на изменение, относящиеся к замененной версии. Вы должны будете выяснить, как ваш клиентский код получит и отреагировать на эти отклонения.