Фреймворк кеширования Django¶

Memcached¶

Memcached - это полностью основанный на памяти кэш-сервер, первоначально разработанный для обработки высоких нагрузок на LiveJournal.com и впоследствии открытый компанией Danga Interactive. Он используется на таких сайтах, как Facebook и Wikipedia, чтобы уменьшить доступ к базе данных и значительно повысить производительность сайта.

Memcached работает как демон, и ему выделяется определенный объем оперативной памяти. Все, что он делает, - это быстрый интерфейс для добавления, извлечения и удаления данных в кеше. Все данные хранятся непосредственно в памяти, поэтому нет накладных расходов на использование базы данных или файловой системы.

После установки самого Memcached необходимо установить привязку Memcached. Существует несколько привязок для Python Memcached; две из них поддерживаются Django: pylibmc и pymemcache.

Чтобы использовать Memcached с Django:

• Установите BACKEND на django.core.cache.backends.memcached.PyMemcacheCache или django.core.cache.backends.memcached.PyLibMCCache (в зависимости от выбранного вами привязки)
• Установите LOCATION на значения ip:port, где ip - это IP-адрес демона Memcached, а port - это порт, на котором работает Memcached, или в значение unix:path, где path - это путь к файлу сокета Memcached Unix.

В этом примере Memcached работает на порту 11211 localhost (127.0.0.1) с использованием привязки pymemcache:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": "127.0.0.1:11211",
    }
}

В этом примере Memcached доступен через локальный файл сокета Unix /tmp/memcached.sock с использованием привязки pymemcache:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": "unix:/tmp/memcached.sock",
    }
}

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

В этом примере кеш совместно используется экземплярами Memcached, работающими на IP-адресах 172.19.26.240 и 172.19.26.242, оба на порту 11211:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": [
            "172.19.26.240:11211",
            "172.19.26.242:11211",
        ],
    }
}

В следующем примере кеш совместно используется экземплярами Memcached, работающими на IP-адресах 172.19.26.240 (порт 11211), 172.19.26.242 (порт 11212) и 172.19.26.244 (порт 11213):

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": [
            "172.19.26.240:11211",
            "172.19.26.242:11212",
            "172.19.26.244:11213",
        ],
    }
}

По умолчанию бэкенд PyMemcacheCache устанавливает следующие параметры (вы можете переопределить их в своем OPTIONS):

"OPTIONS": {
    "allow_unicode_keys": True,
    "default_noreply": False,
    "serde": pymemcache.serde.pickle_serde,
}

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

Redis¶

Redis - это база данных in-memory, которую можно использовать для кэширования. Для начала работы вам понадобится сервер Redis, запущенный либо локально, либо на удаленной машине.

После настройки сервера Redis необходимо установить привязки Python для Redis. Пакет redis-py - это привязка, поддерживаемая Django. Также рекомендуется установить пакет hiredis-py.

Чтобы использовать Redis в качестве бэкенда кэша с Django:

• Установите BACKEND на django.core.cache.backends.redis.RedisCache.
• Установите LOCATION в URL, указывающий на ваш экземпляр Redis, используя соответствующую схему. См. документацию redis-py для details on the available schemes.

Например, если Redis работает на localhost (127.0.0.1) порт 6379:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379",
    }
}

Часто серверы Redis защищены аутентификацией. Чтобы ввести имя пользователя и пароль, добавьте их в LOCATION вместе с URL:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://username:password@127.0.0.1:6379",
    }
}

Если в режиме репликации настроено несколько серверов Redis, вы можете указать их в виде строки с запятой или точкой с запятой, или в виде списка. При использовании нескольких серверов операции записи выполняются на первом сервере (лидер). Операции чтения выполняются на других серверах (репликах), выбранных случайным образом:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": [
            "redis://127.0.0.1:6379",  # leader
            "redis://127.0.0.1:6378",  # read-replica 1
            "redis://127.0.0.1:6377",  # read-replica 2
        ],
    }
}

Кэширование в базе данных¶

Django может хранить свои кэшированные данные в вашей базе данных. Это лучше всего работает, если у вас есть быстрый, хорошо индексируемый сервер базы данных.

Чтобы использовать таблицу базы данных в качестве бэкэнда кеша:

• Установите BACKEND на django.core.cache.backends.db.DatabaseCache
• Установите LOCATION в значение tablename, имя таблицы базы данных. Это имя может быть любым, если это допустимое имя таблицы, которое еще не используется в вашей базе данных.

В этом примере имя таблицы кеша - my_cache_table:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.db.DatabaseCache",
        "LOCATION": "my_cache_table",
    }
}

