Как django обрабатывает несколько серверов memcached?

Ответ 1

Это фактический клиент memcached, который выполняет очертание. Django передает конфигурацию только от settings.CACHES клиенту.

Порядок серверов не имеет значения *, но (по крайней мере для python-memcached) вы можете указать "вес" для каждого из серверов:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': [
                ('cache1.example.org:11211', 1),
                ('cache2.example.org:11211', 10),
            ],
}

Я думаю, что быстрый взгляд на memcache.py (из python-memcached) и особенно memcached.Client._get_server должен ответить на остальные ваши вопросы:

def _get_server(self, key):
    if isinstance(key, tuple):
        serverhash, key = key
    else:
        serverhash = serverHashFunction(key)

    for i in range(Client._SERVER_RETRIES):
        server = self.buckets[serverhash % len(self.buckets)]
        if server.connect():
            #print "(using server %s)" % server,
            return server, key
        serverhash = serverHashFunction(str(serverhash) + str(i))
    return None, None

Я ожидаю, что другие клиенты memcached будут реализованы аналогичным образом.

Разъяснение по @Apreche: Порядок серверов имеет значение в одном случае. Если у вас несколько веб-серверов, и вы хотите, чтобы все они размещали одни и те же ключи на одних и тех же серверах memcached, вам нужно настроить их с тем же списком серверов в том же порядке с теми же весами

Ответ 2

Я тестировал часть этого и нашел несколько интересных вещей с django 1.1 и python-memcached 1.44.

В django с использованием 2 серверов memcache

cache.set('a', 1, 1000)

cache.get('a') # returned 1

Я посмотрел, какой сервер memcache 'a' был оштрафован на использование двух других настроек django, каждый из которых указывает на один из серверов memcache. Я смоделировал перебои в подключении, установив межсетевой экран между исходным экземпляром django и сервером memcache, в котором хранился "a".

cache.get('a') # paused for a few seconds and then returned None

cache.set('a', 2, 1000)

cache.get('a') # returned 2 right away

Клиентская библиотека memcache обновляет свою стратегию ошпаривания, если сервер не работает.

Затем я удалил брандмауэр.

cache.get('a') # returned 2 for a bit until it detected the server back up then returned 1!

Вы можете читать устаревшие данные, когда сервер memcache падает и возвращается! Memcache не делает ничего умного, чтобы попытаться предотвратить это.

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

Еще одно замечание: я читал о некоторых библиотеках кэширования объектов и запросов, и я думаю, что johnny-cache должен быть защищен от этой проблемы. Он явно не отменяет записи; вместо этого он изменяет ключ, по которому кешируется запрос при изменении таблицы. Поэтому он никогда не будет случайно читать старые значения.

Изменить: я думаю, что моя заметка о работе johnny-cache работает нормально. http://jmoiron.net/blog/is-johnny-cache-for-you/ говорит: "Есть дополнительные чтения кеша при каждом запросе на загрузку текущих поколений". Если поколение хранится в самом кэше, описанный выше сценарий может вызвать чтение устаревшего поколения.

Ответ 3

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

С сайтом, работающим на django 1.4.3, python-memcached 1.51, разговаривающим с четырьмя экземплярами memcached, мы обнаружили, что база данных запрашивается гораздо чаще, чем ожидалось. Копаясь дальше, мы обнаружили, что cache.get() возвращал None для ключей, которые, как известно, присутствовали, по крайней мере, в одном из экземпляров memcached. Когда memcached был запущен с параметром -vv, он показал, что вопрос был задан только на одном сервере!

После того, как много волос было потянуто, мы переключили бэкэнд на django.core.cache.backends.memcached.PyLibMCCache (pylibmc), и проблема исчезла.