Какая CMS может обрабатывать страницы с нескольких хостингов?

Вам следует изучить Percona, компанию, занимающуюся производительностью MySQL, которая поставила MySQL на стероиды. Они легко поддерживают среду Master / Master / Master и могут легко достичь этого без необходимости изменять значения автоинкремента от мастера к мастеру.

У них есть продукт под названием XtraDB Cluster. Это бесплатный продукт, работает так же, как MySQL, устанавливается таким же образом, но обрабатывает кластеризацию на уровне БД и делает чертовски хорошую работу.

Когда ваша БД окажется под контролем, вы можете установить CMS на один из серверов, внести изменения, скопировать ее на все другие серверы, и вся ваша среда будет готова к аварийному переключению.

Согласно добавленной информации в вашем комментарии, похоже, что мы говорим о статическом контенте.

Существующие системы

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

В зависимости от ваших потребностей вы можете сделать выбор между синхронизацией вашей базы данных или синхронизацией файлов.

Синхронизация файлов

Если вы можете отправить все полностью статично, синхронизация файлов будет работать хорошо. Хотя я вижу здесь проблему. Например: если вам нужен список последних новостей, вам также придется его сгенерировать и синхронизировать. Когда вы используете синхронизацию базы данных, вы можете просто выполнить простой запрос, необходимый SELECT * FROM news ORDER BY created_at DESC LIMIT 0,10.

Количество действий синхронизации

Другой момент - это объем синхронизации, который вам необходимо выполнить. Если у вас есть экран, например, с 10 новостями в вашем бэкэнде. Писатель создал 3 сообщения и начинает нажимать кнопку публикации для каждого из них. В основном ваша синхронизация файлов начнется после первой. Поэтому сначала нужно синхронизировать новую новость. Затем он должен обновить список последних новостей, а затем синхронизировать его.

Это может быть плохо, если они начнут редактировать достаточно хорошо. Потому что это тоже нужно сделать, например, при смене названия.

Решение для базы данных

Вот где база данных лучше, вы просто обновляете запись, и она туда попадает. Раздел последних новостей обновится, когда станет доступна новая запись.

Проблема со связанным статическим содержанием

Теперь у вас есть одна проблема: вы должны убедиться, что ваш процесс состоит из 2 этапов: 1. Синхронизация изображений и другого статического контента. 2. Синхронизация и / или публикация новости.

В противном случае вы увидите битые изображения. Это можно сделать, например, следующим образом: Убедитесь, что синхронизация нового изображения начинается напрямую. Итак, когда он загружен в CMS. Тогда он будет там до того, как новость будет опубликована. Вы можете проверить это в зависимости от ваших потребностей.

Альтернативы

Поскольку это статический контент, вы сможете обработать его немного лучше. Это потребует новой технологии в вашем стеке, поэтому сначала проверьте, действительно ли она нужна. Новость - это рабочий процесс. Итак, у него есть ступеньки рядом друг с другом. В общем, для рабочего процесса вы можете использовать очереди. Таким образом, вы создаете очередь с новыми новостями, очередь для публикации, очередь для синхронизации статических элементов и т. Д.

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