Здравствуйте,
напишите пожалуйста в личку:
— email в моем мире
— где происходила проблема (мобильный веб, веб, мобильное приложение)
— email друга, от которого не отображаются сообщения в ленте
постараемся разобраться
Заменить bdb на что-то более подходящее — не проблема
Насколько помню, в то время, из альтернатив bdb qpid поддерживал только SQL базы в качестве системы записи данных
под «удачными решениями» я имел ввиду исключительно попытки «вшить» scheduling в messaging
Но, что-то помешало вам сделать отдельную (от messaging) подсистему для DD. Хотя, казалось бы :-) Вот в чем сакральный смысл хранить активные и не активные сообщения в одних и тех же очередях?
Суровая реальность вносит коррективы в идеальную картину мира :)
Потребуется в 2 раза больше дисков, 1 в сервере очередей, чтоб не потерялись события, другой в планировщике, так как в нем большое количество событий могут жить длительное время. Если писать все это на один диск, упадет производительность, на каждое событие придется делать 2 записи на диск вместо одной.
Что делать если клиент захотел внести коррективы в сообщение, уже доставленное планировщику? Можно слать через систему очередей служебные сообщения для планировщика, который будет понимать что это сообщение с мета данными полученного ранее события. Можно обучить клиентов знанию еще и о планировщике и слать изменения напрямую в него. Но, это тоже приводит к нехорошим последствиям. Сообщение по каким-то причинам может быть еще не получено планировщиком из очереди сообщений, а клиент уже прислал изменения. Получается много граничных условий, усложняющих жизнь
Это всего лишь несколько примеров.
Скрестив 2 сущности в одной, мы не очень-то усложнили реализацию сервера очередей, зато добились упрощения архитектуры проекта в целом.
Я же правильно понимаю, что речь идет о «группировке» сообщений одного и того же продюсера, которые он положил в разные очереди? «Группировку» делает сам продюсер, а не сервер?
Речь идет о группировке событий в рамках одной очереди с помощью установки одинакового времени активации. Необязательно должен быть именно один продюсер, обычно группировка делается по внутреннему id данных, например по id пользователя, это позволяет группировать события разным продюсерам.
Сервер про группировку ничего не знает.
Приведу пример:
— Анти спам решил что пользователь X потенциальный спамер (неважно почему)
— Мы хотим проверить последние Y действий пользователя попадающих в ленту к друзьям (загрузка фото, высказывания и т.п.)
— Продюсер получает список ID этих Y событий (из какого-то хранилища)
— Для каждого ID из этих Y порождает событие в очередь и устанавливает одинаковое время активации
В чем польза:
Обработчики событий будут ходить в дисковое хранилище, в котором лежит вся активность пользователей и получение каждого события, если его нет в кэше хранилища — это поход на диск.
Если же события активируются в близкий период времени, то, поход на диск если и будет, то только один. При чтении данных с диска в большинстве наших хранилищ делается prefetch, в кэше на какое-то время оседают и другие события пользователя, а не только те, что были запрошены select'ом из конкретного обработчика.
Таким образом мы уменьшаем суммарное время обработки всех Y событий пользователя X.
И все это на распределенной ферме подписчиков, без каких либо ухищрений в виде синхронизаций на уровне обработчиков.
Хм… но это означает, в том числе и то, что сервер не имеет возможности уведомить подписчика о том, что то сообщение, которое он обрабатывает, повторно активировано. Т.е. что истек timeout и данное сообщение разблокировано.
Каким образом избегаете повторной обработки сообщений, если не секрет?
Верно, сервер никого ни о чем не уведомляет.
Рецепт простой, проблем не доставляет.
Время реактивации сообщений в большинстве очередей выставляется в 1 — 2 часа.
Ни одно сообщение не может так долго обрабатываться. Если за это время оно не было обработано, значит что-то случилось или с обработчиком, или с хранилищем в которое ходит обработчик.
Если среднее время обработки сообщений начинает расти, или в очереди копятся заблокированные события — срабатывает мониторинг и разработчики бизнес логики идут искать ошибки.
Я-то представляю себе, что примерно у вас получилось :-) Тем не менее, в заголовок вы вынесли именно «Сервер очередей».
Правильно, так как система ближе всего именно к серверу очередей
Сдается, мне — не больно то и хотелось :-) Но, мне действительно интересно, изучали ли предметно тот же AMQP, или просто «по втыкали» в «кролика» и успокоились? Почему ограничились только «кроликом»? Если я все правильно понял про 2009 год, то он чуть менее чем ужасен в плане реализации AMQP на тот момент. Тот же qpid от Апачей на то время — практически эталон.
Пробовали разное, но, больше всего RabbitMQ.
В qpid для сохранения данных на диск используется bdb, о какой производительности можно говорить… В моих экспериментах результаты были хуже RabbitMQ
От себя могу сказать, что за 10 лет я таких «удачных» решений видел множество
Звучит очень знакомо :)
Сейчас отвлекусь от очередей, Вы затронули популярную тему.
Обычно, новые сотрудники первые 3 месяца высказываются аналогично. А потом приходит понимание, зачем приходится писать свои велосипеды.
Мы пытаемся упростить себе жизнь и использовать сторонние разработки, к сожалению, очень редко удается пройти этап тестирования.
В подавляющем большинстве случаев разрекламированные решения не устраивают или по производительности, или по надежности или по критерию стабильности работы. Пробовали привлекать разработчиков сторонних систем, писать патчи — чаще всего не помогает.
И приходится в очередной раз разрабатывать свои собственные решения, менее универсальные, зато оптимизированные под наши задачи.
Это не значит что мы не используем чужие системы — используем, но, не так часто как хотелось бы.
Что касается вашей системы, то, осмелюсь предположить, что ваши «группировки событий» — на самом деле «костыль со стразиками» :-)
Не совсем так. Это своего рода бонус, который позволяет небольшими доработками улучшить производительность в критичных местах. Не будете же Вы говорить, что улучшать локальность данных, для того что бы уменьшить промахи кэша процессора сродни костылю? В данном случае работает тот же принцип.
Я правильно понял, что сервер у вас не знает о наличии/отсутствии подписчик[а/ов]?
Все верно. Вся логика управления подписчиками вынесена в отдельную подсистему. Это отдельный кластер машин со своей внутренней диспетчеризацией и управлением ресурсами выделяемыми для обработки той или иной очереди.
Описанный случай выходит за рамки ответственности сервера очередей
Это чистой воды бизнес логика обработчика сообщений из очереди.
В каких-то случаях можно по уникальному идентификатору контента догадаться что это то же самое что пытались вставить, а в каких-то банальный MD5
Здравствуйте,
выше писал что у нас получилась специализированная система, не соответствующая классическому представлению о Message Queue
Почему и зачем — у нас были задачи, которые нужно было решать.
Сделать это существующими решениями с необходимой производительностью не удалось.
Для нас смешение логики оказалось очень удачным.
Сервер очередей одна из немногих активно используемых систем, которая не вызывает постоянного желания что-то доделывать и переделывать.
Наше решение пришлось по вкусу и в других проектах, как оказалось у них то же хватает «странных» задач
write вызывается на каждую команду.
Мы не отвечаем клиенту пока не получили подтверждение о выполнении write (это еще не гарантия того что данные попали на диск)
Каждые N записываемых записей, вызываем fdatasync, что бы данные все таки попали на диск.
Что у нас получается:
— Если упал софт, но, сервер не перезагружался — все нормально. Не будет потеряна ни одна команда.
— Если отключилось питание на сервере, то, мы можем потерять несколько записей которые находились в файловых кэшах, но, еще не записаны операционной системой на диск (записи после последнего fdatasync)
не хватает,
очереди в тарантуле хороши для быстрого старта
по сравнению с нашим решением больше дополнительных данных на каждое сообщение
Разрабатывает команда Моего Мира.
Команда Tarantool не участвует.
По родословной все наоборот. Tarantool родился из фреймворка разработанного в Моем Мире
Никакой магии.
— пользователь отредактировал свой профиль, сообщение ушло в очередь.
— пользователю скажут что все ОК и покажут обновленные данные.
— если пользователь нажал F5 до того как данные дошли до хранилища, он увидит старые данные.
При нормальной работе сервиса события из очереди обрабатываются за несколько миллисекунд, данные окажутся в хранилище раньше чем браузер пользователя отобразит ответ от сервера.
Выгода проявляется во время сбоев, что-то с сетью, часть хранилищ перегружено, или аппаратный сбой, да все что угодно. В таком случае данные из очереди попадут не сразу в хранилище, важно, что они туда обязательно попадут. Неважно, ждет пользователь ответ от сервера, или уже ушел.
Если я правильно понял вопрос про отложенную доставку:
— если нужно отложить обработку события приходит команда на переустановку времени активации события.
— если нужно отложенное событие снова вернуть в пул готовых к обработке приходит та же команда, устанавливающая время активации в текущее значение или в прошлое.
что бросилось в глаза при первом знакомстве:
1. не указан размер сообщений которыми тестировали
2. в тестовой конфигурации сервера указано 12 SAS дисков
«HP StorageWorks 146GB 15K dual port SAS LFF disk drives 512547-B21»
Если загружают все диски, то, указанная цифра в 8 млн кажется маленькой. Опять же, зависит от размера сообщения.
я то же не указал конфигурацию.
В нашем случае эталон это 1 инстанс сервера очередей на одном типовом SATA диске. Размер сообщений равен 4096 байт пользовательских данных.
По другим тестам производительность не выглядит впечатляющей, возможно неправильные тесты (http://integr8consulting.blogspot.ru/2011/02/jms-speed-test-activemq-vs-hornetq.html)
К сожалению, нет.
Очередь может быть пошаржена между несколькими серверами
одно сообщение всегда обрабатывается с конкретного мастера шарда, жить может и в репликах
В планах есть реализация этого функционала, но, это будет нескоро.
Все верно,
нам нужен был нестандартный сервер сообщений, скорее специализированное хранилище
поверх которого построена ферма для выполнения разнообразных задач
На момент разработки Apache Kafka еще не существовала
сейчас Kafka выглядит крайне интересно.
Нет смысле переделывать существующую архитектуру ради Kafka
в новом проекте можно использовать Kafka для транспорта важной статистики, транспорт между внутренними хранилищами и т.п.
мне нравится как используется Kafka в хранилище druid (http://druid.io)
только заметил.
хотим, но, нужно время что бы вычистить исторические нюансы.
к сожалению, пока что этого времени нет
напишите пожалуйста в личку:
— email в моем мире
— где происходила проблема (мобильный веб, веб, мобильное приложение)
— email друга, от которого не отображаются сообщения в ленте
постараемся разобраться
Это относительно новая система, на тот момент в Моем Мире не один год существовал свой сервер приложений
Насколько помню, в то время, из альтернатив bdb qpid поддерживал только SQL базы в качестве системы записи данных
Суровая реальность вносит коррективы в идеальную картину мира :)
Потребуется в 2 раза больше дисков, 1 в сервере очередей, чтоб не потерялись события, другой в планировщике, так как в нем большое количество событий могут жить длительное время. Если писать все это на один диск, упадет производительность, на каждое событие придется делать 2 записи на диск вместо одной.
Что делать если клиент захотел внести коррективы в сообщение, уже доставленное планировщику? Можно слать через систему очередей служебные сообщения для планировщика, который будет понимать что это сообщение с мета данными полученного ранее события. Можно обучить клиентов знанию еще и о планировщике и слать изменения напрямую в него. Но, это тоже приводит к нехорошим последствиям. Сообщение по каким-то причинам может быть еще не получено планировщиком из очереди сообщений, а клиент уже прислал изменения. Получается много граничных условий, усложняющих жизнь
Это всего лишь несколько примеров.
Скрестив 2 сущности в одной, мы не очень-то усложнили реализацию сервера очередей, зато добились упрощения архитектуры проекта в целом.
Речь идет о группировке событий в рамках одной очереди с помощью установки одинакового времени активации. Необязательно должен быть именно один продюсер, обычно группировка делается по внутреннему id данных, например по id пользователя, это позволяет группировать события разным продюсерам.
Сервер про группировку ничего не знает.
Приведу пример:
— Анти спам решил что пользователь X потенциальный спамер (неважно почему)
— Мы хотим проверить последние Y действий пользователя попадающих в ленту к друзьям (загрузка фото, высказывания и т.п.)
— Продюсер получает список ID этих Y событий (из какого-то хранилища)
— Для каждого ID из этих Y порождает событие в очередь и устанавливает одинаковое время активации
В чем польза:
Обработчики событий будут ходить в дисковое хранилище, в котором лежит вся активность пользователей и получение каждого события, если его нет в кэше хранилища — это поход на диск.
Если же события активируются в близкий период времени, то, поход на диск если и будет, то только один. При чтении данных с диска в большинстве наших хранилищ делается prefetch, в кэше на какое-то время оседают и другие события пользователя, а не только те, что были запрошены select'ом из конкретного обработчика.
Таким образом мы уменьшаем суммарное время обработки всех Y событий пользователя X.
И все это на распределенной ферме подписчиков, без каких либо ухищрений в виде синхронизаций на уровне обработчиков.
Верно, сервер никого ни о чем не уведомляет.
Рецепт простой, проблем не доставляет.
Время реактивации сообщений в большинстве очередей выставляется в 1 — 2 часа.
Ни одно сообщение не может так долго обрабатываться. Если за это время оно не было обработано, значит что-то случилось или с обработчиком, или с хранилищем в которое ходит обработчик.
Если среднее время обработки сообщений начинает расти, или в очереди копятся заблокированные события — срабатывает мониторинг и разработчики бизнес логики идут искать ошибки.
Правильно, так как система ближе всего именно к серверу очередей
Пробовали разное, но, больше всего RabbitMQ.
В qpid для сохранения данных на диск используется bdb, о какой производительности можно говорить… В моих экспериментах результаты были хуже RabbitMQ
Звучит очень знакомо :)
Сейчас отвлекусь от очередей, Вы затронули популярную тему.
Обычно, новые сотрудники первые 3 месяца высказываются аналогично. А потом приходит понимание, зачем приходится писать свои велосипеды.
Мы пытаемся упростить себе жизнь и использовать сторонние разработки, к сожалению, очень редко удается пройти этап тестирования.
В подавляющем большинстве случаев разрекламированные решения не устраивают или по производительности, или по надежности или по критерию стабильности работы. Пробовали привлекать разработчиков сторонних систем, писать патчи — чаще всего не помогает.
И приходится в очередной раз разрабатывать свои собственные решения, менее универсальные, зато оптимизированные под наши задачи.
Это не значит что мы не используем чужие системы — используем, но, не так часто как хотелось бы.
Не совсем так. Это своего рода бонус, который позволяет небольшими доработками улучшить производительность в критичных местах. Не будете же Вы говорить, что улучшать локальность данных, для того что бы уменьшить промахи кэша процессора сродни костылю? В данном случае работает тот же принцип.
Все верно. Вся логика управления подписчиками вынесена в отдельную подсистему. Это отдельный кластер машин со своей внутренней диспетчеризацией и управлением ресурсами выделяемыми для обработки той или иной очереди.
Единственное что мы можем обеспечить, что потеряно будет не больше N записей
Это чистой воды бизнес логика обработчика сообщений из очереди.
В каких-то случаях можно по уникальному идентификатору контента догадаться что это то же самое что пытались вставить, а в каких-то банальный MD5
выше писал что у нас получилась специализированная система, не соответствующая классическому представлению о Message Queue
Почему и зачем — у нас были задачи, которые нужно было решать.
Сделать это существующими решениями с необходимой производительностью не удалось.
Для нас смешение логики оказалось очень удачным.
Сервер очередей одна из немногих активно используемых систем, которая не вызывает постоянного желания что-то доделывать и переделывать.
Наше решение пришлось по вкусу и в других проектах, как оказалось у них то же хватает «странных» задач
Мы не отвечаем клиенту пока не получили подтверждение о выполнении write (это еще не гарантия того что данные попали на диск)
Каждые N записываемых записей, вызываем fdatasync, что бы данные все таки попали на диск.
Что у нас получается:
— Если упал софт, но, сервер не перезагружался — все нормально. Не будет потеряна ни одна команда.
— Если отключилось питание на сервере, то, мы можем потерять несколько записей которые находились в файловых кэшах, но, еще не записаны операционной системой на диск (записи после последнего fdatasync)
Кэш в жестких дисках считаем выключенным.
Мы используем только системы с открытым исходным кодом
очереди в тарантуле хороши для быстрого старта
по сравнению с нашим решением больше дополнительных данных на каждое сообщение
Разрабатывает команда Моего Мира.
Команда Tarantool не участвует.
По родословной все наоборот. Tarantool родился из фреймворка разработанного в Моем Мире
расстраивает текстовый протокол для взаимодействия с сервером
— пользователь отредактировал свой профиль, сообщение ушло в очередь.
— пользователю скажут что все ОК и покажут обновленные данные.
— если пользователь нажал F5 до того как данные дошли до хранилища, он увидит старые данные.
При нормальной работе сервиса события из очереди обрабатываются за несколько миллисекунд, данные окажутся в хранилище раньше чем браузер пользователя отобразит ответ от сервера.
Выгода проявляется во время сбоев, что-то с сетью, часть хранилищ перегружено, или аппаратный сбой, да все что угодно. В таком случае данные из очереди попадут не сразу в хранилище, важно, что они туда обязательно попадут. Неважно, ждет пользователь ответ от сервера, или уже ушел.
— если нужно отложить обработку события приходит команда на переустановку времени активации события.
— если нужно отложенное событие снова вернуть в пул готовых к обработке приходит та же команда, устанавливающая время активации в текущее значение или в прошлое.
что бросилось в глаза при первом знакомстве:
1. не указан размер сообщений которыми тестировали
2. в тестовой конфигурации сервера указано 12 SAS дисков
«HP StorageWorks 146GB 15K dual port SAS LFF disk drives 512547-B21»
Если загружают все диски, то, указанная цифра в 8 млн кажется маленькой. Опять же, зависит от размера сообщения.
я то же не указал конфигурацию.
В нашем случае эталон это 1 инстанс сервера очередей на одном типовом SATA диске. Размер сообщений равен 4096 байт пользовательских данных.
По другим тестам производительность не выглядит впечатляющей, возможно неправильные тесты (http://integr8consulting.blogspot.ru/2011/02/jms-speed-test-activemq-vs-hornetq.html)
Очередь может быть пошаржена между несколькими серверами
одно сообщение всегда обрабатывается с конкретного мастера шарда, жить может и в репликах
В планах есть реализация этого функционала, но, это будет нескоро.
нам нужен был нестандартный сервер сообщений, скорее специализированное хранилище
поверх которого построена ферма для выполнения разнообразных задач
сейчас Kafka выглядит крайне интересно.
Нет смысле переделывать существующую архитектуру ради Kafka
в новом проекте можно использовать Kafka для транспорта важной статистики, транспорт между внутренними хранилищами и т.п.
мне нравится как используется Kafka в хранилище druid (http://druid.io)
они сильно улучшили производительность в районе 2.8.х
Для остальных не знаю подходящего аналога.