В отличие от других бэкендов кэша, кэш базы данных не поддерживает автоматическую очистку истекших записей на уровне базы данных. Вместо этого просроченные записи кэша удаляются каждый раз при вызове add(), set() или touch().

python manage.py createcachetable

class CacheRouter:
    """A router to control all database cache operations"""

    def db_for_read(self, model, **hints):
        "All cache read operations go to the replica"
        if model._meta.app_label == "django_cache":
            return "cache_replica"
        return None

    def db_for_write(self, model, **hints):
        "All cache write operations go to primary"
        if model._meta.app_label == "django_cache":
            return "cache_primary"
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        "Only install the cache model on primary"
        if app_label == "django_cache":
            return db == "cache_primary"
        return None

Кеширование в файловой системе¶

Серверная часть на основе файлов сериализует и сохраняет каждое значение кэша как отдельный файл. Чтобы использовать этот бэкэнд, установите BACKEND на django.core.cache.backends.filebased.FileBasedCache и LOCATION в подходящий каталог. Например, чтобы хранить кэшированные данные в /var/tmp/django_cache, используйте этот параметр:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
    }
}

Если вы работаете в Windows, поместите букву диска в начало пути, например:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "c:/foo/bar",
    }
}

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

Убедитесь, что каталог, на который указывает этот параметр, либо существует и доступен для чтения и записи, либо может быть создан пользователем системы, под которой работает ваш веб-сервер. Продолжая приведенный выше пример, если ваш сервер работает от имени пользователя apache, убедитесь, что каталог /var/tmp/django_cache существует и доступен для чтения и записи пользователю apache, или что он может быть создан пользователем apache.

Кэширование в локальной памяти¶

Это кеш по умолчанию, если другой не указан в вашем файле настроек. Если вам нужны преимущества скорости кэширования в памяти, но у вас нет возможности запускать Memcached, подумайте о бэкэнде кеширования в локальной памяти. Этот кеш предназначен для каждого процесса (смотрите ниже) и ориентирован на потоки. Чтобы использовать его, установите BACKEND в "django.core.cache.backends.locmem.LocMemCache". Например:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
        "LOCATION": "unique-snowflake",
    }
}

Параметр LOCATION используется для идентификации отдельных хранилищ памяти. Если у вас только один кеш locmem, вы можете опустить LOCATION; однако, если у вас более одного кэша локальной памяти, вам нужно будет присвоить имя хотя бы одному из них, чтобы они оставались отдельными.

Кэш использует стратегию отбраковки наименее недавно использовавшихся (LRU).

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

Фиктивное кеширование (для разработки)¶

Наконец, Django поставляется с «фиктивным» кешем, который на самом деле не кеширует - он просто реализует интерфейс кеша, ничего не делая.

Это полезно, если у вас есть производственный сайт, который использует усиленное кэширование в различных местах, но в среде разработки/тестирования, где вы не хотите кэшировать и не хотите менять свой код на особый случай последнего. Чтобы активировать фиктивное кеширование, установите BACKEND вот так:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.dummy.DummyCache",
    }
}

Использование настраиваемого бэкэнда кеширования¶

Хотя Django включает в себя готовую поддержку ряда серверных модулей кеширования, иногда вам может потребоваться использовать собственный серверный модуль кеширования. Чтобы использовать внешний кэш-бэкэнд с Django, используйте путь импорта Python в качестве BACKEND параметра CACHES, например:

CACHES = {
    "default": {
        "BACKEND": "path.to.backend",
    }
}

Если вы создаете свой собственный бэкенд, то в качестве эталонных реализаций можно использовать стандартные бэкенды кэш-памяти. Код находится в директории django/core/cache/backends/ исходного кода Django.

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

Аргументы кеша¶

Каждому бэкэнду кеширования можно дать дополнительные аргументы для управления поведением кеширования. Эти аргументы предоставляются как дополнительные ключи в настройке CACHES. Допустимые аргументы:

• TIMEOUT: Тайм-аут по умолчанию в секундах, используемый для кеширования. По умолчанию этот аргумент равен 300 секундам (5 минутам). Вы можете установить для TIMEOUT значение None, чтобы по умолчанию ключи кеша никогда не истекали. Значение 0 вызывает немедленное истечение срока действия ключей (фактически «не кэшировать»).

