Введение
Мы начали использовать базу данных в нашем веб-клиенте, поскольку хотим, чтобы она работала в автономном режиме. В настоящее время мы используем HTTP GET-запросы для получения данных с сервера с ETag / If-None-Match в качестве единственной оптимизации связи.
Из-за клиентской базы мы считаем это неуместным. Например, когда клиент запрашивает список текущих предложений, он либо получает 304 NOT MODIFIED, либо получает весь список, который обычно лишь незначительно отличается от того, что у него уже есть.
Поэтому мы решили добавить в ответ метку времени, которая отправляется с новым запросом, чтобы только созданные или обновленные элементы (давайте игнорируем удаления ), так как последний запрос должен быть включен в новый ответ.
Проблема
Поскольку все наши элементы в базе данных имеют метку времени модификации, это должно быть легко. Однако он работает только тогда, когда в момент времени t все элементы с отметкой времени ts <= t видны на сервере. Это не так по нескольким причинам, таким как изоляция транзакций и репликация базы данных (мы планируем использовать кластер galera).
Может произойти следующее:
- Первоначально нет данных.
- В момент
t=5 сервер отправляет пустой список клиенту.
- В момент
t=6 в базе данных появляется элемент с ts=4 (из POV сервера).
- Во время
t=7 клиент запрашивает новости с t=5 (отметка времени, полученная в последнем ответе).
- Сервер не видит элементов, созданных или обновленных с тех пор, и снова отправляет пустой список.
Клиент пропустил элемент, и это сломанное состояние получает никогда не исправляется .
Возможное средство правовой защиты
Допускает некоторое перекрытие (когда клиент заявляет, что все данные были в момент времени t, проверьте все изменения, начиная с t - Δ) может помочь , но с длительными транзакциями и репликацией нет нормального верхнего предел. Мы хотим синхронизировать клиента каждую секунду, поэтому перекрытие (Δ), скажем, пять секунд, будет означать отправку каждого изменения пять раз.
Это было бы довольно плохо, но это все равно не дает нам гарантии, что устаревшие данные не останутся в клиенте навсегда.
Мы могли бы заменить временную метку списком (id, timestamp) пар всех элементов, но это звучит довольно непрактично.
Вопросы
Хотя существует множество статей по синхронизации баз данных, я не смог найти ничего, касающегося этой «частичной синхронизации». Возможно, я пропустил правильные условия поиска .... Кто-нибудь делал это?
Есть ли простое и эффективное решение вышеуказанной проблемы?
Или, может быть, хорошая альтернатива?