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

Memcached ¶

Memcached - это самый быстрый и наиболее эффективный тип кеша, изначально поддерживаемый Django. Это полностью основанный на памяти кэш-сервер, изначально разработанный для обработки высоких нагрузок на 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( в зависимости от выбранного Memcached связывания)
• Набор LOCATIONдля ip:portзначений, где ipэто IP - адрес Memcached демон и portэто порт , на котором работает Memcached, или к unix:pathзначению, где pathэто путь к файлу сокета Memcached Unix.

В этом примере 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',
        ]
    }
}

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

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

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',
    }
}

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_FREQUENCYCULL_FREQUENCY2MAX_ENTRIES3

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

  Серверные модули Memcached передают содержимое 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бэкэнда на основе, который включает пул клиентов (что может повысить производительность, поддерживая подключение клиентов), обрабатывает ошибки кэша памяти / сети как промахи кеша и устанавливает 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,
        }
    }
}

Указание кеша для каждого просмотра в 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( ключ , значение , тайм-аут = DEFAULT_TIMEOUT , версия = None ) ¶

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

cache.get( ключ , по умолчанию = Нет , версия = Нет ) ¶

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

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

timeoutАргумент является необязательным и по умолчанию к timeoutаргументу соответствующего внутреннего интерфейса в CACHESустановке (описано выше). Это количество секунд, в течение которых значение должно храниться в кеше. Передача Nonefor timeoutприведет к кешированию значения навсегда. A timeoutof 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( ключ , значение , тайм-аут = DEFAULT_TIMEOUT , версия = 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( ключ , по умолчанию , тайм-аут = DEFAULT_TIMEOUT , версия = 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( ключи , версия = Нет ) ¶

Также есть 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( диктат , тайм-аут ) ¶

Чтобы установить несколько значений более эффективно, используйте 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( ключ , версия = Нет ) ¶

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

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

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

cache.delete_many( ключи , версия = Нет ) ¶

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

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

cache.clear() ¶

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

>>> cache.clear()

cache.touch( ключ , тайм-аут = DEFAULT_TIMEOUT , версия = None ) ¶

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

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

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

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

cache.incr( ключ , дельта = 1 , версия = нет ) ¶

cache.decr( ключ , дельта = 1 , версия = нет ) ¶

Вы также можете увеличивать или уменьшать уже существующий ключ с помощью методов 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настроек.