• OPTIONS: Любые параметры, которые должны быть переданы в серверную часть кеша. Список допустимых параметров будет варьироваться в зависимости от серверной части, а серверные части кеша, поддерживаемые сторонней библиотекой, будут передавать свои параметры непосредственно в базовую библиотеку кеша.

  Бэкэнды кеширования, которые реализуют свою собственную стратегию отбраковки (т.е. бэкэнды locmem, filesystem и database), будут учитывать следующие параметры:

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

  • CULL_FREQUENCY: доля записей, которые отбираются при достижении MAX_ENTRIES. Фактическое соотношение - 1 / CULL_FREQUENCY, поэтому установите CULL_FREQUENCY на 2, чтобы отбирать половину записей при достижении MAX_ENTRIES. Этот аргумент должен быть целым числом и по умолчанию равен 3.

    Значение 0 для CULL_FREQUENCY означает, что весь кеш будет сброшен при достижении MAX_ENTRIES. На некоторых бэкэндах (в частности, в базе данных) это делает отсечение намного быстрее за счет большего количества промахов в кеше.

  Бэкенды Memcached и Redis передают содержимое OPTIONS в качестве аргументов ключевых слов в конструкторы клиента, что позволяет более детально контролировать поведение клиента. Пример использования см. ниже.

• KEY_PREFIX: строка, которая будет автоматически добавлена (добавлена по умолчанию) ко всем ключам кеша, используемым сервером Django.

  Более подробную информацию см. в cache documentation.

• VERSION: Номер версии по умолчанию для ключей кеша, сгенерированных сервером Django.

  Более подробную информацию см. в cache documentation.

• KEY_FUNCTION Строка, содержащая пунктирный путь к функции, которая определяет, как составить префикс, версию и ключ в окончательный ключ кеша.

  Более подробную информацию см. в cache documentation.

В этом примере серверная часть файловой системы настраивается с таймаутом 60 секунд и максимальной емкостью 1000 элементов:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
        "TIMEOUT": 60,
        "OPTIONS": {"MAX_ENTRIES": 1000},
    }
}

Вот пример конфигурации бэкэнда на основе pylibmc, который включает двоичный протокол, аутентификацию SASL и режим поведения ketama:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyLibMCCache",
        "LOCATION": "127.0.0.1:11211",
        "OPTIONS": {
            "binary": True,
            "username": "user",
            "password": "pass",
            "behaviors": {
                "ketama": True,
            },
        },
    }
}

Вот пример конфигурации бэкэнда на основе pymemcache, который позволяет объединять клиентов в пул (что может повысить производительность за счет сохранения подключенных клиентов), обрабатывает ошибки кэша памяти/сети как пропуски кеша и устанавливает флаг TCP_NODELAY на сокете соединения:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": "127.0.0.1:11211",
        "OPTIONS": {
            "no_delay": True,
            "ignore_exc": True,
            "max_pool_size": 4,
            "use_pooling": True,
        },
    }
}

Вот пример конфигурации для бэкенда на основе redis, который выбирает базу данных 10 (по умолчанию Redis поставляется с 16 логическими базами данных), указывает parser class (redis.connection.HiredisParser будет использоваться по умолчанию, если установлен пакет hiredis-py) и устанавливает пользовательский connection pool class (redis.ConnectionPool используется по умолчанию):

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379",
        "OPTIONS": {
            "db": "10",
            "parser_class": "redis.connection.PythonParser",
            "pool_class": "redis.BlockingConnectionPool",
        },
    }
}

Указание кеша для каждого представления в URLconf¶

Примеры в предыдущем разделе жестко запрограммировали тот факт, что представление кэшируется, потому что cache_page изменяет функцию my_view на месте. Этот подход связывает ваше представление с системой кеширования, что не идеально по нескольким причинам. Например, вы можете захотеть повторно использовать функции представления на другом сайте без кеша или распространить представления среди людей, которые могут захотеть использовать их без кеширования. Решением этих проблем является указание кеша для каждого представления в URLconf, а не рядом с самими функциями представления.

Вы можете сделать это, заключив функцию просмотра в cache_page при обращении к ней в URLconf. Вот старый URLconf из более раннего:

urlpatterns = [
    path("foo/<int:code>/", my_view),
]

Вот то же самое с my_view, заключенным в cache_page:

from django.views.decorators.cache import cache_page

urlpatterns = [
    path("foo/<int:code>/", cache_page(60 * 15)(my_view)),
]

Доступ к кешу¶

django.core.cache.caches¶

Вы можете получить доступ к кешам, настроенном в параметре CACHES, через dict-подобный объект: django.core.cache.caches. Повторные запросы одного и того же псевдонима в одном потоке вернут один и тот же объект.

>>> from django.core.cache import caches
>>> cache1 = caches["myalias"]
>>> cache2 = caches["myalias"]
>>> cache1 is cache2
True

