Шаг 5. Синхронизация данных в доменах между сайтами
Доменный центр, располагающийся на мастер-сайте, работает в роли MDC (Master Domain Center) и имеет прямое соединение с DomainDB – рассмотрено на шаге 1. Доменный центр, располагающийся на любом другом сайте, работает в роли SDC (Site Domain Center) и кэширует данные в локальной объектной БД. Роль MDC хранит данные обо всех доменах всей системы и их сущностях, даже если домен не обслуживается на сайте в соответствии с файлом конфигурации. Роль SDC кэширует данные только по тем доменам, что обслуживаются на её сайте в соответствии с конфигурационным файлом. Тем не менее SDC владеет полным деревом доменов, и получая запросы к необслуживаемым доменам проксирует их на обслуживающие их сайты (связь SDC – SDC или SDC – MDC).
Мастер-домен полноценно обслуживается только на мастер-сайте (в роли MDC). Обслуживание запросов к мастер-домену в SDC отличается от обслуживания запросов к другим необслуживаемым на сайте доменам – часть запросов также проксируется (на MDC), а часть обрабатывается локально. Соответственно часть настроек и сущностей мастер-домена кэшируется в SDC для нужд обособленной работы сайта без связи с мастер-сайтом.
Поскольку для всех остальных частей системы важен именно функционал доменного центра и безразлична разница между MDC и SDC, то принято говорить о роли DC в тех контекстах, где разница между ними не имеет значения.
MDC на мастер-сайте посредством DomainDB является резервным хранилищем всех настроек и сущностей домена. В любой момент можно добавить в конфигурацию еще один сайт, привязать к нему доменные зоны, и SDC на нем загрузит в свое хранилище все связанные сущности путем синхронизации с MDC.
Наличие обособленной DomainDB гарантирует возможность полной переустановки системы с сохранением всех доменных настроек и сущностей.
Синхронизация данных SDC – MDC
Всякий раз, когда модифицирующие CRUD-операции над сущностями домена выполняются на обслуживающем домен рабочем сайте, данные сначала попадают в SDC, и затем в случае удачи отправляются на MDC, откуда попадают в БД домена.
Кейс: администратор выполняет модифицирующие CRUD-запросы, подключившись к WS мастер-сайта, в то время как домен обслуживается на рабочем сайте.
Для этого есть процесс синхронизации, инициируемый каждым SDC. Как раз в этом процессе в начале и происходит отправка накопленных неисполненных изменений на MDC, и только вслед за этим производится полная синхронизация SDC и MDC, где MDC выступает источником информации. Раз в 20 секунд на каждом сайте производится процедура синхронизации между SDC и MDC.
Следствие: администратор модифицирует сущность через WS рабочего сайта, SDC принимает изменения и отправляет на MDC, а тот отказывает. В этом случае администратор видит, что сущность изменилась, а через 20 секунд изменения откатились, ведь MDC выступил источником информации при синхронизации, и там этих изменений нет.
Коммуникация SDC – SDC
SDC непосредственно коммуницируют между собой только в рамках проксирования запросов с одного сайта, где домен не обслуживается, на другой, где домен обслуживается. Это вырожденная коммуникация.
Многосайтовое обслуживание домена
Кейс: Администратор применяет конфигурацию, в которой домен назначается на обслуживание двум сайтам. Через некоторое время оба сайта работают полноценно и целостно.
Домен может обслуживаться на нескольких рабочих сайтах. За такую настройку отвечает файл конфигурации (шаг 1). Различные роли проявляют в связи с многосайтовым обслуживанием домена различные шаблоны поведения. Рассмотрим как ведет себя в этой ситуации SDC. Оказывается, все уже рассмотрено – его поведение является следствием его процесса синхронизации с MDC. Всякий раз когда на одном из сайтов в SDC изменяется какая-то сущность, сначала это изменение попадает на MDC, а затем оттуда синхронизируется на другие SDC (см.рис.). При этом конфликты решаются также посредством MDC и его транзактности: создание элемента с одним идентификатором с разных сайтов – остается тот кто первым добежал до MDC, при изменении одного объекта – остается тот кто последним добежал до MDC, удаление безразлично к последовательности, но имеет приоритет перед модификацией сущности при любом порядке операций. Очевидно, что бесконечного цикла синхронизации нескольких сайтов получить невозможно. Стоит иметь в виду, что синхронизация сущностей доменов между двумя сайтами происходит интервалами в 20 секунд. То есть в основном сайты будут синхронизироваться в пределах 20 секунд. В некоторых редких случаях время синхронизации может увеличиваться в несколько раз.
Кейс: администратор применяет конфигурацию, в которой доменная зона с тремя уровнями доменов привязывается к новому сайту. За каждый интервал 20 секунд будет синхронизироваться один уровень доменов перемещенной зоны – сначала синхронизируется первый уровень доменов, среди его сущностей есть дочерние домены и они активируются, через 20 секунд они синхронизируются и передадут эстафету доменам 3 уровня зоны.
Рабочий сайт без связи с другими
Кейс: администратор производит модифицирующий CRUD-запрос на WS рабочего сайта в условиях, когда MDC недоступен (возможно нет связи с мастер-сайтом, либо что-то еще).
В этом случае для администратора все выглядит так же как и на шаге 1. А внутри изменения применяются к текущему сайту, и сохраняются в очереди на отправку. SDC производит периодические попытки их отправить ровно в той последовательности, в которой они применялись. На размер этой очереди установлен лимит в 10000 модифицирующих CRUD-запросов для каждого сайта, после чего SDC начинает отказывать в их исполнении.
Кейс: два администратора на двух сайтах меняют одну и ту же сущность в условиях, когда одному сайту не доступен мастер-сайт.
В качестве проверочного упражнения попробуйте самостоятельно описать этапы процесса вплоть до завершения синхронизации и выяснить состояния изменяемой сущности на этих сайтах на каждом этапе.
Термин | Определение |
---|---|
|
! |
|
! |
|
! |
|
! |
|
! |
|
! |
-
Следующий шаг: Шаг 6. Обеспечение доступности
-
Предыдущий шаг: Шаг 4. Изменение конфигурации