В настоящее время я использую производственную среду с 4 выделенными серверами memcached, каждый из которых имеет 48 ГБ ОЗУ (42 выделены для memcache). Сейчас у них все в порядке, но трафик и контент растут и, несомненно, будут расти и в следующем году.
Что вы думаете о стратегиях дальнейшего масштабирования memcached? Как у вас дела до сих пор:
Добавляете ли вы в ящики больше ОЗУ до их полной емкости - фактически удваивая кэш-пул на том же количестве ящиков? Или вы масштабируете по горизонтали, добавляя больше тех же блоков с тем же объемом оперативной памяти.
Текущие блоки, безусловно, могут обрабатывать больше оперативной памяти, поскольку их загрузка процессора довольно низкая, единственное узкое место - это память, но мне интересно, не было бы лучшей стратегией распределить кеш, делая вещи более избыточными и минимизируя влияние на кеш потерять одну коробку (потеря 48 ГБ кеша против потери 96 ГБ). Как бы вы (или вы) справились с этим решением?
Когда я это делаю, обычно возникает безубыточность между размером блока точек (стоимостью места в стойке), расходами на микросхемы высокой плотности и обработкой сценария отказа. Это почти всегда заканчивается конфигурацией меньше максимальной плотности памяти (а также, как правило, не самых быстрых доступных чипов), что, как вы упомянули, улучшает влияние сбоя узла и обычно делает их более рентабельными. Некоторые затраты / вещи, которые следует учитывать при выборе:
Я также сделал обновления до максимальных ящиков по мере роста кластеров (обычно, когда они довольно маленькие), так как в краткосрочной перспективе может быть значительно дешевле купить больше памяти при масштабировании, чтобы дать вам больше времени для создания более крупной архитектуры. решения.
Я так хочу знать, что вы перемещаете, что потребляет более 100 ГБ памяти, не перегружая ваши сетевые карты.
Memcache довольно линейно масштабируется между машинами, поэтому вам нужно задать следующие вопросы:
Масштабирование - это 10% интуиции, 70% измерений и адаптации и 20% попыток вернуться и попробовать что-то еще.
Загружайте их, пока они не исчерпают самое слабое звено или не перестанут быть рентабельными. Они могут быть, а могут и не быть там.