Если именованный ключ не существует, будет вызвана ошибка InvalidCacheBackendError.

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

django.core.cache.cache¶

В качестве ярлыка кэш по умолчанию доступен в виде django.core.cache.cache:

>>> from django.core.cache import cache

Этот объект эквивалентен caches['default'].

Основное использование¶

Базовый интерфейс:

cache.set(key, value, timeout=DEFAULT_TIMEOUT, version=None)¶

>>> cache.set("my_key", "hello, world!", 30)

cache.get(key, default=None, version=None)¶

>>> cache.get("my_key")
'hello, world!'

key должен быть str, а value может быть любым выбираемым объектом Python.

Аргумент timeout является необязательным и по умолчанию равен аргументу timeout соответствующего серверного модуля в настройке CACHES (объяснено выше). Это количество секунд, в течение которых значение должно храниться в кеше. Передача None в качестве timeout приведет к кешированию значения навсегда. Значение тайм-аута, равное 0, не кэшируется.

Если объект не существует в кэше, то cache.get() возвращает None:

>>> # Wait 30 seconds for 'my_key' to expire...
>>> cache.get("my_key")
None

Если необходимо определить, существует ли объект в кэше, а в памяти хранится литеральное значение None, используйте объект sentinel по умолчанию:

>>> sentinel = object()
>>> cache.get("my_key", sentinel) is sentinel
False
>>> # Wait 30 seconds for 'my_key' to expire...
>>> cache.get("my_key", sentinel) is sentinel
True

cache.get() может принимать аргумент default. Он указывает, какое значение возвращать, если объект не существует в кэше:

>>> cache.get("my_key", "has expired")
'has expired'

cache.add(key, value, timeout=DEFAULT_TIMEOUT, version=None)¶

Для добавления ключа только в том случае, если он еще не существует, используйте метод add(). Он принимает те же параметры, что и set(), но не будет пытаться обновить кэш, если указанный ключ уже присутствует:

>>> cache.set("add_key", "Initial value")
>>> cache.add("add_key", "New value")
>>> cache.get("add_key")
'Initial value'

Если вам нужно знать, хранит ли add() значение в кеше, вы можете проверить возвращаемое значение. Он вернет True, если значение было сохранено, в противном случае - False.

cache.get_or_set(key, default, timeout=DEFAULT_TIMEOUT, version=None)¶

Если необходимо получить значение ключа или установить значение, если ключа нет в кэше, существует метод get_or_set(). Он принимает те же параметры, что и get(), но при этом значение по умолчанию не возвращается, а устанавливается как новое значение кэша для данного ключа:

>>> cache.get("my_new_key")  # returns None
>>> cache.get_or_set("my_new_key", "my new value", 100)
'my new value'

Вы также можете передать любую вызываемую переменную в качестве значения по умолчанию:

>>> import datetime
>>> cache.get_or_set("some-timestamp-key", datetime.datetime.now)
datetime.datetime(2014, 12, 11, 0, 15, 49, 457920)

cache.get_many(keys, version=None)¶

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

>>> cache.set("a", 1)
>>> cache.set("b", 2)
>>> cache.set("c", 3)
>>> cache.get_many(["a", "b", "c"])
{'a': 1, 'b': 2, 'c': 3}

cache.set_many(dict, timeout)¶

Для более эффективной установки нескольких значений используйте set_many() для передачи словаря пар ключ-значение:

>>> cache.set_many({"a": 1, "b": 2, "c": 3})
>>> cache.get_many(["a", "b", "c"])
{'a': 1, 'b': 2, 'c': 3}

Как и cache.set(), set_many() принимает необязательный параметр timeout.

В поддерживаемых серверных модулях (memcached) set_many() возвращает список ключей, которые не удалось вставить.

cache.delete(key, version=None)¶

Чтобы очистить кэш для конкретного объекта, можно явно удалить ключи с помощью команды delete():

>>> cache.delete("a")
True

touch() возвращает True, если ключ был получен успешно, в противном случае - False.

cache.delete_many(keys, version=None)¶

Если необходимо очистить сразу несколько ключей, то delete_many() может принимать список очищаемых ключей:

>>> cache.delete_many(["a", "b", "c"])

cache.clear()¶

Наконец, если необходимо удалить все ключи в кэше, используйте cache.clear(). Будьте осторожны с этим; clear() удалит из кэша все, а не только ключи, установленные вашим приложением. ..:

>>> cache.clear()

cache.touch(key, timeout=DEFAULT_TIMEOUT, version=None)¶

