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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Edit:

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

Горловина бутылки не обрабатывает, а дисковый ввод / вывод. Имейте много оперативной памяти и делайте в памяти столько, сколько можете.

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

Answer 5

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

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

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

Answer 6

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