>> То есть у вас нет вероятности того, что кластер разделится на N подсетей? Допустим где-то маршрутизатор умер. И либо умерло все либо все живое?
У нас полный набор всех сервисов в 2 независимых дата-центрах (и некоторые еще в третьем). Если упал маршрутизатор в одном, считаем, что упал весь дата-центр.
Вероятность, что распадется на N подсетей или откажут оба дата-центра одновременно — есть. Но мы считаем ее меньше вероятности падения кирпича на голову.
>> И вот интересный вопрос — сложность в настройке и поддержке, ну допустим по сравнению с кроликом сильно различается?
Не можем подсказать — опыта его администрирования и использования в production у нас нет.
>> Вот прям везет вам, что никогда оборудование не умирает)
NATS и NSQ выглядят похоже. Мы не глубоко изучали NSQ, но там вроде 2 процесса в каждом узле вместо одного (сложнее администрировать) + у NATS есть возможность добавить message persistence, если понадобится (надстройка NATS Streaming).
Спасибо за комментарий. Мы логируем время отправки и время окончания обработки каждого сообщения получателем, и в мониторинге висит триггер, если время окончания обработки все еще не заполнено через 10 минут после отправки.
Некоторые сообщения мы можем безболезненно терять — например, push-уведомление на телефон с количеством новых задач. Обычно, через несколько минут будет новое такое сообщение, старое перестанет быть актуальным.
Ситуация, когда умер хотя бы один сервис — исключительная. Это бывает при maintenance, минут 5-10 может. В крайнем случае — ночь может полежать (но всегда есть резерв). Конечно, 100% гарантия невозможна и между at-least-once / at-most-once delivery мы явно сделали выбор в пользу последнего. Нам важно, что мы не ожидаем сюрпризов от выбранного механизма MQ.
Как я понимаю, каждый сервер кластера знает обо всех остальных и публикует темы (topic), на которые он подписан. Нет единого центра управления, никто не считается главным узлом, поэтому и split brain в классическом понимании (2 главных узла) невозможен. Полный peer-to-peer.
Пропускную способность в production не измеряли, нам достаточно, что слой MQ незаметен и latency между разными физическими машинами в районе 1ms. Когда будет время, соберем статистику, напишем отдельно.
У нас не было вопроса JSON или какой-либо другой формат данных. Это обусловлено тем, что основным клиентом сервиса является браузер, в котором есть нативная поддержка JSON. Да и во всех мобильных платформах есть много JSON-библиотек.
Вопрос скорее был такой: куда уходит CPU веб сервера и что оптимизировать в первую очередь. Оказалось, что наш собственный код отъедал не более 30%, остальное — gzip и сериализация ответов. Мораль: вначале замеряем, а уже потом ввязываемся в благородное дело кодирования.
Цифры: в самых тяжелых запросах сериализация выполнялась более 400мс (около 8Мб данных до gzip). Нам удалось сократить это до 98мс, но не в общем случае, а конкретно для нашего набора данных. Самая быстрая библиотека общего назначения давала около 200мс.
Есть шансы ускорить сериализацию еще, но мы решили двигаться в сторону уменьшения объема данных.
В Google есть много ссылок на сравнения библиотек. Да и на Хабре, кажется, писали обзоры.
Мы не рассматривали альтернативные форматы, поскольку JSON — стандарт, поддерживается всем браузерами и библиотеки доступны на всех мобильных платформах. В итоге все в JSON и останется в нем в обозримом будущем.
Наиболее точное, построчное профилирование, замедляет выполнение кода примерно в 10 раз. Разумеется, мы используем легковесное профилирование, но оно не всегда дают достаточно точную информацию.
Спасибо за комментарий. Как вы, наверное, заметили, это пост с пометкой «из песочницы». Т.е. он у нас тут первый. Будем пробовать писать истории в другом формате.
У нас полный набор всех сервисов в 2 независимых дата-центрах (и некоторые еще в третьем). Если упал маршрутизатор в одном, считаем, что упал весь дата-центр.
Вероятность, что распадется на N подсетей или откажут оба дата-центра одновременно — есть. Но мы считаем ее меньше вероятности падения кирпича на голову.
>> И вот интересный вопрос — сложность в настройке и поддержке, ну допустим по сравнению с кроликом сильно различается?
Не можем подсказать — опыта его администрирования и использования в production у нас нет.
>> Вот прям везет вам, что никогда оборудование не умирает)
Умирает, просто мы считаем это штатной ситуацией.
Send 1K bytes over 1 Gbps network 10,000 ns
Read 4K randomly from SSD* 150,000 ns
Тут, конечно, указана цифра для чтения с SSD, но запись вряд ли будет быстрее.
Вот здесь можно какие-то впечатления прочитать:
https://news.ycombinator.com/item?id=11284489
Некоторые сообщения мы можем безболезненно терять — например, push-уведомление на телефон с количеством новых задач. Обычно, через несколько минут будет новое такое сообщение, старое перестанет быть актуальным.
Ситуация, когда умер хотя бы один сервис — исключительная. Это бывает при maintenance, минут 5-10 может. В крайнем случае — ночь может полежать (но всегда есть резерв). Конечно, 100% гарантия невозможна и между at-least-once / at-most-once delivery мы явно сделали выбор в пользу последнего. Нам важно, что мы не ожидаем сюрпризов от выбранного механизма MQ.
Как я понимаю, каждый сервер кластера знает обо всех остальных и публикует темы (topic), на которые он подписан. Нет единого центра управления, никто не считается главным узлом, поэтому и split brain в классическом понимании (2 главных узла) невозможен. Полный peer-to-peer.
Пропускную способность в production не измеряли, нам достаточно, что слой MQ незаметен и latency между разными физическими машинами в районе 1ms. Когда будет время, соберем статистику, напишем отдельно.
>> каждая партиция независима, о какой блокировке всей очереди идет речь?
вы правы, речь именно о блокировке одной partition, спасибо.
>> Поэтому пока это смотрится: а смотрите что мы на Go сумели написать, Go сейчас модный, так что вы должны выбрать нас.
Хуже того, они вначале на ruby написали (еще более модный), работало медленно, переписали на Go. :)
Вопрос скорее был такой: куда уходит CPU веб сервера и что оптимизировать в первую очередь. Оказалось, что наш собственный код отъедал не более 30%, остальное — gzip и сериализация ответов. Мораль: вначале замеряем, а уже потом ввязываемся в благородное дело кодирования.
Цифры: в самых тяжелых запросах сериализация выполнялась более 400мс (около 8Мб данных до gzip). Нам удалось сократить это до 98мс, но не в общем случае, а конкретно для нашего набора данных. Самая быстрая библиотека общего назначения давала около 200мс.
Есть шансы ускорить сериализацию еще, но мы решили двигаться в сторону уменьшения объема данных.
В Google есть много ссылок на сравнения библиотек. Да и на Хабре, кажется, писали обзоры.
А если серьезно — нам нравится делать полезные вещи. Кому-то наша система приносит пользу, а кто-то, мы надеемся, извлечет пользу из этого текста.