Мультиведущая репликация Redis

Сценарий: у Нас есть два центра обработки данных, которые работают одновременно (оба трафика подачи).
У каждого есть своя собственная вся стопка инфраструктуры, таким образом, это может работать без другого произойти.

Тем не менее мы хотели бы, когда состояние сети допускает его, чтобы наша база данных Redis синхронизировалась между двумя. Потеря ключей во время разделения сети приемлема, как имеет, делают дубликаты ключа - это - только данные кэша. Но, мы извлекаем максимальную пользу из кэша, когда оба центра обработки данных возросли (с 15-20% удачных обращений в кэш к 30-40% удачных обращений в кэш).

После некоторого поиска вокруг я не мог найти ничего, что эффективно даст нам мультиведущее устройство. (Главным образом высказывание "не делает этого" или "оно не поддерживается").

В конце я записал клиенту, который соединяется с обоими ведущими устройствами, подписывается на события ключевого пространства для базы данных и затем продвигает все команды НАБОРА между DBS (все наши ключи устанавливаются с истечением) - с некоторым внутренним "недавно замеченным" кэшем для предотвращения цикла воспроизведения.

В данный момент это работает отлично - единственная реальная оборотная сторона - то, что после того, как мы получаем новое ключевое событие, мы затем должны выпустить GETEX для получения ключа, и это - истечение - таким образом, Вы заканчиваете со вторым чтением (таким образом о 2x задержка RTT для удаленного DC). Это также ограничено действительно просто поддержкой НАБОРА.

Мой вопрос: существует ли лучший способ получить этот вид мультиосновной репликации?

Я начал смотреть на SYNC/PSYNC, но нет большого количества документации относительно этих протоколов, и не уверено, какие обязательства клиенту не, возможно, придется нарушать сервер.