Я использую довольно простые веб-сайты PHP в Ubuntu с экземплярами AWS EC2, которые используют *.rds.amazonaws.com
доменные имена для подключения к соответствующим экземплярам RDS.
Это вызывает 2 проблемы:
Когда истекает срок действия кеша DNS, каждые 5 секунд следующий запрос добавляет минимум 12 мсек ко времени обработки моих веб-сайтов, что не идеально (я стараюсь не выходить за рамки бюджета в 100 мс).
Иногда этот шаг разрешения не удается, поэтому вместо того, чтобы показывать моим клиентам страницу с ошибкой, мой скрипт будет спать примерно на 500 мс, а затем попытается снова.
Мне интересно, есть ли что-то, например, локальный кеширующий DNS-преобразователь, который мог бы более изящно справиться с этими проблемами?
Возможно, он сможет кэшировать IP-адрес на 3 секунды, а затем автоматически попытаться обновить этот кеш, зная, что у него осталось 2 секунды. И если он продолжает терпеть неудачу, все равно предоставляйте старый / устаревший ответ, поскольку это лучше, чем отсутствие ответа.
Или он может предложить кэшированный ответ немедленно, даже если срок его действия истек (вероятно, он все еще верен); и если вы просто предоставили просроченный ответ, запустите обновление, на случай, если экземпляр RDS только что переместился.
Или я могу обойтись без сценария, который проверяет ответ DNS в цикле (dig +short
), а при изменении IP-адреса обновите /etc/hosts
файл, используя имя хоста, например database-abc
.
Кстати, мои сайты, как правило, получают около ~ 4 запросов каждые 5 секунд в течение дня (поэтому обновления кеша довольно часты), но в ночное время активность низкая.
Согласно Документация по AWS Route 53:
Amazon Route 53 эффективно связывает запросы пользователей с инфраструктурой, работающей в AWS, например инстансами Amazon EC2, балансировщиками нагрузки Elastic Load Balancing или корзинами Amazon S3, а также может использоваться для маршрутизации пользователей в инфраструктуру за пределами AWS. Amazon Route 53 можно использовать для настройки проверок работоспособности DNS для маршрутизации трафика к работоспособным конечным точкам или для независимого мониторинга работоспособности вашего приложения и его конечных точек.
Для вашего конкретного сценария вот статья