Category: дизайн

me

Про ZeroMQ

Спасено из тонущего поста ФБ.
https://www.facebook.com/oleg.i.tsarev/posts/10206505560627604

Участники: slonik_v_domene, lionet и zamotivator

Претензии к 0MQ:
- повторяя семантику BSD sockets не работает как BSD sockets;
- дескриптор 0mq нельзя передавать между потоками;
- оно глючит при/после коредампа или любого некорректного завершения одного из peer;
- криво построена работа в асинхронном режиме (все эти poll);
- течёт;
- по дизайну (!) не даёт делать прокси;
- по имплементации не рассчитано на слишком большое количество клиентов;
- по дизайну (!) не рассчитано на облака и доступ интернетных клиентов, только на fixed IP и всякий энтерпрайз подобный;
В общем, использовать это в продакшене = наживать лишний геморрой и седые волосы.

Отдельное замечание про паттерн REQ-REP:
Дело в том, что в 0mq REQ-REP принципиально нельзя работать иначе как вызывая read и write в четкой последовательности.

Отсюда проблема с ребутом: если процесс упал, есть 50% вероятности что данные не были записаны или прочитаны. После чего оно залипает и приходится гасить второй peer. Это все проходили в продакшене, проходили с большой кровью, что когда один компонент отваливался, надо было рестартить все остальные из-за того, что 0mq находилось не в том состоянии.

REQ-REP 0mq - ужасно неудобная вещь, пользовыаться ею как альтернативой BSD sockets нельзя.

В паттерне PUB-SUB этой проблемы уже нет. Но проблема в том, что когда ты все паттерны разберешь и поймешь, что тебе нужен только один, и он — самый сложный, самый нерекомендуемый докой на ømq, самый недодокументированный, и с самыми неочевидными преимуществами над обычными сокетами паттерн ROUTER-ROUTER.

Вообще, с 0mq работа выглядит примерно так: ты что-то делаешь, как правило - простые вещи. И они у тебя получаются быстро и просто.
Потом ты осознаешь что в проекте надо сделать каую-то простую и очевидную вещь, ну там между потоками передать дескриптор очереди.

И вот тут получается Drupal learning curve.