Для унификации обмена сообщениями между кластерами системы CSS-17 применяется обмен через интеграционную шину, которую обеспечивает кластер Bus.Обмен сообщениями осуществляется по протоколу AMQP версии 0-10. Со спецификациями протокола AMQP версии 0-10 можно ознакомиться по ссылке: http://www.amqp.org/sites/amqp.org/files/amqp0-10.zip.

Далее будут рассмотрены механизмы, которые используются в CSS-17 при взаимодействии через Bus.

AMQP является протоколом, ориентированным на передачу сообщений через очередь с поддержкой механизмов транзакционности и гарантии доставки.Брокером AMQP называется сервер, который выполняет функции приема, маршрутизации, хранения сообщения в очереди и доставки сообщения получателю.В AMQP различают клиента отправителя (Publisher) и клиента получателя (Consumer) сообщения.Точка обмена (Exchange) выполняет функции маршрутизации сообщения при получении его брокером от отправителя. Целью "exchange" является определение того, в какую очередь должно быть доставлено каждое сообщение на основании транспортных параметров сообщения.

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

Типовой процесс доставки сообщения по протоколу AMQP можно отобразить следующим образом:      

В процессе отправки сообщения отправитель устанавливает для сообщения различные параметры, которые влияют на процесс обработки и доставки сообщения.Ключевыми параметрами, которые используются в CSS-17, являются:

• exchange - точка обмена, которая должна использоваться для маршрутизации сообщения на брокере;
• routing.key - метка маршрутизации, которая используется при маршрутизации;
• reply_to.exchange - точка обмена, которая должна использоваться при отправке ответного сообщения;
• reply_to.routing_key - метка маршрутизации, которая должна использоваться при отправке ответного сообщения;
• time_to_live - время жизни сообщения.

Точка обмена (Exchange).

Протокол AMQP регламентирует несколько типов точек обмена, которые отличаются принципами маршрутизации поступающих в них сообщений.Поддерживаются следующие типа точек обмена:

• Direct exchange
• Fanout exchange
• Topic exchange
• Headers exchange

В системе CSS-17 используется Direct Exchange.

В Direct Exchange маршрутизация входящих сообщений осуществляется в очереди на основании значения параметра "routing key" сообщения. Этот тип точки обмена идеален для организации unicast-потоков обмена сообщениями (можно организовать и multicast обмен).Direct Exchange работает следующим образом:

• очередь Q связывается с точкой обмена с меткой маршрутизации routing.key=K;
• когда новое сообщение поступает с меткой маршрутизации routing.key=R, то точка обмена маршрутизирует это сообщение в очередь Q, если R=K.

Direct exhange часто используется в ситуациях, когда нужно распределять задачи между несколькими однотипными обработчиками в режиме распределения нагрузки (round robin).
Схематически работа Direct exhcnage:

Очередь (Queue).

Очереди в AMQP очень похожи на очереди в других системах доставки сообщений или обработки задач и представляют собой накопитель сообщений, работающий по принципу FIFO (First In First Out).Часть параметров очередь наследует от точки обмена, а также обладает следующими индивидуальными параметрами:

• Name - имя;
• Durable - определяет, сохраняются ли сообщения в очереди при рестарте брокера;
• Exclusive - используется только одной коннекцией (получателем) и очередь удаляется, если коннекция закрывается;
• Auto-delete - очередь удаляется, когда последний получатель отписывается от очереди.

Для того чтобы очередь можно было использовать её необходимо задекларировать (declare). Декларация очереди ведет к её созданию, если очереди с таким именем и тем же набором атрибутов не существует. Декларация очереди не происходит, если уже существует очередь с именно таким именем и набором атрибутов (очередь уже существует, декларация считается успешно выполненной). Если же происходит декларация очереди и определяется, что очередь с таким именем, но отличающимся набором параметров, уже существует - возвращается ошибка "PRECONDITIONS_FAILED".

AMQP 0-10 определяет следующие общие правила именования очередей:

• имя очереди может содержать от 1 до 255 символов;
• первый символ имеет следующие ограничения: буквы a-z или A-Z, цифры 0-9 и символ подчеркивания '_';
• второй и последующие символы могут быть любыми UTF-8 символами.

В системе CSS-17 применяются следующие дополнительные правила именования очередей:

• имя очереди состоит из набора смысловых частей;
• смысловые части разделяются символом точка ('.');
• имя заканчивается суффиксом 'q' (допускается использовать суффикс 'qe').

