Наверное лучше синхронная т.к. набор данных должен быть везде гарантированно одинаков. Вообще я в этом пока не определился, есть более приоритетные и простые задачи.
1) Зависимостей особых нет. Можно собрать с jemalloc или tcmalloc. Но это опционально.
2) Сетевая подсистема почти полностью взята из Redis. Есть поддержка epoll/select механизмов.
3) Сохранения данных происходит в файл. Для сохранения используется собственный бинарный формат.
Почему EagleMQ я точно сам не знаю. Орёл быстрая птица, EagleMQ тоже :)
Все данные сбрасываются на диск по заданному интервалу (асинхронно, через fork) и если сервер упадет то загрузится с данными последнего сохранения. Это пока единственный механизм сохранения данных.
За автоподъем ответственность можно переложить на специальные утилиты. Сам по себе сервер не запустится.
Аллокатор памяти подсчитывает всю выделяемую приложением память во время исполнения. Потом берётся RSS (Resident set size) процесса и делится на реально выделенную память.
Вообще аллокатор взят из Redis для поддержки jemalloc и tcmalloc.
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 которая очищает очередь.
Если получить контроль над NTP сервером, получается можно массово сломать Windows
В будущем возможно добавлю snapshotting для настройки интервалов сохранения в зависимости от количества измененных данных.
2) Сетевая подсистема почти полностью взята из Redis. Есть поддержка epoll/select механизмов.
3) Сохранения данных происходит в файл. Для сохранения используется собственный бинарный формат.
Почему EagleMQ я точно сам не знаю. Орёл быстрая птица, EagleMQ тоже :)
Все данные сбрасываются на диск по заданному интервалу (асинхронно, через fork) и если сервер упадет то загрузится с данными последнего сохранения. Это пока единственный механизм сохранения данных.
За автоподъем ответственность можно переложить на специальные утилиты. Сам по себе сервер не запустится.
Вообще аллокатор взят из Redis для поддержки jemalloc и tcmalloc.
Но это моё личное мнение. Я на самом деле нигде его не использовал.
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
Реализовывать заново AMQP не имеет большого смысла т.к. уже есть RabbitMQ например.
К тому же я собираюсь добавлять функциональность которой нет в AMQP (не хочу ограничиваться протоколом).