Система кэширования Django

Memcached

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

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

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

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

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

В этом примере Memcached работает на локальном компьютере (127.0.0.1), порт 11211, с привязкой 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 — это база данных в памяти, которую можно использовать для кэширования. Для начала потребуется запустить сервер Redis локально или на удаленной машине.

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

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

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

Например, если Redis работает на локальном компьютере (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 будет очищен весь кэш. В некоторых серверных частях (в частности, database) это значительно ускоряет очистку за счет увеличения числа промахов кэша.

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

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

  Подробнее см. в документации по кэшированию.

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

  Подробнее см. в документации по кэшированию.

• KEY_FUNCTION: строка с точечным путем к функции, определяющей, как объединить префикс, версию и ключ в итоговый ключ кэша.

  Подробнее см. в документации по кэшированию.

В этом примере настраивается серверная часть на основе файлов с временем ожидания 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, которая включает пул клиентов (что может повысить производительность за счет поддержания подключений клиентов), обрабатывает ошибки Memcached и сети как промахи кэша и устанавливает флаг 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 логическими базами данных) и задает пользовательский класс пула соединений (по умолчанию используется redis.ConnectionPool):

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379",
        "OPTIONS": {
            "db": "10",
            "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, можно получить через объект, похожий на словарь: 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, который можно сериализовать с помощью pickle.

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

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

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

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

>>> 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

delete() возвращает 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."""
        ...

…и укажите путь к этому классу в точечной нотации в параметре BACKEND настройки CACHES.