Это во многом связано с тем, как на самом деле распространяется memcache .По сути, вы инициализируете клиента списком из одного или нескольких серверов, которые он может использовать.Когда вы выполняете запись, данные отправляются только на один сервер, а не на все.
Клиент отвечает за хеширование ключа кэша, чтобы определить, к какому серверу он должен подключиться, как для чтения, так и для записи - тот же принципв виде хеш-таблицы, определяющей, в каком сегменте, вероятно, находится данный ключ. Некоторым memcache клиентам может быть предоставлена информация о весе и т. д., чтобы сделать их решение более точным.инициализировать клиента двумя серверами, а затем отключить один из них.Если вы реконфигурируете (например, закомментируете) список серверов, то вы эффективно изменяете эту стратегию хеширования на лету, и она несовместима с той, которая используется для определения места хранения данных.Когда вы возвращаете другой сервер обратно, клиент повторно включает его в вычисление хэша, и затем , что становится несовместимым с тем, как данные были сохранены.
Типичный обходной путь для этого, который я видел, состоит в том, чтобы попытаться избежать изменения числа (или порядка) фактически запущенных экземпляров memcached , обычно путем подготовки нескольких резервных копий.Это могут быть узлы с меньшими ресурсами, работающие на том же компьютере, что и ваши другие экземпляры, если они вам нужны - и они даже не нуждаются в оперативном резерве, если вы вызываете их при изменении конфигурации memcache.
Очевидно, что если вы используете memcache для хранения «важных» данных, таких как информация о сеансе, которые не сохраняются в других местах, то вам больше важна поддержка такого рода целостности, чем если бы вы былина самом деле просто использовать его в качестве одноразового кэша, который, в худшем случае, на некоторое время повлияет на вашу производительность.Это действительно компромисс.
Стоит прочитать: