Comments 16
Каково примерное кол-во и конфигурация машин, выделенных под каждый слой архитектуры?
Конкретно сложно сформулировать. Мы хостимся в дата центре и конфигурация оборудования обусловлена скорее историческими причинами, чем текущими потребностями.
Очереди хранятся в трех кластерах SQL Server, практически не влияя на их загрузку.
Обработчики крутятся на тех же базах + двух отдельных серверах + есть еще сервера веб сервисов, которыми они пользуются…
Очереди хранятся в трех кластерах SQL Server, практически не влияя на их загрузку.
Обработчики крутятся на тех же базах + двух отдельных серверах + есть еще сервера веб сервисов, которыми они пользуются…
Мы проходили на проекте построение очередей на SQL-базах. Минусы в постоянной перестройке индексов, если сообщения путешествуют между таблицами либо очень широкой таблицей с лишними колонками-флагами, если все сообщения лежат в одной таблице и у них меняются статусы и промежуточные данные. Наша особенность была в том, что каждый объект проходил воронку из 16 операций разной ресурсоемкости и каждая операция добавляла или убирала определенные виды данных этим объектам. То есть «демон» каждой операции (на одной операции могло быть задействовано от 1 до 40 демонов) лез в базу, искал 1-N объектов для обработки, обрабатывал и менял их статус и данные. Также проблемы были в количестве коннектов к БД.
В итоге перешли на RabbitMQ с автоматическим подключением новых серверов. Создали 15 очередей. Каждый демон берет данные из одной очереди, обрабатывает и то, что получилось отправляет во вторую очередь. В итоге в SQL-базу данные попадали после прохождения всех этапов воронки и PostgreSQL был практически не нагружен. Производительность поднялась со 200,000 объектов в сутки до 500,000 объектов в час (часть операций ресурсоемкая и выполняется по 1-2 секунды на объект).
В итоге перешли на RabbitMQ с автоматическим подключением новых серверов. Создали 15 очередей. Каждый демон берет данные из одной очереди, обрабатывает и то, что получилось отправляет во вторую очередь. В итоге в SQL-базу данные попадали после прохождения всех этапов воронки и PostgreSQL был практически не нагружен. Производительность поднялась со 200,000 объектов в сутки до 500,000 объектов в час (часть операций ресурсоемкая и выполняется по 1-2 секунды на объект).
Согласен. Мы стараяемся не использовать таблицы для очередей.
В основном мы сейчас используем SQL Server Service Broker. Там множество своих тонкостей, но если всё настроено хорошо, то проблем с производительностью в работе с очередями не образуется. В качестве бонуса — относительно простые обработчики мы хостим прямо в SQL Server, накладные расходы получаются очень низкими, никаких проблем с управлением коннектами к БД, опросом очередей, локами и т.д. Но это не для всех задач, конечно же.
Хотя, например, очередь входящего шлюза в продакшене (опять же исторически) — это у нас таблица в базе. Даже при том, что в ней лежат относительно большие сериализованные сообщения, мы его разгоняли до 250,000 в минуту.
В основном мы сейчас используем SQL Server Service Broker. Там множество своих тонкостей, но если всё настроено хорошо, то проблем с производительностью в работе с очередями не образуется. В качестве бонуса — относительно простые обработчики мы хостим прямо в SQL Server, накладные расходы получаются очень низкими, никаких проблем с управлением коннектами к БД, опросом очередей, локами и т.д. Но это не для всех задач, конечно же.
Хотя, например, очередь входящего шлюза в продакшене (опять же исторически) — это у нас таблица в базе. Даже при том, что в ней лежат относительно большие сериализованные сообщения, мы его разгоняли до 250,000 в минуту.
Больше всего интересует самый первый этап распределения входящих сообщений меду кластерами.
У вас используется балансировщик? Какой? Один или несколько? Как происходит балансировка, распределение сообщений?
У вас используется балансировщик? Какой? Один или несколько? Как происходит балансировка, распределение сообщений?
На первом этапе сообщения не распределяются, они все сваливаются в одну очередь. Перед очередью стоит несколько легких веб серверов и балансировщик для отказоустойчивости. Нагрузки на систему здесь невелика.
Потом уже происходит декодирование, применяются общие операции, и уже затем распределение по шардам баз данных. Шард ключ на основе номера клиента.
Потом уже происходит декодирование, применяются общие операции, и уже затем распределение по шардам баз данных. Шард ключ на основе номера клиента.
Какой балансировщик используете?
Как архитектурно выглядят «несколько легких веб серверов и балансировщик» перед очередью?
Вы пишете:
>Немного про уровень нагрузки. Наша система обрабатывает сообщения от десятков тысяч устройств, при этом за секунду в среднем >мы получаем от нескольких сотен до тысячи сообщений
и
>Нагрузки на систему здесь невелика
По-моему, нагрузка от тысячи до нескольких тысяч сообщений в секунду уже прилична и её нельзя назвать невеликой.
Как архитектурно выглядят «несколько легких веб серверов и балансировщик» перед очередью?
Вы пишете:
>Немного про уровень нагрузки. Наша система обрабатывает сообщения от десятков тысяч устройств, при этом за секунду в среднем >мы получаем от нескольких сотен до тысячи сообщений
и
>Нагрузки на систему здесь невелика
По-моему, нагрузка от тысячи до нескольких тысяч сообщений в секунду уже прилична и её нельзя назвать невеликой.
>Шард ключ на основе номера клиента.
Это мне кажется странным, т.к нагрузка на шарды может оказаться неравномерной из-за того, что один клиент будет слать сообщений намного больше, чем другой, «молчун»
Это мне кажется странным, т.к нагрузка на шарды может оказаться неравномерной из-за того, что один клиент будет слать сообщений намного больше, чем другой, «молчун»
При построении API для хождения мобильных устройств на я стараюсь предусмотреть (даже для stateless-систем) набор сообщений, позволяющих идентифицировать и управлять с бакенда поведением клиенстких устройств — в частности, одним из методов является Handshake_Hello({UDID}), который принимает идентификатор устройства, а отдает, наряду с необходимой устройству конфигурационной информацией сервера, еще и поле AlternateCommunicationPoint={new URI}.
Согласно спецификации серверного API, Handshake_Hello вызывается при старте приложения на устройстве перед первым запросом на сервер — для сессионных схем он возвращает токен сессии, и без него дальнейшие запросы не будут авторизованы; для stateless — ответственность за вызов лежит на разработчике клиента.
Получив в ответ на вызов непустой CommunicationPoint, клиент должен повторить посылку Handshake_Hello на переданный ему в ответе URI, иначе — может продолжать общение с исходным сервером.
Таким образом, можно прямо на лету перенаправлять нужные устройства (по UDID) например, на тестовый сервер, где детально логировать обмен, переключать временно всех с prod на dev, распределять нагрузку по разным инстансам итд
Согласно спецификации серверного API, Handshake_Hello вызывается при старте приложения на устройстве перед первым запросом на сервер — для сессионных схем он возвращает токен сессии, и без него дальнейшие запросы не будут авторизованы; для stateless — ответственность за вызов лежит на разработчике клиента.
Получив в ответ на вызов непустой CommunicationPoint, клиент должен повторить посылку Handshake_Hello на переданный ему в ответе URI, иначе — может продолжать общение с исходным сервером.
Таким образом, можно прямо на лету перенаправлять нужные устройства (по UDID) например, на тестовый сервер, где детально логировать обмен, переключать временно всех с prod на dev, распределять нагрузку по разным инстансам итд
А что за сервис то? Мониторинг транспорта?
Слишком абстрактно выходит без понимания о чем речь…
По теме вопрос такой:
Несмотря на очереди узким местом в данном случае будет самый первый gateway сервер.
Хоть он не нагруженный, но если он встает, то все сообщения со всех устройств теряются вместе с очередями.
Не думали ли делать на самих устройствах привязку к разным зеркалам?
Выше похожий комментарий вопрос в комментарии…
Слишком абстрактно выходит без понимания о чем речь…
По теме вопрос такой:
Несмотря на очереди узким местом в данном случае будет самый первый gateway сервер.
Хоть он не нагруженный, но если он встает, то все сообщения со всех устройств теряются вместе с очередями.
Не думали ли делать на самих устройствах привязку к разным зеркалам?
Выше похожий комментарий вопрос в комментарии…
Так и задумано — сделать абстрактно. Но вы правы, действительно мониторинг транспорта.
Про гейтвей ответил выше.
Про гейтвей ответил выше.
И всё-таки, расскажите, пожалуйста про балансировку и первый gatewate-сервер поподробнее. Если это секрет, то так и скажите, не будем больше мучать
Есть Virtual IP устройство (кажется, Citrix Netscaler), за ним стоят 3 веб сервера. Netscaler перенаправляет входящие запросы на один из них. Ну и еще проводит их health check, периодически обращаясь по фиксированному HTTP адресу на каждом из них.
Схема такая же, как для всех других веб серверов в нашем дата центре, никаких ухищрений не требовалось. Или я о них не знаю, я все-таки далек от железа.
Схема такая же, как для всех других веб серверов в нашем дата центре, никаких ухищрений не требовалось. Или я о них не знаю, я все-таки далек от железа.
Apache Storm не смотрели? Типа на входе очереди на Kaffka, процессинг в Storm и выгрузка в hdfs или hbase?
Sign up to leave a comment.
Как мы строим систему обработки сообщений