Шаблоны и технологии для системы, способной обрабатывать 40 000 сообщений в секунду.

Question

Нам нужно построить систему, способную обрабатывать 40 000 сообщений в секунду.Ни одно сообщение не может быть потеряно в случае каких-либо программных или аппаратных сбоев.

Размер каждого сообщения составляет около 2-4Кб.

Обработка сообщения состоит из проверки сообщения, выполнения некоторых простых арифметических вычислений, сохранения результата в базе данных и (иногда) отправки уведомлений в другие системы.

Предпочтительной программной технологией является .Net.

Какие модели программного и аппаратного обеспечения наиболее подходят для такой задачи?

Сколько оборудования для этого потребуется?

Answer 1

1. Очередь сообщений.Ваш технологический процесс кажется главной целью для него.
2. Кластеризация/балансировка нагрузки.
3. Оптимизируйте свой код

Первое, что я бы сделал, это поставил уведомления в очередь.Затем я бы поставил в очередь все записи в базу данных, которым не нужно возвращать значение.Тогда я бы посмотрел на масштабирование.

Другие соображения:* Избегайте больших, неуклюжих фреймворков, которые выполняют гораздо больше скрытой работы, чем вам, вероятно, нужно.* Используйте кэш и статические переменные везде, где это возможно.

40 000 сообщений в секунду вполне осуществимы, но если добавить к этому объем ввода-вывода, результат может оказаться непредсказуемым даже на сверхбыстром оборудовании с огромным объемом памяти.Постарайтесь выполнить как можно больше внеполосной обработки.Если это не удается, посмотрите, можете ли вы запускать несколько потоков (на многоядерной или многопроцессной машине) и при необходимости просмотреть несколько серверов в кластере.

Редактировать:

Я не могу переоценить преимущества нагрузочного тестирования в таком сценарии.Создайте простой прототип и нагрузочное тестирование.Усовершенствуйте прототип, пока не получите желаемые результаты.Затем создайте окончательное решение на основе прототипа.Пока вы не проверите желаемый уровень производительности, вы будете предполагать решение.

Answer 2

4k * 40.000/с = 160 МБ/с — это довольно большая пропускная способность.

Вероятно, вам потребуется такая полоса пропускания в обоих направлениях, поскольку требование отсутствия потери сообщений означает, что все взаимодействующие стороны отправляют и получают сообщения в обоих направлениях.

Разделите это число на среднюю пропускную способность вашей сетевой карты или скорость записи вашего жесткого диска, чтобы определить, что это будет высокопараллельная и избыточная система.

Вам также необходимо сравнить операции с базой данных и расчеты каждого сообщения, умножив их на 40 000 (или 3,5 миллиарда за один день), чтобы получить оценку необходимого оборудования.

Я думаю, что требование .Net будет наименьшей из ваших проблем.

Answer 3

Первое, что я хотел бы сделать, это попытаться выяснить, что именно означают ваши требования.«Ни одно сообщение не может быть потеряно в случае каких-либо программных или аппаратных сбоев» невозможно.Предположим, вы записываете сообщение на 5000 разных дисков в 5000 разных местах.Если все из этих дисков выйдет из строя одновременно, вы неизбежно потеряете данные.

Аналогично, если вы делать где-то есть ошибка, которая может привести к потере данных.Идея о том, чтобы разработать решение, которое всегда будет работать при обнаружении ошибки в любой части системы, невозможна.

После того, как вы определите, какой уровень избыточности и надежности вам действительно нужен, вам будет легче помочь.Вам также будет легче быть уверенным в том, что вы достигли этого уровня надежности.

Answer 4

Если вы используете стек Microsoft, вам почти наверняка понадобится использовать MSMQ (Microsoft Message Queueing).Он имеет множество опций, которые вы можете настроить для повышения надежности и производительности.Взгляните на Часто задаваемые вопросы по MSMQ.

Узким местом является не обработка, а дисковый ввод-вывод.Имейте много оперативной памяти и делайте как можно больше памяти.

MSMQ управляет своей очередью в памяти, но если оборудование выйдет из строя, все в памяти будет потеряно.Если вы пометите свои сообщения как восстанавливаемые, они будут записаны на диск, но вы легко можете столкнуться с узкими местами.

Answer 5

Если вы используете MSMQ и помечаете сообщения как восстанавливаемые, будьте очень осторожны, чтобы надежно исключить сообщения из очереди.Сделайте этот процесс максимально безопасным, потому что, если что-то пойдет не так, сообщения могут накапливаться так быстро, что диск заполнится за долю секунды и приведет к сбою системы.Тогда все входящие сообщения будут потеряны.Спроси меня, откуда я знаю.(Я не создавал его, мне просто нужно было его поддержать.Не весело.)

Я так и не понял, как указать MSMQ сохранять сообщения на диске, отличном от C:, но это было бы необходимо.По крайней мере, таким образом система сможет сообщить вам о наличии проблемы.

Как уже упоминалось выше, узким местом будут диск и база данных.Я думаю, что MSMQ справится с таким объемом, особенно если вы избегаете триггеров и тому подобного.

MQ от IBM, вероятно, лучше подходит для этой задачи.

Answer 6

Мой совет — нанять того, кто уже создал подобную систему.Пусть они сами выбирают архитектуру и инструменты разработки.Работа с такими высокими показателями транзакций потребует специальных знаний в области аппаратного и программного обеспечения, а самый дешевый способ получить такие знания — заплатить за них деньги.