Rattler: VAS developer (SMS, MMS, WAP, WEB, USSD, IVR, VoIP)

Продолжаем ликбез по Kannel ;-)

Наиболее распространенный способ обращения Kannel к бизнес-логике конкретного сервиса - отправка HTTP-запроса. Простой и понятный API позволяет создавать сервисы даже начинающим программистам. В моей личной практике встречались приложения в 2-3 строки, из которых первая была shebang'ом, но речь пойдет о повышении надежности и сглаживании нагрузки.

Ситуация 1: недоступность сервиса в момент запроса

Причины могут быть очень разные - ненадежная сеть, чрезмерная нагрузка, регламентные работы на сервере (абонентам по барабану), да и просто кривые руки разработчиков.

По умолчанию, Kannel после неудачной попытки просто отправит абоненту ответное сообщение о недоступности сервиса. Но можно сделать следующие изменения в конфигурации (группа smsbox):

http-request-retry = 5
http-queue-delay = 60

Первая строка означает, что нужно сделать 5 попыток доставки, а уж потом признать сервис помершим. Вторая строка задает периодичность повторных попыток (60 секунд). Так что теперь наш сервис может пролежать пару минут, не пугая пользователя.

Ситуация 2: тяжелая бизнес-логика и ограничение нагрузки

Допустим, нашему SMS-сервису необходимо для выдачи результата произвести большое количество вычислительной работы или перелопатить террабайты данных. При этом, нагрузка у нас неравномерная, а пропускная способность на SMSC выдана с хорошим запасом. Во многих случаях это светит лавинообразным ростом нагрузки, т.к. запросы могут поступать быстрее, чем их получается обработать, из-за чего плодятся обработчики, пока машинка не сдохнет.

Чтобы такого не происходило, в той же группе smsbox нужно добавить примерно такую строчку:

max-pending-requests = 10

Теперь одновременно Kannel будет отправлять не более 10 HTTP запросов, содержащих MO SMS или DLR. Для справки: ограничение по умолчанию составляет 512 одновременных запросов.