Кэшированное представление Django REST Framework возвращает 2 разные полезные нагрузки
У меня возникла странная проблема с моим представлением пагинационного списка в Django REST Framework, которое использует 2-часовой кэш. Если я неоднократно делаю запросы к конечной точке представления, то иногда получаю ответ 1 (размер x байт), а иногда ответ 2 (размер y байт).
Код представления выглядит следующим образом:
class MyListView(generics.ListAPIView):
model = MyListModel
serializer_class = MyListSerializer
pagination_class = PageNumberPagination
pagination_class.page_size = 1000
def get_queryset(self):
region = self.kwargs.get('region')
sort_param = '-date_created'
return MyListModel.objects.filter(region=region).order_by(sort_param)
@method_decorator(cache_page(2*60*60))
def get(self, *args, **kwargs):
return super().get(*args, **kwargs)
Не уверен, что это имеет отношение к делу, но раз в день я запускаю cronjob, который очищает все кэшированные представления, используя следующий код:
from django.core.cache import cache
cache.clear()
Я убедился, что разница в данных ответа этой конечной точки не связана с истечением срока действия кэша и заменой его новыми данными. Я также подтвердил, что данные в базе данных для MyListModel
вообще не изменяются. Я также подтвердил, что параметр region согласован между запросами.
Я в растерянности, как я могу получить 2 разных ответа от этой конечной точки. Кэш или не кэш, базовые данные не меняются, поэтому ответ должен быть последовательным. Это наводит меня на мысль, что каким-то образом хранятся 2 кэшированных ответа, и иногда возвращаются кэшированные данные ответа 1, а иногда - кэшированные данные ответа 2. Но я все еще не знаю, по какому механизму это может происходить.
Хотя, строго говоря, это возможно, Django часто не является процессом, который вы запускаете непосредственно для ответа на HTTP-запросы. Обычно вы помещаете некоторые компоненты в середину этого процесса. Например, Gunicorn, который обычно сначала создает несколько процессов ("рабочих"), а затем направляет каждый запрос к одному из этих рабочих, в зависимости от того, какие рабочие доступны в данный момент. Это увеличивает "пропускную способность" сервера.
В зависимости от того, как вы настроите веб-сервер Django, это может привести к двум или более кэшам и другому дублированию. Таким образом, очистка одного из кэшей может помочь одному из экземпляров Django, но не (как таковому) другому.
Это обычно одна из (многих) причин, по которым используется база данных, потому что работа, выполненная одним сервером, должна быть прочитана другим сервером. Таким образом, манипулирование данными одним Django-сервером может вызвать массу проблем, если второй Django-сервер будет вынужден это читать.
Поэтому, возможно, стоит посмотреть, как вы настроили сервер для работы и как кэши отображаются на экземпляр(ы) Django.