cache.touch() устанавливает новый срок действия ключа. Например, чтобы обновить ключ, срок действия которого истекает через 10 секунд:

>>> cache.touch("a", 10)
True

Как и другие методы, аргумент timeout является необязательным и по умолчанию соответствует параметру TIMEOUT соответствующего бэкэнда в настройке CACHES.

touch() возвращает True, если ключ был поулчен успешно, в противном случае - False.

cache.incr(key, delta=1, version=None)¶

cache.decr(key, delta=1, version=None)¶

Также можно инкрементировать или декрементировать уже существующий ключ, используя методы incr() или decr() соответственно. По умолчанию существующее значение кэша будет увеличено или уменьшено на 1. Другие значения инкремента/декремента могут быть указаны в качестве аргумента вызова инкремента/декремента. При попытке увеличить или уменьшить несуществующий ключ кэша будет выдана ошибка ValueError:

>>> cache.set("num", 1)
>>> cache.incr("num")
2
>>> cache.incr("num", 10)
12
>>> cache.decr("num")
11
>>> cache.decr("num", 5)
6

cache.close()¶

Вы можете закрыть соединение с вашим кешем с помощью close(), если это реализовано серверной частью кеша.

>>> cache.close()

Префикс ключа кеширования¶

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

Чтобы предотвратить это, Django предоставляет возможность добавлять префиксы ко всем ключам кеша, используемым сервером. Когда определенный ключ кеша сохраняется или извлекается, Django автоматически добавит префикс ключа кеша со значением параметра KEY_PREFIX.

Убедившись, что каждый экземпляр Django имеет разные KEY_PREFIX, вы можете гарантировать, что не будет конфликтов в значениях кеша.

Управление версиями кеша¶

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

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

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

>>> # Set version 2 of a cache key
>>> cache.set("my_key", "hello world!", version=2)
>>> # Get the default version (assuming version=1)
>>> cache.get("my_key")
None
>>> # Get version 2 of the same key
>>> cache.get("my_key", version=2)
'hello world!'

Версия конкретного ключа может быть увеличена или уменьшена с помощью методов incr_version() и decr_version(). Это позволяет переводить определенные ключи на новую версию, оставляя другие ключи незатронутыми. Продолжая наш предыдущий пример:

>>> # Increment the version of 'my_key'
>>> cache.incr_version("my_key")
>>> # The default version still isn't available
>>> cache.get("my_key")
None
# Version 2 isn't available, either
>>> cache.get("my_key", version=2)
None
>>> # But version 3 *is* available
>>> cache.get("my_key", version=3)
'hello world!'

Преобразование ключа кеша¶

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

def make_key(key, key_prefix, version):
    return "%s:%s:%s" % (key_prefix, version, key)

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

Параметр KEY_FUNCTION указывает путь через точки к функции, соответствующей прототипу make_key() выше. Если предоставляется, эта настраиваемая функция клавиш будет использоваться вместо функции объединения клавиш по умолчанию.

Предупреждения о ключах кеширования¶

Memcached, наиболее часто используемый бэкэнд производственного кеша, не позволяет использовать ключи кеша длиной более 250 символов или содержащие пробелы или управляющие символы, и использование таких ключей вызовет исключение. Чтобы поощрять переносимый кэш-код и минимизировать неприятные сюрпризы, другие встроенные серверные части кеша выдают предупреждение (django.core.cache.backends.base.CacheKeyWarning), если используется ключ, который может вызвать ошибку в memcached.

Если вы используете производственный бэкэнд, который может принимать более широкий диапазон ключей (пользовательский бэкэнд или один из встроенных бэкэндов без memcached), и хотите использовать этот более широкий диапазон без предупреждений, вы можете отключить CacheKeyWarning с этим кодом в модуле management одного из ваших INSTALLED_APPS:

import warnings

from django.core.cache import CacheKeyWarning

warnings.simplefilter("ignore", CacheKeyWarning)

Если вы хотите вместо этого предоставить настраиваемую логику проверки ключей для одного из встроенных бэкэндов, вы можете создать его подкласс, переопределить только метод validate_key и следовать инструкциям по использованию пользовательского бэкэнда кеширования. Например, чтобы сделать это для бэкэнда locmem, поместите этот код в модуль:

from django.core.cache.backends.locmem import LocMemCache


class CustomLocMemCache(LocMemCache):
    def validate_key(self, key):
        """Custom validation, raising exceptions or warnings as needed."""
        ...

…и используйте разделенный точками путь Python к этому классу в части BACKEND вашей настройки CACHES.