Инфраструктура кеширования в Django ¶

Memcached ¶

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

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

После установки Memcached следующим шагом будет установка кода привязки Memcached. В Python доступно несколько кодов привязки Memcached; два самых популярных - python-memcached и pylibmc .

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

• Установите BACKEND на django.core.cache.backends.memcached.MemcachedCache или на 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, используя ссылку python-memcached :

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

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

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

Если вы используете код ссылки pylibmc , не используйте префикс unix:/ :

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
        'LOCATION': '/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.MemcachedCache',
        '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.MemcachedCache',
        '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 .

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

Это кэш по умолчанию, если в вашем файле настроек нет другого кеша. Если вам нужны преимущества скорости кэширования в памяти, но у вас нет возможности запускать 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 2 CULL_FREQUENCY MAX_ENTRIES 3

    Значение CULL_FREQUENCY to 0 означает, что весь кеш очищается при 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
        }
    }
}

Вот пример конфигурации движка, основанный на python-memcached ограничении размера объекта 2 МБ:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
        'OPTIONS': {
            'server_max_value_length': 1024 * 1024 * 2,
        }
    }
}

Вот пример конфигурации движка, основанного на 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,
            }
        }
    }
}

Использование кеша для просмотра в конфигурации URL ¶

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

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

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

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

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

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

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

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

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

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

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

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 .

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

Версии кеша ¶

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

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 .