Cluster
Вы не хотите использовать это для сессий. Это не нужно, так как сеансы не требуют высокой пропускной способности. Кластер также не является высокодоступным, и распределение ключей по нескольким серверам создает больше точек отказа. Это приемлемо для кэширования, но для сеансов это потребует повторного входа в систему. Это может быть смягчено с помощью ведомых устройств в кластере, но имеет те же недостатки, что указаны ниже. Кроме того, вам придется управлять гораздо большим количеством серверов, чем с Redis Sentinel.
Хозяин / Раб (со Стражем)
У главного / подчиненного Redis есть только ведущие записи, ведомые только для чтения, с возможной согласованностью и асинхронной репликацией.
Для чего-то не очень интенсивного, такого как сеансы, и критического для пользовательского опыта, я бы не стал читать от ведомых устройств, так как новый сеанс может быть недоступен на ведомых устройствах, что может вызвать некоторые незначительные проблемы с пользовательским интерфейсом при неправильных сеансах.
Аварийное переключение, с другой стороны, может быть полезным для сеансов. Любые реплицированные сеансы все еще будут сохраняться, если мастер потерпит неудачу.
Standalone
Это хороший вариант для небольших сайтов, которые не являются частью кластера (один сервер *), или сайтов, где информация для входа в систему не критична для пользовательского опыта или операций , например, только необходимость оставлять комментарии в общедоступном блоге. Будет работать простое сообщение «попробуйте позже».
Основным преимуществом этого подхода является то, что его очень просто настроить и обслуживать, так как это одна установка. Redis очень стабильный, поэтому у вас не будет проблем с самим Redis. Сбои более вероятны из-за обслуживания, обновлений или простоя сервера, чем из-за сбоя самого Redis.
* Если вы используете в работе для своего бизнеса один веб-сервер, инфраструктура Redis должна быть последней из ваших проблем. Сделайте ее максимально доступной.
Источник: Встроенная инфраструктура для высокодоступного сайта WordPress.