Часто в компаниях есть штатные редакторы, которые работают с некими сайтами этой, принадлежащими ей — наполняют их контентом, модерируют и т.д. Обычно редакторы вместе с обычными пользователями пользуются одной версией сайта, которая располагается на хостинге в сети. Но это не оптимально, так как лишний трафик (прежде всего HTML-код страниц, рисунки, css) гуляет с сервера на офис, занимая внешний канал компании и тратя трафик веб-сервера. При мдленном внешнем канале тратится так же и время редакторов.
В идеале, в данном случае передавать необходимо только добавляемые и получаемые данные, так как весь антураж может быть сохранен и доступен в пределах офиса локально.
Для решения этой задачи можно использовать общую базу данных, которая будет располагаться на хостинге. На сервере в локальной сети поднять сайт, указать для подключения к СУБД параметры доступа к база на удаленном сервере. Таким образом, у вас будут 2 одинаковых сайта, параллельно работающих с одним источником данных.
В принципе это обычная схема для балансировки нагрузки на фронтэнд (web-сервер). Практику много фронтэндов — один бэкэнд (база) применяют довольно часто, а следующий этап разделения нагрузки (когда уже СУБД не выдерживает напора) — кластеризация серверов баз данных. Но это лирическое отступление.
Следуюет учесть три нюанса. Во-первых, так как сервера у нас теперь два, время на них может быть разное. Следовательно при записи в базу временные показатели будут для серверов расходиться и может возникнуть путаница. Чтобы этого избежать, проще всего брать время из СУБД. Делать это надо естественно 1 раз за запрос (кэшировать), а не при каждой необходимости (при условии, что запрос выполняется не более 1 секунды; если больше, значит ваша система нуждается в оптимизации). Таким образом время на всех серверах будет синхронизировано по времени на сервере с СУБД.
Второй нюанс заключается в том, что по сети информация между сервером на офисе и базой у провайдера будет ходить в открытом виде, что потенциально опасно. Так же опасно создавать пользователя, которому будет разрешено удаленно подключаться к сети с любого хоста, так как получив ваш пароль злоумышленник легко завладеет базой и сайтом (если IP статичский, второй аспект не актуален).
Решить эту проблему можно через подключение к СУБД по защищенному SSL-протоколу. Популярные СУБД поддерживают SSL (MySQL, PgSQL). Подключение клиента к серверу через SSL поддерживают родные C API этих СУБД, и PHP MySQL/PgSQL API тоже. Но SSL не поддерживается PDO (во всяком случае я не нашел информацию о поддержке), который в настоящее время очень популярен и который следует использовать. По этому вариант подключения к базе через SSL отпадает.
Остается другой, довольно простой для использования и сложный для настройки вариант — перегон трафика между офисом и хостингом через VPN. Сам VPN я уже описывал в своем блоге. После поднятия VPN-тоннеля необходимо прописать роут на IP вашего сервера (того сервера, где находится СУБД) через виртуальный интерфейс VPN-соединения. Таким образом весь трафик между PHP и СУБД будет ходить по безопасному зашифрованному каналу.
Третий нюанс заключается в кэшировании. Часто кэш некоторых элементов заводят пожизненно (или на долгое время), а сбрасывается он только при изменении данных редактором. В этом случае, при внесении изменений на одном из серверов, кэш не сбросится на втором и на неопределенный срок там останется неактуальная информация. Эта проблема решается через изменение стратегии кэширования, либо использование общего сервера кэширования и выходит за рамки данной статьи. Если именно этот вопрос для вас остается актуальным, ищите информацию в гугле, т.к. та же самая проблема существует при балансировке нагрузки путем «размножения» фронэндов.
Когда все проблемы решены, все что остается делать — это следить за тем, чтобы версии скриптов на серверах в сети и на офисе были одинаковыми, чтобы не повредить базу.
Теперь редакторы сайта смогут пользоваться более быстрой локальной версией сайта, но все изменения будут отображаться в том числе и на сайте в сети.