Memcached - как бороться с добавлением / развертыванием серверов

Question

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

Вот как memcached заполняется нормально:

$m = new Memcached();

$servers = array(
    array('mem1.domain.com', 11211, 33),
    array('mem2.domain.com', 11211, 67)
);
$m->addServers($servers);

Моя первоначальная идея состоит в том, чтобы сделать массив $ servers для заполнения из базы данных, также кэшированным, но основанным на файлах, выполняемым один раз в день или с чем-то, с возможностью принудительного обновления при следующем запуске функции содержит вызов $ addservers. Тем не менее, я предполагаю, что это может добавить некоторые дополнительные издержки, поскольку диски имеют довольно медленное хранение ...

Что ты думаешь?

Answer 1

Используйте файл конфигурации - будь то из файла parse_ini_file или какой-либо другой схемы синтаксического анализа. Если вы беспокоитесь о времени разбора, вы можете поместить эти конфиги в путь загрузки php ini http://brian.moonspot.net/using-ini-files-for-php-application-settings - это предварительно проанализирует все необходимые вам переменные, но вам нужно будет перезапустить apache для загрузки любых изменений.

Как только файлы будут прочитаны достаточно (если у вас не слишком много копий на вашем компьютере), файл конфигурации все равно будет находиться в кеше с отображенной памятью, поэтому он будет очень быстрым. Вы можете оптимизировать, используя сериализованную форму php, которая быстро загружается, и даже оптимизировать ее, используя кэш пользователя APC.

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

Answer 2

Всегда лучше определить такие вещи в источнике. Конечно, вы можете использовать parse_ini_file() или что-то подобное для чтения файла конфигурации. Правда, это принадлежит источнику. Но если он определен в INI-файле, проблем с безопасностью, таких как внедрение кода и тому подобное, не так много, в отличие от определения ваших записей в PHP.

Поскольку существует несколько приложений, которые могут считывать один и тот же файл INI, вы можете поместить его в общую папку, к которой имеют доступ все приложения (например, с помощью групповых разрешений). На самом деле делать это не рекомендуется.

Answer 3

Насколько я понял, главная проблема здесь заключается в том, как кэшировать конфигурацию, чтобы она в основном обновлялась при ее изменении.

Что ж, лучшим вариантом здесь, очевидно, является сохранение его в базе данных и обновление из БД, скажем, каждые 15 секунд. С большой нагрузкой на приложение, запрос БД каждые 15 секунд ничего не изменит. Загрузка данных из самой БД довольно быстрая, так как вам нужно всего несколько полей.

Еще один вариант, который может сработать здесь - использовать отдельный memcached :) Серьезно, просто кэшируйте конфигурацию, загруженную из БД, очищая этот ключ кэша при обновлении конфигурации.

Подводя итог: любая схема истечения срока действия будет работать. Самое простое решение - сохранить его самостоятельно (сохранить последнее время обновления и проверять его при каждом вызове функции); немного более продвинутый - используйте что-то вроде memcached.

update : БД - лучшее решение, поскольку оно хорошо масштабируется: вам не нужно копировать конфигурации на 20 серверах при каждом обновлении конфигурации.

Answer 4

В зависимости от ваших требований, я бы использовал список, который поддерживает автоматическое выселение после некоторого TTL (пассивного режима) или какого-то типа шаблона слушателя, если вы хотите, чтобы это было обновлено немедленно (активный режим). Где бы вы ни хранили свой первоисточник (файл свойств, база данных и т. Д.), Это не очень важно, если он доступен, когда это необходимо, и ваш TTL достаточно велик (как вы упомянули в своем комментарии).

Для пассивного подхода вы можете использовать другую локальную библиотеку кэширования, которая поддерживает TTL (например, EHCache в Java), поместив список серверов в кеш под некоторым известным ключом. Например, для активного подхода Java имеет java.util.EventListener. К счастью, прошло много лет с тех пор, как я что-то делал в PHP, поэтому не могу посоветовать это.

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

Возможно, вы также захотите взглянуть на , как last.fm использует согласованный алгоритм хеширования для возможности добавления / удаления серверов в / из пула memcached, не вызывая полную переназначение всех ключей.

Answer 5

• Используйте локатор услуг, например - https://www.consul.io/. Добавьте или удалите сервисы, и потребители получат информацию о сервисах от консула в режиме реального времени.
• Если консул берет на себя больше усилий по управлению новым программным обеспечением, переместите информацию в централизованный конфиг. При обновлении перезагрузите конфигурацию или запустите события обновления. Потребители слушают события и обновляют информацию.