История изменений
Исправление den73, (текущая версия) :
Беда в том, что не нужно стабильно обрезать. Достаточно иногда обрезать.
Но я уже начинаю приходить к выводу, что Redis по сравнению с SQL слаб в плане защиты целостности. Т.е. в нём не только нет транзакций, но нет и общего способа отличить задумчивого клиента от умершего клиента. В SQL для этого используется TCP keepalive (и от частоты этого keepalive неиллюзорно зависит стабильность всей системы). Тут, получается, нужно городить keepalive руками.
Кроме того, похоже на то, что нужно, вообще говоря, руками городить журнал транзакций.
Вот вопрос из SO в моём направлении:
https://stackoverflow.com/questions/49997082/is-it-possible-to-detect-that-a-...
Т.е. похоже нужно в этой ситуации вынести REDIS за скобки и считать, что мы имеем дело с идеальной системой хотя бы на одном узле. Но опять же всё упирается в необходимость постоянного вещания. Только постоянное вещание позволяет определить, что на том конце или в сети что-то пошло не так. Дальше мы по таймауту на стороне сервера принимаем решение, что сделка неудачна.
Допустим, в нашей модели это будет банк. Но надо думать дальше.
Исходная версия den73, :
Беда в том, что не нужно стабильно обрезать. Достаточно иногда обрезать.
Но я уже начинаю приходить к выводу, что Redis по сравнению с SQL слаб в плане защиты целостности. Т.е. в нём не только нет транзакций, но нет и общего способа отличить задумчивого клиента от умершего клиента. В SQL для этого используется TCP keepalive (и от частоты этого keepalive неиллюзорно зависит стабильность всей системы). Тут, получается, нужно городить keepalive руками.
Кроме того, похоже на то, что нужно, вообще говоря, руками городить журнал транзакций.
Вот вопрос из SO в моём направлении:
https://stackoverflow.com/questions/49997082/is-it-possible-to-detect-that-a-...
Т.е. похоже нужно в этой ситуации вынести REDIS за скобки и считать, что мы имеем дело с идеальной системой. Но опять же всё упирается в необходимость постоянного вещания. Только постоянное вещание позволяет определить, что на том конце или в сети что-то пошло не так. Дальше мы по таймауту на стороне сервера принимаем решение, что сделка неудачна.
Допустим, в нашей модели это будет банк. Но надо думать дальше.