Использование Redis в качестве промежуточного кеша для REST API
У нас есть приложение iOS, которое говорит с сервером django через REST API. Большая часть данных состоит из довольно крупных объектов Item, которые связаны с несколькими связанными моделями, которые переводят в один плоский словарь, и эти данные редко меняются.
Мы обнаружили, что запрос для этого не является проблемой для Postgres, но генерация ответов JSON занимает заметное количество времени. С другой стороны, коллекции элементов различаются для каждого пользователя.
Я думал о системе рендеринга, где мы просто строим словарь для объекта Item и сохраняем его в redis как строку JSON, таким образом мы можем обслуживать API напрямую из redis (например, HMGET (идентификатор элементов в пользовательской библиотеке), который является быстрым и позволяет относительно легко регенерировать "визуализированные экземпляры", в основном всего пару сигналов post_save
.
Интересно, насколько хорош этот дизайн, есть ли в нем серьезные недостатки? Может быть, лучший способ для этой задачи?
Ответы
Ответ 1
Конечно, мы делаем то же самое в нашей фирме, используя Redis для хранения не JSON, а больших XML-строк, которые генерируются из базовых баз данных для запросов RESTful, и это экономит много сетевых перелетов и накладных расходов.
Несколько вещей, о которых следует помнить, если вы впервые используете Redis...
Выделенный сервер Redis
Redis однопоточен и должен быть развернут на выделенном сервере с достаточной мощностью процессора. Не делайте ошибки при развертывании на вашем сервере приложений или баз данных.
Высокая доступность
Настройте Redis с репликацией Master/Slave для обеспечения высокой доступности. Я знаю, что с Redis cluster было много прогресса, поэтому вы можете проверить это тоже на HA.
Кэш Хит/Мисс
При проверке Redis для "попадания" в кеш, если соединение мертво или возникает какое-либо исключение, не прерывайте запрос, просто по умолчанию для базы данных; кеширование всегда должно быть "лучшим", поскольку база данных всегда может использоваться в качестве последнего средства.