Деление memcached между сайтами?

Я согласен с Найлом здесь. Другая возможность - это вы можете использовать частное IP-пространство. Допустим, вашему серверу может быть назначено 4 IP-адреса от 10.xx1 до 4. Вы можете запустить Memcached с 4 серверами и привязаться к каждому IP-адресу, тем самым предоставив всем сайтам один и тот же порт, но другой IP-адрес memcache.

Кроме того, вы можете изменить сценарий инициализации для memcached, чтобы запустить все 4 сервера и остановить их вместе за один идти. Это можно использовать с методом привязки IP или порта. Это будет очень просто для вас.

Вот пример нескольких серверов за один раз Работающий сценарий запуска нескольких серверов Memcached /etc/init.d? (см. Источник сценария вопроса).

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

В этом нет необходимости. Если учесть, что хранилище memcache на самом деле работает как стек LRU , тогда становится очевидным, что неоптимально отдавать некоторую часть памяти сайту, который используется меньше, когда сайт, который должен быть больше кэширован в memcache, будет иметь меньшую часть памяти и записи для него будут выталкиваться чаще, чем необходимо, в то время как сайт, получающий меньше трафика, будет иметь меньше неиспользуемых данных, хранящихся в этой выделенной части, которую можно было бы лучше использовать для более активных сайтов, которые вместо использования записей memcached должны достичь данные в некотором сервере SQL.

Крайне маловероятно, что Memcache когда-либо будет потреблять более 32 МБ ОЗУ для магазина Magento. Если учесть, что каждая кешируемая страница имеет размер около 4 Кбайт - у вас есть довольно много возможностей для кэшированного контента.

Я бы предложил настроить несколько экземпляров Memcached с использованием сокетов unix (это быстрее и безопаснее, чем TCP / IP). Вы можете запустить Memcached со следующими флагами

-d
-m 32
-u myuser
-s /home/myuser/cache.sock
-a 0700    

Из http://www.sonassihosting.com/blog/support/implement-memcache-for-sonassi-magento-optimised-dedicated-servers/

Ваш кэш памяти Конфигурация local.xml будет выглядеть так, и прочтите это, чтобы понять, почему необходим slow_backend - http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching -in-magento /

<cache>
 <slow_backend>database</slow_backend>
 <fast_backend>Memcached</fast_backend>
 <fast_backend_options>
 <servers>
 <server>
 <host>unix:///home/myuser/cache.sock</host>
<port>0</port>
<persistent>0</persistent>
 </server>
 </servers>
 </fast_backend_options>
 <backend>memcached</backend>
 <memcached>
 <servers>
 <server>
 <host>unix:///home/myuser/cache.sock</host>
<port>0</port>
<persistent>0</persistent>
 </server>
 </servers>
 <compression><!--[CDATA[0]]></compression-->
 <cache_dir><!--[CDATA[]]></cache_dir-->
 <hashed_directory_level><!--[CDATA[]]></hashed_directory_level-->
 <hashed_directory_umask><!--[CDATA[]]></hashed_directory_umask-->
 <file_name_prefix><!--[CDATA[]]></file_name_prefix-->
 </file_name_prefix></hashed_directory_umask></hashed_directory_level></cache_dir></compression></memcached>
</cache>

The easiest way will be, as your suspected, to have multiple instances of memcached. memcache is purposefully kept as simple as possible for speed so offers no internal forms of separation like what you're looking for. It doesn't even offer any form of authentication for the same reason!

Я согласен с обоими ответами здесь, но хотел добавить еще немного.

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

Хотя это может быть простой задачей, если это крупномасштабные, они также могут быть хорошими ресурсами для просмотра:

twemproxy

https: // github. com / twitter / twemproxy

Позволяет вам установить прокси перед memcache. Это означает, что все сайты / клиенты подключаются к процессам «Щелкунчик», которые балансируют нагрузку в пулах вашего кэша памяти.

moxi

http://code.google.com/p/moxi/

Другое решение прокси для балансировки нагрузки кэша памяти. .

Опять же, это зависит от размера вашей инфраструктуры, но это могут быть инструменты, которые помогут вам в более крупной или растущей инфраструктуре.