В настоящий момент используются следующие общие правила формирования имен очередей:

• core.cp.'core_cluster_name'.'number_of_call_process_group'.'number_of_call_process'.qe - очередь используется для отправки сообщений из кластера Adapter в кластер Core;
• css.pa.sip-t.'pa_sip_cluster_name'.init.q - очередь для приема инициирующих сообщений, поступающих в кластер адаптера SIP из кластера Core;
• css.pa.sip-t.'pa_sip_cluster_name'.'session_identifier'.q - очередь для приема сообщений кластером адаптера SIP из кластера Core в рамках вызова;
• css.pa.megaco.'pa_megaco_cluster_name'::'gateway_name'.init.q - очередь для приема инициирующих сообщений, поступающих в кластер адаптера Megaco из кластера Core;
• css.pa.megaco.'pa_megaco_cluster_name'::'gateway_name'.'session_identifier'.q - очередь для приема сообщений, поступающих в кластер адаптера Megaco из кластера Core в рамках вызова;
• tring_client'client_version'....q - очереди подсистемы контроля целостности tring системы CSS-17;
• ccn....q - очереди подсистемы распределенной командной консоли CoCon системы CSS-17;
• css.cm.... - очереди подсистемы синхронизации конфигурации Configuration Manager системы CSS-17;
• css.rps....q - очереди подсистемы обмена событиями, нотификациями, авариями RPS системы CSS-17;
• dds.bus....q - очереди распределенной подсистемы доступа к хранилищу конфигурационной информации DDS кластера DS системы CSS-17;
• mycelium.mgmt.... - очереди, используемые брокером для синхронизации в кластере Bus.

Правила связывания (Bindings).

Bindings - это правила связывания/маршрутизации, которые используются в точке обмена для маршрутизации сообщений в очереди.Для того чтобы точка обмена E могла направлять сообщения в очередь Q необходимо, чтобы Q была связана с E.Правило связывания может иметь дополнительный "routing key" атрибут, который используется в некоторых типах точек обмена.Назначение "routing key" в том, чтобы выбрать определенные сообщения, размещенные в "exchange", и направить их в соответствующую очередь. Таким образом, "routing key" работает как фильтр.

Если сообщение не может быть смаршрутизировано в точке обмена (например, нет соответствующего правила связывания), то оно отбрасывается либо возвращается отправителю (зависит от настроек атрибутов сообщения).

Получатели (Consumers).

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

Процесс доставки сообщения получателю.

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

Спецификации протокола AMQP определяют 2 возможных алгоритма доставки сообщения:

• basic.delivery/basic.get - в данном режиме сообщение удаляется из очереди сразу после отправки получателю;
• использование механизма basic.ack - в данном режиме функционирует надежная доставка. Сообщение удаляется, когда брокер получил подтверждение об успешной обработке сообщения получателем.

Первый вариант доставки сообщения называется режимом "автоматического подтверждения". Второй вариант можно назвать режимом "явного подтверждения". Особенностью второго варианта является то, что получатель может подтвердить доставку сообщения как сразу после получения сообщения, так и через какое-то время, после выполнения заложенной в нем бизнес-логики (например, после завершения транзакции по записи изменений в базу данных).

Если процесс получателя падает (падает коннекция к брокеру) либо истекает таймер ожидания подтверждения, брокер производит повторную доставку сообщения другому получателю. Если других получателей нет, то брокер будет ожидать появления получателя для последующей доставки ему сообщения.

В процессе обработки сообщения получателем может сложиться ситуация когда получатель не может обработать сообщение (некорректная информация, какая-то ошибка в логике, недоступность подсистем и т.п.). Получатель может просигнализировать брокеру об ошибке обработки сообщения путем отправки ему сообщения "reject". В процессе отправки "reject" получатель может сигнализировать брокеру о том, что сообщение должно быть сброшено либо предоставлено другому получателю (зависит от прикладной логики и характера ошибки).

Механизм управления потоком сообщений к получателю.

В AMQP введен очень полезный механизм ограничения количества сообщений, которые брокер отправляет одному получателю. Обычно такие механизмы называются "flow control" (механизм управления потоком сообщений).

Механизм управления потоком AMQP позволяет ограничивать поток информации, отправляемой брокером получателю по:

• количеству переданной информации (потолок в байтах);
• количеству переданных сообщений.

В системе CSS-17 этот механизм используется практически во всех кластерах и служит способом ограничения входящей нагрузки на процессы обрабатывающие сообщения.