Какие стратегии кэширования я могу реализовать между балансировщиком веб-нагрузки и веб-фермой?

Я не уверен, что понимаю вопрос. Кэширование обратного прокси - обычная практика, и для этого существует множество инструментов. Лак и Кальмар популярны в мире с открытым исходным кодом для этого. Обычно вы помещаете пару блоков RPC за балансировщиком нагрузки, а затем либо переходите непосредственно из блоков RPC на свои веб-серверы, либо возвращаетесь через балансировщик нагрузки на веб-серверы.

Тем не менее, если вы говорите об API, обычно большая часть контента, который вы будете обслуживать, будет динамическим, что делает кеширование в основном бесполезным.

Я опаздываю на вечеринку здесь; но мне есть что внести ...

Кэл Хендерсон (кратко) рассказывает о проблемах, с которыми вы сталкиваетесь в его книга Создание масштабируемых веб-сайтов. Вам следует прочитать главу об API веб-сервисов.

Как правильно указывает мольберт, кэширование обратного прокси-сервера обычно не дает больших преимуществ для API.

Две вещи, которые принесут вам пользу:

1. Распределенный кеш ключ-значение для данных, с которыми вы работаете. Т.е. вы можете кэшировать свой горячий данные в собственном объектном формате вашей платформы, или как простые сериализованные массивы, или что-то еще, что быстро для вашей платформы. Это ограничивает количество обращений к вашей базе данных, где у вас будут самые серьезные проблемы с масштабированием. Вашим серверам API по-прежнему потребуется получать любые некэшированные наборы данных и сериализовать ответ, но, по крайней мере, часть сериализации связана только с процессором и может быть легко масштабирована.
2. Какая-то система ограничения скорости, то есть способность ограничивать или отказывать клиентам, которые делают слишком много запросов. Вызовы API обычно связаны с довольно тяжелой обработкой на ваших серверах (поскольку они читают необработанные данные или манипулируют ими), поэтому имеет смысл защитить себя от плохо написанных клиентов.

В дополнение к вышесказанному Кэл Хендерсон предлагает создавать клиентские библиотеки с открытым исходным кодом на популярных языках и применять в них лучшие практики (например, кэширование на стороне клиента, ограничение скорости). Таким образом, сторонние разработчики будут иметь простую, совместимую платформу кода для повторного использования и развития. Идея звучит великолепно, ИМХО, но тоже несколько дорого.

А слой кеширования поможет со статическим контентом, но я не понимаю, насколько это поможет с динамическими API. Однако это все еще может быть полезно.

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

Для вашего динамического материала вы можете использовать что-то вроде того, что он упомянул Вот если вы используете CDN для динамических материалов.

CDN, такие как Akamai, могут быть полезны даже для динамического контента, такого как API и SSL. Они делают это, сохраняя открытые сеансы TCP между своими граничными узлами и вашими серверами. Это уменьшает количество открытых соединений на ваших серверах и экономит массу времени и пакетов при установлении новых сеансов TCP.

Балансировщик нагрузки, такой как HAProxy, также может помочь за счет оптимизации и оптимизации сеансов TCP. Он даже может запускать пакеты размером 1500 MTU на стороне World и кадры Jumbo на стороне backend, чтобы сократить время обработки на ваших реальных серверах. В нем есть несколько уловок, позволяющих перенести обработку соединения с реальных серверов на LB. Наличие потоков и сокетов TCP на ваших серверах API, привязанных только к медленному клиенту TCP, является пустой тратой ресурсов.