Erlang Killer Apps В Эрланг среде принятно считать, что RabbitMQ и Riak, или по крайней мере riak_core — являются киллер приложениями Erlang. Я сам помню на начале своей карьеры тоже поставил на эти продукты и еще на Nitrogen. С нитрогеном я разобрался быстро (он уже история — все используют N2O уже давно). Настала очередь Riak или RabbitMQ, не знал за что взяться. Взялся сразу за распределенную базу, но так быстро на распределенные алгоритмы не наскочишь, а тестами покрывать распределенные системы — это не в этой жизни, может в следующей, если плохо себя вести буду. Вообщем исследование Chain Replication завело меня в тупик зависимых типов и я начал пить™. Расскажу какие мысли у меня были во-первых по Riak. Riak после всего что я видел до него поверг меня в шок стоимостью обслуживания продакшина. Я с легкостью строил кластера пока не понял что они мне совершенно не нужны. Из riak нужно реально только riak_kv, riak_core и riak_pipe. Причем я даже собирал Riak без bitcask полностью (он вшитый в ядро) и многие другие штуки делал типа порт Riak под Windows 8. Собственно KVS появился как штука чтобы не ебаться с голым riak. В Riak вы храните бинари, а в KVS типы-рекорды описаные в схемах. Это потом в KVS появились бекенды. Паралельно у меня был кластер из трех RabbitMQ. Тогда уже я понял что производительность RabbitMQ высокая только если они работают в шардах (не кластер, потому что интерконнет хуйовый у эрланга). Т.е. реально RabbitMQ используют все просто как ETS с красивым дашбордом для админов. Забейте хуй на RabbitMQ, эта штука покрыта кольцами как и Riak. Счас есть гораздо емкостные MQ типа emqtt.io (gproc в качестве деливери, mnesia — для дюрабилити), тоже причем с красивыми дашбордами. У меня кстати есть заказ от Остинелли на порт emqtt.io с gproc на syn. Но я не об этом. Спросите себя почему MQ и KV сервера в вашем окружении (а они у вас все равно есть, какое бы вы приложение не писали) находятся в разных приложениях. Ведь в вашем приложении MQ обслуживает клиентов, и KV обслуживает клиентов. Поэтому тут работатет data locality, а значит можно посадить это на одни и теже воркеры vnode. Но почему у всех ПОГОЛОВНО MQ и KV сервера — это разные продукты? Почему так? Ответа не нашел. Продуктов нет (разве что redis). Поэтому я подумал написать (еще два года назад) MQ + KV сервер работающий на одном ядре. И ядро это KVS. KVS отвечает за durability, MQ должен хранить сабскрипшин меш своих подписок а также все сообщения (если очередь скажем персистента или нужны ACK или нужна транзакционность). Вполне очевидно что это можно хранить в том же KVS. Уверен что все люди которые используют RabbitMQ (илии другие MQ продукты) дублируют и синхронизируют свой сабскрипшин меш приложения и состояние подписок в mnesia таблицах RabbitMQ. Нахуя? Незнаю, в моем MQ такого дублирования не будет. Какие я могу обеспечить показатели MQ сервера на KVS: 1) ну я могу выжать из мнезии 40K RPS на данных которые помещаются в RAM, и 20K RPS на данных которые не ограничиваются ничем. async_dirty естественно. 2) Data Locality. И серверы очередей и серверы данных будут обслуживать на одних и тех же vnode (по 64 или 128 на ноду), т.е. вычислятся хешом по идентификатору пользователя, а значит исчезает необходимость в синхронизации, так как все сообщения от MQ и KV протокола будут помещены в одну и туже очередь пользователя (линеаризация во имя консистентности). 3) Благодаря KVS, и MQ сервер и KV сервер будут поддерживать все бекенды которые поддерживает KVS: mongoDB, SQL, Riak, mnesia, redis. 4) доступ к очередям можно получать напрямую читая их из базы, если нужно. Еще был план написать универсальный REST эндпойнт к KVS как в Riak и CouchDB, и чтобы этот же эндпойнт был API для MQ сервера. Ну и этот конструктор не имеет ограничений. На KVS можно лепить уже более сложные API и системы. Пример CR хоть и заезженный, но рабочий. Вообщем надо соединять MQ и KV сервера, мое мнение, а вы делайте как хотите :-)