Поздравляю,
не удевлен, так как ожидал именно их победу! И это уже не первый раз!!!
Мы (Россияне и Сакт-Петербуржцы) — Лучшие в мире!
Буду готовить сына к поступлению в ИТМО!
ответ по вопросу 2. я искал не нашел. ZMQ производительней кролика, делали замер, но кролик проще в эксплуатации и может масштабироваться.
В качестве сервера очередей, если не нужно использовать хитрый роутинг, так же можно использовать memcacheQ и redis. По производительности они где-то на одном уровне. Есть еще параметр — объем занимаемой памяти, но я его не мерил. я в качестве сервера очередей использую tarantool. Но моя задача простая — всего одна очередь. Используется тарантул потому, что он задействован в других частях проекта, в частности, как кешер данных.
данные сохраняются в каком-то определенном формате?
интервал перезаписи не изменяется по интенсивности загрузки, например по принципу, если в сервер ничего не пишем — зачем ему сохраняться?
можно разработать протокол, на базе уже существующего, т.е. сделаль кастомное расширение протокола
например, мы, при реализации своего стороджа, использовали составной ключ, первая часть которого указывала на номер банка хранения, а последняя на операцию доступа (прямой доступ или доступ по индексу/номеру)
тоже самое можно придумать и в твоем случае. Все Базовые операции соответствуют AMQP
Всем новым операциям можно присвоить новый код операции.
В случае Расширение базовой операции, можно присвоить новый неиспользуемый код.
следующий шаг — это дописываешь amqp сишный клиент и дело в шляпе
На сколько я помню исходники, то часть сишного клиента вообще генерится из JSON описания.
Тут вообще ничего писать не надо, поправляешь файл спецификации JSON и все в шоколаде ;)
> команда stats
>Queues — number of queues
желательно еще кол-во сообщений в очереди, или я что-то недопонял и очередь одна и это цифра является кол-во сообщений в очереди?
что интересует, полезу в исходники позже…
— используемые либы
— какая используется сетевая модель
— какая модель хранения данных, очередей
— какая используется модель сохранения данных
да и самый интересный вопрос и почему все жн Орел?
что хотелось бы принципиально увидеть в следующих публикациях:
— что побудило создать еще один велосипед
— сравнение с существующими серверами очередей, преимущества и недостатки
— где и как применяется
— планы
Вопросы:
— масштабируемость, консистентность
— администрирование, персистентность
что случается с данными во время падения?
Использование существующих протоколов имеет свои плюсы и не маленькие:
Вы сможете привлечь больше пользователей к своему сервису, так как под существующие протоколы, например AMQP, реализованы клиенты OpenSource практически на всех языках.
Так например я реализовал свой NoSQL сторадж, который общался по memcached протоколу, не надо было изобретать велосипедов для клиентов, подходят уже существующие.
Тем же путем пошли создатели TokyoTyrant, который поддерживает три протокола: HTTP, memcached и свой бинарный, или Tarantool, который поддерживает протоколы: свой бинарный и memcached.
Принципиально — Вы молодец, я сам хотел реализовать что-то подобное ;)
на досуге обязательно посмотрю ваши наработки
читаю я и вижу подробное описание AMQP
кстати о бинарном протоколе, AMQP бинарный, и это нормальная практика использовать бинарные протоколы
почему бы не привязаться к существующему уже проверенному протоколу?
У автора есть несколько статей по данной тематике: 1, 2.1, 2.2, 3. Четвёртая статья видимо так и не увидит свет ввиду публикации автором книги «Extending and Embedding PHP», посвящённой данной тематике.
очевидно с выходим книги убрали статьи 1, 2.1, 2.2, 3 ;(
не удевлен, так как ожидал именно их победу! И это уже не первый раз!!!
Мы (Россияне и Сакт-Петербуржцы) — Лучшие в мире!
Буду готовить сына к поступлению в ИТМО!
habrahabr.ru/post/64192/
habrahabr.ru/post/149694/
habrahabr.ru/post/150134/
habrahabr.ru/post/44907/
В качестве сервера очередей, если не нужно использовать хитрый роутинг, так же можно использовать memcacheQ и redis. По производительности они где-то на одном уровне. Есть еще параметр — объем занимаемой памяти, но я его не мерил. я в качестве сервера очередей использую tarantool. Но моя задача простая — всего одна очередь. Используется тарантул потому, что он задействован в других частях проекта, в частности, как кешер данных.
интервал перезаписи не изменяется по интенсивности загрузки, например по принципу, если в сервер ничего не пишем — зачем ему сохраняться?
у меня реализовано master-child, мастер переподнимает дочку.
я писал С++ обертку для сишного клиента
например, мы, при реализации своего стороджа, использовали составной ключ, первая часть которого указывала на номер банка хранения, а последняя на операцию доступа (прямой доступ или доступ по индексу/номеру)
тоже самое можно придумать и в твоем случае. Все Базовые операции соответствуют AMQP
Всем новым операциям можно присвоить новый код операции.
В случае Расширение базовой операции, можно присвоить новый неиспользуемый код.
следующий шаг — это дописываешь amqp сишный клиент и дело в шляпе
На сколько я помню исходники, то часть сишного клиента вообще генерится из JSON описания.
Тут вообще ничего писать не надо, поправляешь файл спецификации JSON и все в шоколаде ;)
>Queues — number of queues
желательно еще кол-во сообщений в очереди, или я что-то недопонял и очередь одна и это цифра является кол-во сообщений в очереди?
>.flush(flags)
желательно добавить функционал «Почистить очередь»
— используемые либы
— какая используется сетевая модель
— какая модель хранения данных, очередей
— какая используется модель сохранения данных
да и самый интересный вопрос и почему все жн Орел?
— что побудило создать еще один велосипед
— сравнение с существующими серверами очередей, преимущества и недостатки
— где и как применяется
— планы
Вопросы:
— масштабируемость, консистентность
— администрирование, персистентность
что случается с данными во время падения?
Вы сможете привлечь больше пользователей к своему сервису, так как под существующие протоколы, например AMQP, реализованы клиенты OpenSource практически на всех языках.
Так например я реализовал свой NoSQL сторадж, который общался по memcached протоколу, не надо было изобретать велосипедов для клиентов, подходят уже существующие.
Тем же путем пошли создатели TokyoTyrant, который поддерживает три протокола: HTTP, memcached и свой бинарный, или Tarantool, который поддерживает протоколы: свой бинарный и memcached.
Принципиально — Вы молодец, я сам хотел реализовать что-то подобное ;)
на досуге обязательно посмотрю ваши наработки
кстати о бинарном протоколе, AMQP бинарный, и это нормальная практика использовать бинарные протоколы
почему бы не привязаться к существующему уже проверенному протоколу?
очевидно с выходим книги убрали статьи 1, 2.1, 2.2, 3 ;(