ИМХО, вы вводите ненужную сложность вместо более простого решения. Это были бы мои альтернативные предложения вместо вашего подхода к json patch cron, который очень сложно сделать последовательным и атомарным.

1. Использовать только mongodb: при правильном проектировании базы данных и индексации, а также при правильном распределении/разбиении аппаратного обеспечения производительность записи mongodb очень высока. И типы операций, которые вы используете в jsonpatch, изначально поддерживаются в документах mongodb BSON и их языке запросов, например, $push, $set, $inc, $pull и т. д. Возможно, вы хотите не прерывать действия пользователей с помощью синхронной записи в Mongodb , для этого решение использует асинхронную очередь, как указано в пункте № 2.

   2.Использовать очереди задач и mongodb: вместо хранения исправлений в Redis, как вы делаете сейчас, вы можете поместить задачу исправления в очередь задач, которая будет асинхронно выполнять обновление mongodb, и пользователь не будет испытывать любое медленное исполнение. Одной из очень хороших очередей задач является Celery , которая может использовать Redis в качестве брокера и серверной части для обмена сообщениями. Таким образом, обновления каждого пользователя получают одну задачу и будут применяться к mongodb очередью задач, и производительность не пострадает.

Как и в случае с любой системой, которая может стать несовместимой, вы должны разрешить применение исправлений как можно быстрее, если хотите быстрее обнаруживать конфликты и уменьшать вероятность их возникновения. Скорее всего, это ваша основная проблема, если вы не уведомляете других клиентов о каких-либо обновленных данных как можно скорее (и просто ждете, пока CRON запустится для обновления общих данных, к которым могут получить доступ другие клиенты). ).

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

1. Пользователь применил некоторые операции, которые потерялись при переводе. Как? Я не знаю, но это объяснило бы несоответствие.
2. Операции не применяются в правильном порядке. Как? Я не знаю. У меня нет кода, чтобы уйти.

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

1. Порядок операций.
2. Как мы будем справляться с конфликтами.

Последнее действительно зависит от вас, и вам понадобится хорошая система уведомлений / обмена сообщениями, чтобы обновлять «правду», которую видят клиенты.

Сценарий 1

Пользователь A применяет операции 1 и 2. Документ обновляется на сервере, а затем пользователь B уведомляется об этом. Пользователь Б собирался применить операции 3 и 4, но эти операции (в таком порядке) не конфликтуют с операциями 1 и 2. В мире все хорошо. Это хорошая ситуация.

Сценарий 2

Пользователь А применяет операции 1 и 2. Пользователь Б применяет операции 3 и 4.

Если вы применяете операции атомарно для каждого пользователя, вы можете получить следующие очереди:

[1,2,3,4] [3,4,1,2]

В любом месте, если возникает конфликт, вы должны уведомить либо пользователя A, либо пользователя B на основе того, «кто дошел первым» (или любой другой семантики взвешивания, которую вы хотите использовать). Опять же, как вы справляетесь с конфликтами, зависит от вас. Если вы еще не читали о векторных часах, вам следует это сделать.

Если вы не применяете операции атомарно для каждого пользователя, вы можете получить следующие очереди:

[1,2,3,4] [3,4,1,2] [1,3,2,4] [3,1,4,2] [3,1,2,4] [1,3,4,2]

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

Резюме

Некоторые важные вещи, которые вы должны помнить:

1. Убедитесь, что обновления очереди применяются атомарно для каждого пользователя.
2. Выясните, как вы будете справляться с несколькими версиями общего ресурса, возникающими в результате множественных мутаций от разных клиентов (опять же, я предлагаю вам прочитать о векторных часах).
3. Не обновляйте общий ресурс, к которому могут обращаться несколько клиентов в режиме реального времени, как задание cron.
4. Когда есть конфликт, который не может быть разрешен, подумайте, как вы будете с ним справляться.
5. В результате пункта 3 вам нужно будет придумать систему уведомлений, чтобы клиенты могли быстро получать обновленные ресурсы. В результате пункта 4 вы можете включить сообщение клиентам о том, что что-то пошло не так с их обновлением. Что-то, что только что пришло мне в голову, это то, что вы уже используете Redis, который имеет возможности pub/sub.

ИЗМЕНИТЬ:

Похоже, Google Docs разрешает конфликты с помощью преобразований. То есть путем сдвига целых символов/строк, чтобы освободить место для гибридного применения всех операций: docs_22.html" rel="nofollow noreferrer">https://drive.googleblog.com/2010/09/whats- Different-about-new-google-docs_22.html

Как я уже говорил ранее, все зависит от того, как вы хотите справляться со своими собственными конфликтами, которые в значительной степени должны определяться самим приложением/продуктом и вариантами его использования.