Когда JRedis получает поддержку семантики транзакции (Redis 1.3.n, основная ветка JRedis), тогда, безусловно, она должна быть достаточно "стабильной".
Протокол Redis для нетранзакционных команд, которые сами по себе являются атомарными, позволяет получить окно неисправимого сбоя при отправке деструктивной команды, а на этапе чтения происходит сбой соединения.У клиента НЕТ СПОСОБА узнать, действительно ли Redis обработал последний запрос, но ответ был сброшен из-за сбоя сети (например).Даже базовый клиент запроса / ответа подвержен этому (и я думаю, что это не ограничивается Java, как таковой).
Поскольку протокол Redis не требует никаких метаданных (вообще) с типами DML и DDLКоманды (например, без порядкового номера команды) это окно сбоя открывается.
При конвейерной обработке больше нет последовательной связи между записываемой командой и читаемым ответом.(Канал посылает команду, состоящую из N команд позади той, которая заставила Redis выдать ответ, считываемый одновременно. Если что-то идет капутом, в воздухе много МУСОВ:)
ЭтоПри этом каждый будущий объект в канале будет помечен как неисправный, и вы будете знать точно, на каком ответе произошла ошибка.
Это квалифицируется как "нестабильный"?На мой взгляд, нет.Это проблема с конвейерной обработкой.
Опять же, Redis 1.3.n с семантикой транзакций полностью решает эту проблему.
За пределами этой проблемы с асинхронными (конвейерами) существует большая ответственностьс вашей стороны, чтобы убедиться, что вы не перегружаете вход на разъем.В значительной степени конвейеры JRedis защищают вас от этого (поскольку поток вызывающей стороны используется для выполнения сетевой записи, что, естественно, демпфирует входную нагрузку в очереди ожидающих ответов).
Но вам все равно нужно запустить тесты - вы сказали «Производство», верно?)) - и размер ваших коробок и колпачок на количество загрузочных нитей на переднем конце.
Я бы также рекомендовал не запускать более одного конвейера JRedis на многоядерных машинах.В существующей реализации (которая не разбивает на части буфер записи) есть место для повышения эффективности (в контексте полного использования полосы пропускания и максимизации пропускной способности) путем запуска нескольких конвейеров на одном сервере.Пока один конвейер занят созданием буферов для записи, другой - записи и т. Д. Но эти два конвейера будут мешать друг другу из-за их (неизбежно - помните, что они являются очередями, и должна происходить некоторая форма синхронизации) и периодической аннулированием кэша.(в каждой очереди / очереди в худшем случае - но в Doug Lea мы верим.) Так что, если конвейер A средняя задержка достигнет d1 (изолированно), то и конвейер B. К сожалению, выполнение двух из них на тех же ядрах приведет кв новом системном периоде аннулирования кэша, равном ПОЛОВИНЕ исходной системы, так ДВАЖДЫ, поскольку происходит больше недействительных кэшей (в среднем).Так что это самоубийство.Но проверьте свои условия нагрузки и на предполагаемой платформе развертывания производства.