Комментарии 36
Интересно сравнение производительности с раббитом
читаю я и вижу подробное описание AMQP
кстати о бинарном протоколе, AMQP бинарный, и это нормальная практика использовать бинарные протоколы
почему бы не привязаться к существующему уже проверенному протоколу?
кстати о бинарном протоколе, AMQP бинарный, и это нормальная практика использовать бинарные протоколы
почему бы не привязаться к существующему уже проверенному протоколу?
На самом деле есть и множество отличий от AMQP.
Реализовывать заново AMQP не имеет большого смысла т.к. уже есть RabbitMQ например.
К тому же я собираюсь добавлять функциональность которой нет в AMQP (не хочу ограничиваться протоколом).
Реализовывать заново AMQP не имеет большого смысла т.к. уже есть RabbitMQ например.
К тому же я собираюсь добавлять функциональность которой нет в AMQP (не хочу ограничиваться протоколом).
желательно поподробнее об отличиях
можно разработать протокол, на базе уже существующего, т.е. сделаль кастомное расширение протокола
например, мы, при реализации своего стороджа, использовали составной ключ, первая часть которого указывала на номер банка хранения, а последняя на операцию доступа (прямой доступ или доступ по индексу/номеру)
тоже самое можно придумать и в твоем случае. Все Базовые операции соответствуют AMQP
Всем новым операциям можно присвоить новый код операции.
В случае Расширение базовой операции, можно присвоить новый неиспользуемый код.
следующий шаг — это дописываешь amqp сишный клиент и дело в шляпе
На сколько я помню исходники, то часть сишного клиента вообще генерится из JSON описания.
Тут вообще ничего писать не надо, поправляешь файл спецификации JSON и все в шоколаде ;)
например, мы, при реализации своего стороджа, использовали составной ключ, первая часть которого указывала на номер банка хранения, а последняя на операцию доступа (прямой доступ или доступ по индексу/номеру)
тоже самое можно придумать и в твоем случае. Все Базовые операции соответствуют AMQP
Всем новым операциям можно присвоить новый код операции.
В случае Расширение базовой операции, можно присвоить новый неиспользуемый код.
следующий шаг — это дописываешь amqp сишный клиент и дело в шляпе
На сколько я помню исходники, то часть сишного клиента вообще генерится из JSON описания.
Тут вообще ничего писать не надо, поправляешь файл спецификации JSON и все в шоколаде ;)
Мне не нравится AMQP. Считаю его излишне запутанным для выполения довольно простых задач.
Но это моё личное мнение. Я на самом деле нигде его не использовал.
Но это моё личное мнение. Я на самом деле нигде его не использовал.
Использование существующих протоколов имеет свои плюсы и не маленькие:
Вы сможете привлечь больше пользователей к своему сервису, так как под существующие протоколы, например AMQP, реализованы клиенты OpenSource практически на всех языках.
Так например я реализовал свой NoSQL сторадж, который общался по memcached протоколу, не надо было изобретать велосипедов для клиентов, подходят уже существующие.
Тем же путем пошли создатели TokyoTyrant, который поддерживает три протокола: HTTP, memcached и свой бинарный, или Tarantool, который поддерживает протоколы: свой бинарный и memcached.
Принципиально — Вы молодец, я сам хотел реализовать что-то подобное ;)
на досуге обязательно посмотрю ваши наработки
Вы сможете привлечь больше пользователей к своему сервису, так как под существующие протоколы, например AMQP, реализованы клиенты OpenSource практически на всех языках.
Так например я реализовал свой NoSQL сторадж, который общался по memcached протоколу, не надо было изобретать велосипедов для клиентов, подходят уже существующие.
Тем же путем пошли создатели TokyoTyrant, который поддерживает три протокола: HTTP, memcached и свой бинарный, или Tarantool, который поддерживает протоколы: свой бинарный и memcached.
Принципиально — Вы молодец, я сам хотел реализовать что-то подобное ;)
на досуге обязательно посмотрю ваши наработки
что хотелось бы принципиально увидеть в следующих публикациях:
— что побудило создать еще один велосипед
— сравнение с существующими серверами очередей, преимущества и недостатки
— где и как применяется
— планы
Вопросы:
— масштабируемость, консистентность
— администрирование, персистентность
что случается с данными во время падения?
— что побудило создать еще один велосипед
— сравнение с существующими серверами очередей, преимущества и недостатки
— где и как применяется
— планы
Вопросы:
— масштабируемость, консистентность
— администрирование, персистентность
что случается с данными во время падения?
и естественно интересует автоподъем
Про персистентность могу ответить сразу.
Все данные сбрасываются на диск по заданному интервалу (асинхронно, через fork) и если сервер упадет то загрузится с данными последнего сохранения. Это пока единственный механизм сохранения данных.
За автоподъем ответственность можно переложить на специальные утилиты. Сам по себе сервер не запустится.
Все данные сбрасываются на диск по заданному интервалу (асинхронно, через fork) и если сервер упадет то загрузится с данными последнего сохранения. Это пока единственный механизм сохранения данных.
За автоподъем ответственность можно переложить на специальные утилиты. Сам по себе сервер не запустится.
сервер имеет один процесс или архитектура master-child?
у меня реализовано master-child, мастер переподнимает дочку.
у меня реализовано master-child, мастер переподнимает дочку.
данные сохраняются в каком-то определенном формате?
интервал перезаписи не изменяется по интенсивности загрузки, например по принципу, если в сервер ничего не пишем — зачем ему сохраняться?
интервал перезаписи не изменяется по интенсивности загрузки, например по принципу, если в сервер ничего не пишем — зачем ему сохраняться?
что интересует, полезу в исходники позже…
— используемые либы
— какая используется сетевая модель
— какая модель хранения данных, очередей
— какая используется модель сохранения данных
да и самый интересный вопрос и почему все жн Орел?
— используемые либы
— какая используется сетевая модель
— какая модель хранения данных, очередей
— какая используется модель сохранения данных
да и самый интересный вопрос и почему все жн Орел?
а как вы рассчитываете дефрагментацию занятого пространства?
1) Зависимостей особых нет. Можно собрать с jemalloc или tcmalloc. Но это опционально.
2) Сетевая подсистема почти полностью взята из Redis. Есть поддержка epoll/select механизмов.
3) Сохранения данных происходит в файл. Для сохранения используется собственный бинарный формат.
Почему EagleMQ я точно сам не знаю. Орёл быстрая птица, EagleMQ тоже :)
2) Сетевая подсистема почти полностью взята из Redis. Есть поддержка epoll/select механизмов.
3) Сохранения данных происходит в файл. Для сохранения используется собственный бинарный формат.
Почему EagleMQ я точно сам не знаю. Орёл быстрая птица, EagleMQ тоже :)
> команда stats
>Queues — number of queues
желательно еще кол-во сообщений в очереди, или я что-то недопонял и очередь одна и это цифра является кол-во сообщений в очереди?
>.flush(flags)
желательно добавить функционал «Почистить очередь»
>Queues — number of queues
желательно еще кол-во сообщений в очереди, или я что-то недопонял и очередь одна и это цифра является кол-во сообщений в очереди?
>.flush(flags)
желательно добавить функционал «Почистить очередь»
1) Есть команда .queue_list которая отдает список всех очередей со статистикой:
name — queue name
max_msg — maximum number of messages
max_msg_size — maximum message size
flags — flags that created queue
size — the number of messages in the queue
declared clients — the number of clients which declare queue
subscribed clients — the number of clients subscribed to queue
Также есть аналогичные команды: .user_list, .route_list, .channel_list
В будущем планирую добавить команды: .user_info, .queue_info,… для получении информации о каждом примитиве по названию.
2) Есть команда .queue_purge которая очищает очередь.
Кстати, есть документация на русском: GitHub
name — queue name
max_msg — maximum number of messages
max_msg_size — maximum message size
flags — flags that created queue
size — the number of messages in the queue
declared clients — the number of clients which declare queue
subscribed clients — the number of clients subscribed to queue
Также есть аналогичные команды: .user_list, .route_list, .channel_list
В будущем планирую добавить команды: .user_info, .queue_info,… для получении информации о каждом примитиве по названию.
2) Есть команда .queue_purge которая очищает очередь.
Кстати, есть документация на русском: GitHub
Удачи Вам в этом начинании!
Интересуют два вопроса: совместимость с OpenStack и масштабируемость (10, 100 узлов)
Интересуют два вопроса: совместимость с OpenStack и масштабируемость (10, 100 узлов)
1. Можно ли более наглядно объяснить разницу между примитивами: какой когда используется; или табличку сравнительную.
2. Существует ли в природе где-либо сравнительная табличка разных реализацией менеджера очередей?
Спасибо.
2. Существует ли в природе где-либо сравнительная табличка разных реализацией менеджера очередей?
Спасибо.
ответ по вопросу 2. я искал не нашел. ZMQ производительней кролика, делали замер, но кролик проще в эксплуатации и может масштабироваться.
В качестве сервера очередей, если не нужно использовать хитрый роутинг, так же можно использовать memcacheQ и redis. По производительности они где-то на одном уровне. Есть еще параметр — объем занимаемой памяти, но я его не мерил. я в качестве сервера очередей использую tarantool. Но моя задача простая — всего одна очередь. Используется тарантул потому, что он задействован в других частях проекта, в частности, как кешер данных.
В качестве сервера очередей, если не нужно использовать хитрый роутинг, так же можно использовать memcacheQ и redis. По производительности они где-то на одном уровне. Есть еще параметр — объем занимаемой памяти, но я его не мерил. я в качестве сервера очередей использую tarantool. Но моя задача простая — всего одна очередь. Используется тарантул потому, что он задействован в других частях проекта, в частности, как кешер данных.
Ответ по вопросу 1 можно найти тут:
habrahabr.ru/post/64192/
habrahabr.ru/post/149694/
habrahabr.ru/post/150134/
habrahabr.ru/post/44907/
habrahabr.ru/post/64192/
habrahabr.ru/post/149694/
habrahabr.ru/post/150134/
habrahabr.ru/post/44907/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Введение в EagleMQ