Использование протокола и библиотеки memcached для взаимодействия с Kestrel

Question

РЕДАКТИРОВАТЬ

Я переместил вопросы наверх.Я оставлю описание проблемы для справки по поиску и любой справочной информации, которая может кому-то понадобиться.

Если вы используете библиотеку memcached с kestrel, не будет ли алгоритм хэширования memcached всегда искать в неправильном месте, если выиспользовать 2+ сервера в кластере и использовать надежные функции чтения (или любые другие функции)?Нужно ли менять алгоритм хеширования в библиотеке memcached?Я что-то пропустил?У кого-нибудь есть понимание?

ОБЩАЯ ИНФОРМАЦИЯ

Пользователи Kestrel хвастаются, что вы можете использовать любую библиотеку memcached для подключения к вашему кластеру kestrel, чтобы выдвигать и выгружать элементыочередь.Подумав об этом, он кажется ущербным.Memcached работает в кластере без межсерверного взаимодействия, потому что клиент определяет, где хранится ключ или где его хранить, на основе алгоритма хеширования.

Документация kestrel говорит о том, что kestrel является "в основном справедливым"потому что клиент подключается к произвольному узлу kestrel для чтения или записи в очередь.Если вы используете клиент memcached, ваш клиент всегда будет искать в одной и той же точке очереди, потому что клиент memcached использует непротиворечивый алгоритм хеширования.Очевидно, что если вы используете только один сервер kestrel в вашем кластере, это не имеет значения, есть только один раз, где искать.Даже если вы используете несколько узлов, это может быть нормально, потому что вы обращаетесь к статическому имени очереди, поэтому алгоритм хеширования всегда выглядит в одном и том же месте.

Однако дополнительные функции открываются с помощью kestrel, с которым взаимодействуютизменив имя очереди, к которой вы обращаетесь с клиента (надежное чтение инициируется добавлением / открытием и завершается нажатием / закрытием).Теоретически это должно привести к тому, что клиент будет последовательно искать неправильное местоположение для очереди и никогда не получит объект очереди, потому что он последовательно записывается в один узел и последовательно читается из другого узла.

Спасибо!

Answer 1

Отказ от ответственности: я не работал с пустельгой, но это звучит хорошо, и я немного покопался по вашему вопросу. Цитирование из документации пустельги:

Клиенты имеют список всех серверов в кластере и выберите один наугад для каждой операции

Похоже, вы правы, вам, вероятно, следует просто создать собственный алгоритм выбора сервера (это легко сделать в пользовательском классе) и просто подключиться к одному серверу и использовать его для одной операции (set / get / open) + закрыть / монитор + подтвердить) затем переключиться на другой, если хотите. Если клиент memcached переключит сервер на / open и / close, это действительно испортит вашу транзакцию, так что это не совсем безопасно, вы должны убедиться, что вы используете один и тот же сервер внутри операции kestrel, а не memcached. Если вы хотите использовать монитор и подтвердить, вам все равно придется написать свой собственный класс клиента, так что не имеет значения, какую дозу заполняет клиентская библиотека memcached.