Все веб-кэши понимают HTTP-заголовок “Управления Кэша”?

К Вашему первому вопросу: Да, в нормальной конфигурации HAProxy все потоки трафика через подсистему балансировки нагрузки и когда это входит к Вашим серверам, и когда она выходит снова от серверов до клиентов. Это более или менее всегда так со всеми подсистемами балансировки нагрузки, поскольку они обычно реализуются как Прокси HTTP или уровень IP NAT / направляющий поля. Исключение - когда "прямой возврат сервера" (DSR) используется, посмотрите это объяснение inlab.com того, каков DSR.

Мои подсистемы балансировки нагрузки и бэкенды расположены в различных частях США

Ehh, почему? Если бы Вы используете геовыравнивание нагрузки или многоадресную маршрутизацию затем, я не ожидал бы, что Вы зададите эти вопросы. В нормальной эксплуатации заключают Вас в корпус, действительно должен иметь Ваши серверы в той же стойке, и на быстрой низкой задержке без коллизий LAN. Это сделало бы жизнь легче для Вашего программного обеспечения сервера и дало бы Вам больше производительности с Ваших серверов, а также более последовательный / надежные рабочие характеристики...

Каноническая установка для программного обеспечения, которое Вы используете, была бы чем-то вроде этого:

nginx (для сжатия HTTP)-> кэш Лака (для кэширования)-> подсистема балансировки нагрузки уровня HTTP (HAProxy, или nginx или встроенный Лак)-> веб-серверы.

Дополнительно, если Ваша загрузка высока, Вы могли бы иметь несколько nginx или лакировать серверы в очень переднем; но это для сайтов с тысячами запроса в секунду.

К Вашему второму вопросу, Когда Вы спрашиваете "более эффективный", я вызываю сомнение о том, что Вы имеете в виду. Более эффективный как в более низком трафике между серверами? Незначительно, поскольку кэш Лака останавливает некоторое движение от идущего далее назад. Более эффективный относительно использования ЦП - можно просто переставить сервисы вокруг к менее загруженным физическим серверам, пока Вы сохраняете логическую структуру тем же.