Сергей Соколов

Репликация MySQL вполне вписывается в описанный сценарий, за исключением несовпадения структуры таблиц из-за разности версий: все копии БД должны быть идентичны. Асинхронность ОК.

Придется только озадачиться обработкой восстановления синхронизации после серьезных сбоев на дочерних узлах: выкачивать копию с центрального (master), полностью заменять ей бд в дочке (slave), перезапускать slave.

И важный момент — локальные изменения должны писаться сразу на центральный сервер, локальный – read only.

Подобная схема реализуется например для WordPress с помощью HyperDB.

Мне помогли эти две ссылки (обе на англ.)
1. Урок по Командам
2. Документация по Командам

У меня напр. так работает закрытие отдельного файла:

location ~/some_folder/secret.php$ {
  auth_basic            "Secret area";
  auth_basic_user_file  /home/users/.htpasswd;
  location ~* \.php {
    include /etc/nginx/fastcgi.conf;
    fastcgi_intercept_errors on;
    fastcgi_index  index.php;
    fastcgi_pass php;
  }
}

Только «события»: старт, стоп, ручной пуск нового оъявления, пополнение счёта — всё, что изменяет прогноз по деньгам, запускает событие, по которому обновляется дата-время окончания денег на счете, по которой сервер выключит показ.

На крон возлагается единственная задача: найти по всем счетам, кого пора отрубить.

Включение, из состояния «выкл.», возможно только по событию пополнения счёта.

Коммерческие системы защиты PHP кода:

• ionCube от $199
• Zen Guard $600