AMQP в кластере

Вскоре после разворачивания AMQP сервера на выходных благополучно зависла виртуальная машина в которой жил RabbitMQ и… Было невесело и стало ясно, что пора воспользоваться кластером RabbitMQ.

Если вкратце, то кластер работает так: есть ноды, реплицирующие данные, есть memory-only ноды, на которых ничего не хранится. Клиент может подключиться к любой, но может получить редирект на другую ноду. Клиент должен уметь это отрабатывать, мне пришлось дописывать реализацию самому. При падении текущей ноды клиент должен сам переподключиться дальше. Если ему повезло, то он даже может сохранить auto_delete очереди, если успеет их законсумить. Однако я это не советую и лучше повторить процедуру подключения заново.

Итак, настройка кластера.

баг в ExternalInterface

Мне потребовалось через RTMP рассылать данные в формате JSON по флешкам.
После прихода во флеш данные отправляются сразу в ExternalInterface.call:

ExternalInterface.call("juggernaut.receiveData", event.info.description);

В какой-то момент у меня начали валиться ошибки «в нигде» и «из
ниоткуда», которые
были видны только в Firebug-е. До receiveData дело не дошло.
Текст ошибки:

missing ) after argument list

AMQP — практика использования

Увидев вводный пост про AMQP решил поделиться своей практикой использования этого механизма.

Ещё задолго до начала внедрения AMQP у нас был полный зоопарк из различных обработчиков фоновых задач: delayed_job , starling + workling и т.п. Плюс к этому, ещё активно использовался HTTP ping между серверами и juggernaut для пуш-канала на браузер. Ах, ещё забыл брутальное оповещение по IP multicast.

Весь этот перечень страшных слов работает, но уж очень он разнообразен и обширен, решили урезать. Чего же общего между HTTP ping-ом и старлингом? Да то, что это всё сообщения от источника к подписчикам. AMPQ был выбран как общий транспорт для таких сообщений.

DSL и контексты

Человеческие языки (насколько я это всё понимаю) бывают более или менее контекстно-зависимые. Например, русское слово «смеркается», вырванное из контекста скорее всего будет значить тоже самое, что и в самом контексте. Это удобно тем, что всегда можно его однозначно перевести просто по таблице перевода, а человеку надо меньше напрягать мозг, что бы понять что оно значит. Зато это слово писателю сложнее подогнать под свои нужды и выразить с его помощью что-то новое. Английское слово “do” наоборот: само по себе мало чего значит, зато его можно использовать в окружении других слов в разнообразнейших случаях. Минус понятен: что бы понять, что оно тут значит, надо держать кучу слов в памяти, что создает сильное когнитивное сопротивление.

Если перевести всё сказанное на программирование, то получается что:

• менее контекстно-зависимые языки хуже расширяются новыми инструкциями, но проще для понимания и поиска по документации;
• более контекстно-зависимые языки лучше расширяются, но тяжелее для понимания.

Язык конфигурации postfix-а — первый вариант. Assembler — это чуть ли не предел контекстной зависимости. Хорошо бы держать всю память приложения в голове, когда на нем пишешь. Однако вполне понятно, что написать почтовый сервер на ассемблере безумно сложно, но теоретически возможно, а вот на языке конфигурации postfix-а — увы, никак.

Как мы лукэтми разгоняли

В связи со сменой верстки на лукэтми (отказались от единой помойки в /stylesheets, /images, /javascripts и решили разнести всю верстку и картинки на раздельные каталоги), получилась такая проблема, что надо при отдаче CSS cервером, парсить его: ослик не умеет всасывать больше 32 стилевых файлов.

Продолжение про БД

  
1
2
3
4
5
6
7

  

SELECT articles.title, group_concat(tags.name, ', ') AS tag_list 
   FROM articles 
   LEFT JOIN taggings ON (taggings.taggable_id = articles.id AND 
                          taggings.taggable_type = 'Article') 
   INNER JOIN tags ON (taggings.tag_id = tags.id) 
   GROUP BY articles.title;