Подтвердить что ты не робот

Использование Redis в качестве промежуточного кеша для REST API

У нас есть приложение iOS, которое говорит с сервером django через REST API. Большая часть данных состоит из довольно крупных объектов Item, которые связаны с несколькими связанными моделями, которые переводят в один плоский словарь, и эти данные редко меняются.

Мы обнаружили, что запрос для этого не является проблемой для Postgres, но генерация ответов JSON занимает заметное количество времени. С другой стороны, коллекции элементов различаются для каждого пользователя.

Я думал о системе рендеринга, где мы просто строим словарь для объекта Item и сохраняем его в redis как строку JSON, таким образом мы можем обслуживать API напрямую из redis (например, HMGET (идентификатор элементов в пользовательской библиотеке), который является быстрым и позволяет относительно легко регенерировать "визуализированные экземпляры", в основном всего пару сигналов post_save.

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

4b9b3361

Ответ 1

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

Несколько вещей, о которых следует помнить, если вы впервые используете Redis...

Выделенный сервер Redis
Redis однопоточен и должен быть развернут на выделенном сервере с достаточной мощностью процессора. Не делайте ошибки при развертывании на вашем сервере приложений или баз данных.

Высокая доступность
Настройте Redis с репликацией Master/Slave для обеспечения высокой доступности. Я знаю, что с Redis cluster было много прогресса, поэтому вы можете проверить это тоже на HA.

Кэш Хит/Мисс
При проверке Redis для "попадания" в кеш, если соединение мертво или возникает какое-либо исключение, не прерывайте запрос, просто по умолчанию для базы данных; кеширование всегда должно быть "лучшим", поскольку база данных всегда может использоваться в качестве последнего средства.