Непоследовательные значения кеша с использованием Zend Cache с AWS ElastiCache на нескольких серверах

Мы используем Zend Cache с memcached-сервером, указывающим на кластер AWS ElastiCache с двумя узлами кеша. Наша настройка кеша выглядит так:

$frontend = array(
    'lifetime' => (60*60*48),
    'automatic_serialization' => true,
    'cache_id_prefix' => $prefix
);
$backend = array(
    'servers' => array(
        array( 'host' => $node1 ),
        array( 'host' => $node2 )
    )
);
$cache = Zend_Cache::factory('Output', 'memecached', $frontend, $backend);

Мы не замечали никаких проблем с кешем в прошлом при использовании одного сервера EC2 для записи и чтения из кеша.

Однако недавно мы представили второй сервер EC2, и внезапно мы видим проблемы при записи в кеш с одного сервера и чтения из другого. Оба сервера управляются одной и той же учетной записью AWS, и ни один из серверов не имеет проблем с записью или чтением из кеша отдельно. Такая же конфигурация кэша используется для обоих.

Сервер A выполняет $cache->save('hello', 'message');

Последующие вызовы $cache->load('message'); с сервера A возвращают ожидаемый результат привет.

Однако, когда сервер B выполняет $cache->load('message');, мы получаем false.

Насколько я понимаю ElastiCache, сервер, делающий запрос на чтение, не должен иметь никакого отношения к возвращаемому кешу. Может ли кто-нибудь пролить свет на это?

Ответ 2

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

Представьте, что у вас есть 5 узлов ElastiCache в кластере кеша, добавление шестого сервера может привести к тому, что 40% + ваших ключей внезапно указывают на разные серверы, чем обычно. Эта деятельность нежелательна, может привести к промахам в кэше и, в конечном итоге, погрузить ваши БД с запросами. Чтобы свести к минимуму это переназначение, рекомендуется следовать последовательной модели Hash в ваших клиентах кеша.

Consistent Hashing - это модель, которая позволяет более стабильно распределять ключи при добавлении или удалении серверов. Согласованное Хеширование описывает методы сопоставления ключей со списком серверов, где добавление или удаление серверов вызывает очень минимальный сдвиг в том, где отображаются ключи. Используя этот подход, добавление одиннадцатого сервера должно привести к переназначению менее 10% ваших ключей. Этот% может варьироваться в производстве, но он намного эффективнее в таких эластичных сценариях по сравнению с обычными алгоритмами хеширования. Рекомендуется также поддерживать порядок хранения серверов memcached и количество серверов во всех клиентских конфигурациях при использовании согласованного Hashing. Приложения Java могут использовать "библиотеку Ketama" через spymemcached для интеграции этого алгоритма в свои системы. Более подробную информацию о последовательном хэшировании можно найти на http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients

Ответ 1

Ответ 2