1. Введение

Недавно я исследовал некоторое промежуточное ПО для сообщений, обычно используемый MQ, такой как RabbitMQ, ActiveMQ, Kafka и т. д. NSQ — это распределенная платформа для обмена сообщениями в реальном времени, основанная на языке Go, выпущенная на основе протокола с открытым исходным кодом MIT и представляющая собой простое в использовании промежуточное программное обеспечение для обмена сообщениями с открытым исходным кодом от компании bitly. Официальные лица и третьи стороны также разработали множество библиотек клиентских функций для NSQ, таких как официальная nsqd на основе HTTP, клиент Go go-nsq, клиент Python pynsq, клиент JavaScript на основе Node.js nsqjs и асинхронный клиент C libnsq, Java клиент nsq-java и множество сторонних клиентских библиотек на разных языках.

1.1 Features

1) DistributedNSQ обеспечивает распределенную децентрализованную топологию без единой точки отказа, стабильную передачу сообщений и гарантию публикации, а также может иметь характеристики высокой отказоустойчивости и высокой доступности (HA). 2) Масштабируемость легко расширяется. NSQ поддерживает горизонтальное расширение без централизованных брокеров. Встроенная служба обнаружения упрощает добавление узлов в кластер. Поддерживает как pub-sub, так и балансировку нагрузки рассылка сообщений. 3) Ops FriendlyNSQ очень легко настроить и развернуть, и он поставляется в комплекте с интерфейсом управления. Двоичные пакеты не имеют зависимостей во время выполнения. Есть официальный образ Docker. 4. Интегрированный высокоинтегрированный официальный Предоставляются библиотеки Go и Python. И библиотеки предоставляются для большинства языков.

1.2 Компоненты

• Тема. Тема — это логический ключ для программы, чтобы опубликовать сообщение, и тема создается, когда программа публикует сообщение в первый раз.

• Каналы: Каналы связаны с потребителями и балансируют нагрузку между потребителями.Каналы в некотором смысле представляют собой «очередь». Всякий раз, когда издатель отправляет сообщение в тему, сообщение будет реплицировано на все каналы, подключенные к потребителям.Потребители читают сообщение через этот специальный канал, который фактически создается при первой подписке потребителя. Канал поставит сообщения в очередь. Если нет потребителей для чтения сообщений, сообщения сначала будут поставлены в очередь в памяти, а когда их количество станет слишком большим, они будут сохранены на диск.

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

• nqd: nqd — это процесс-демон, отвечающий за получение, постановку в очередь и доставку сообщений клиентам. Он может работать независимо, но обычно он настраивается кластером, в котором находится экземпляр nsqlookupd (где он объявляет темы и каналы, чтобы каждый мог его найти).

• nsqlookupd: nsqlookupd — это демон, отвечающий за управление информацией о топологии. Клиент обнаруживает производителя указанной темы (topic), запрашивая nsqlookupd, и узел nqd передает информацию о теме (topic) и канале (channel). Есть два интерфейса: интерфейс TCP, который nqd использует для широковещательной рассылки. HTTP-интерфейс, который клиенты используют для обнаружения и управления.

• nsqadmin: nsqadmin — это набор веб-интерфейса, который используется для сбора статистики кластера в режиме реального времени и выполнения различных задач управления. Общие категории инструментов:

• nsq_to_file: использует указанную тему/канал и записывает в файл, опционально сворачивая и/или сжимая файл.

• nsq_to_http: использование указанной темы/канала и выполнение HTTP-запросов (GET/POST) к указанной конечной точке.

• nsq_to_nsq: Потребитель указывает тему/канал и повторно публикует сообщение в пункт назначения nqd через TCP.

1.3 Топология

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

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

Сообщения из каждого канала ставятся в очередь до тех пор, пока их не обработает рабочий процесс.Если очередь превышает лимит памяти, сообщение будет записано на диск. Узлы Nsqd сначала передают информацию о своем местоположении в nsqlookup, и после успешной регистрации рабочие обнаружат все узлы nsqd, содержащие темы событий, с узла сервера nsqlookup.

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

2. Internals

2.1 Гарантия доставки сообщений

NSQ гарантирует, что сообщения будут доставлены хотя бы один раз, хотя сообщения могут быть дублированы. Потребители должны обращать внимание на это и дедуплировать или выполнять такие действия, как idempotent. Эта гарантия предоставляется как часть протокола и рабочего процесса и работает следующим образом (при условии, что клиент успешно подключается и подписывается на тему): 1) Клиент указывает на то, что он готов получить сообщение 2) NSQ отправляет сообщение и временно хранить Данные локально (в реконструкции или тайм-аут) 3) клиент отвечает FIN (END) или REQ (RE-QUEEUE), указывающий на успех или сбой соответственно. Если клиент не отвечает, NSQ будет время ожидания после установленного времени и автоматически реквизировать сообщение Это гарантирует, что единственным возможным случаем потери сообщения является ненормальное завершение процесса NSQD. В этом случае любая информация, которая находится в памяти (или любом буфере, не промытой на диск), будет потеряна. Как предотвратить потери сообщений является наиболее важным, даже эта неожиданная ситуация может быть смягчена. Одним из решений состоит в том, чтобы сформировать избыточные пары NSQD (на разных хостах), чтобы получить копии одной и той же части сообщения. Поскольку потребитель, который вы реализуете, является IdEmpotent, обрабатывая эти сообщения в два раза длиннее не имеет никакого удара по потоку и позволяет системе выжить любой отказ от одного узла без потери информации.

2.2 Упрощает настройку и управление

Один экземпляр nqd предназначен для одновременной обработки нескольких потоков данных. Потоки называются «темами», а темы имеют 1 или более «каналов». Каждый канал получает копию всех сообщений в теме. На практике канал сопоставляется с темой потребления нижестоящих услуг. Ни темы, ни каналы предварительно не настроены. Темы создаются путем первой публикации сообщения в именованной теме или путем первой подписки на именованную тему. Канал создается первой подпиской на указанный канал. Все буферизованные данные по темам и каналам независимы друг от друга, что не позволяет медленным потребителям вызывать задержки на других каналах (то же самое относится и к уровню темы). Канал обычно имеет несколько клиентских подключений. Предполагая, что все подключенные клиенты готовы к приему сообщений, каждое сообщение будет доставлено случайному клиенту. nsqlookupd, который предоставляет службу каталогов, где потребители могут найти интересующие их подписанные темы. адрес nsqd. С точки зрения конфигурации отделите потребителей от производителей (оба должны знать только, где подключиться к общему экземпляру nsqlookupd, а не друг к другу), уменьшив сложность и обслуживание. На более низком уровне каждый nqd имеет долгоживущее TCP-соединение с nsqlookupd, периодически передающее свое состояние. Эти данные используются nsqlookupd для информирования потребителей об адресе nqd. Для потребителей для опроса используется открытый интерфейс HTTP/lookup. Чтобы представить нового потребителя темы, просто запустите его с настроенным nsqlookup. Клиент NSQ для адреса экземпляра. Для добавления новых потребителей или производителей не требуется никаких изменений конфигурации, что значительно снижает накладные расходы и сложность.

2.3 Устранение единых точек отказа

NSQ предназначен для распределенного использования. Клиент nqd подключается (через TCP) ко всем экземплярам производителя указанной темы. Здесь нет посредника, брокера сообщений и единой точки отказа. Эта топология исключает единую цепочку, агрегацию, обратную связь. Вместо этого ваши потребители имеют прямой доступ ко всем производителям. Технически, не имеет значения, какой клиент к какому NSQ подключается, пока есть достаточно потребителей, подключенных ко всем производителям, чтобы удовлетворить поток сообщений, гарантируется, что все в конечном итоге будет обработано. Для nsqlookupd высокая доступность достигается за счет запуска нескольких экземпляров. Они не взаимодействуют друг с другом напрямую, и данные в конечном итоге считаются непротиворечивыми. Потребитель опрашивает все настроенные экземпляр nsqlookupd и объединить ответы. Неисправный, недоступный или иным образом отказавший узел не остановит систему.

2.4 Эффективность

Для протоколов данных максимизируйте производительность и пропускную способность, отправляя данные клиентам, а не ожидая, пока клиенты извлекут данные. Эта концепция, называемая состоянием RDY, в основном представляет собой форму управления потоком на стороне клиента. Когда клиент подключается к nqd и подписывается на канал, он переходит в состояние RDY, равное 0. Это означает, что информация клиенту еще не отправлена. Когда клиент готов получать отправленные сообщения, он обновляет состояние своей команды RDY до числа, которое он готов обработать, например 100. Без каких-либо дополнительных инструкций, когда будет доступно 100 сообщений, они будут доставлены клиенту (серверная сторона каждый раз уменьшает количество сообщений для этого клиента). количество RDY). Клиентская библиотека предназначена для отправки команды для обновления счетчика RDY, когда счетчик RDY достигает 25% от настроенного максимального значения в полете (и назначается соответствующим образом в случае подключений к нескольким nsqds).

2.5 Сердцебиение и время ожидания

TCP-протокол NSQ ориентирован на push-уведомления. После установления соединения, рукопожатия и подписки потребитель помещается в состояние RDY, равное 0. Когда потребитель готов получать сообщения, он обновляет состояние RDY до количества сообщений, которые он готов принять. Клиентская библиотека NSQ постоянно управляет за кулисами результатом потока управления сообщениями. Время от времени nqd будет посылать пульс на соединение. Клиент может настроить интервал между тактами, но nqd будет ожидать ответа перед отправкой следующего пульса. Объединение тактов на уровне приложения и состояний RDY, чтобы избежать явления блокировки головы, которое также может сделать такты бесполезными (т. Е. Если потребитель находится в более позднем буфере приема, обрабатывая поток сообщений, ОС заполнится, блокируя пульс), чтобы гарантировать прогресс, все сети Ограничение времени ввода-вывода привязано к настроенному интервалу пульса. Это означает, что вы можете буквально отключить сетевое соединение между nqd и потребителем, и он будет правильно обнаруживать и обрабатывать ошибки. При обнаружении фатальной ошибки клиентское соединение принудительно закрывается. Время ожидания сообщений в пути истекает, и они повторно помещаются в очередь для доставки другому потребителю. Наконец, ошибки регистрируются и накапливаются в различных внутренних показателях.

2.6 Распределенный

Поскольку NSQ не обменивается информацией между демонами, он с самого начала создавался для распределенных операций. Отдельные машины можно выключать и запускать по желанию, не затрагивая остальную часть системы, а публикаторы сообщений могут публиковать локально, даже при наличии сетевых разделов. Эта философия дизайна «сначала дистрибуция» означает, что NSQ может продолжать масштабироваться вечно, нуждаясь в более высокой пропускной способности? Затем добавьте еще nqd. Единственное общее состояние хранится на узле поиска, даже если им не требуется глобальное представление, настройка некоторых nsqd для регистрации на некоторых узлах поиска. Это очень простая конфигурация, единственный ключевой момент заключается в том, что потребители могут получить всю полную информацию. через поиск node.node set. Очистить события сбоя — NSQ создает набор явных компромиссов между сбоями в компонентах относительно возможных сбоев, что имеет смысл как для доставки сообщений, так и для восстановления. Хотя они могут не обеспечивать такой строгий уровень гарантии, как системы Kafka, простота работы NSQ делает ситуации сбоя очень очевидными.

2.7 no replication

В отличие от других компонентов очередей, NSQ не обеспечивает какой-либо репликации и кластеризации, что делает его таким простым в использовании, но у него нет достаточных гарантий для какой-либо гарантированной высоконадежной публикации сообщений. Мы можем частично избежать этого, уменьшив время синхронизации файлов, просто настроив флаг для поддержки наших очередей через EBS. Но все еще бывает ситуация, когда сообщение умирает сразу после публикации, теряя действительные записи.

2.8 Нет строгого порядка

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

2.9 Отсутствие функции дедупликации данных

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

3. Попрактикуйтесь в процессе установки

В этой статье опущен конкретный процесс установки кластера nsq.Вы можете самостоятельно обратиться к официальному сайту, который относительно прост. Эта часть знакомит с топологией авторского эксперимента и соответствующей информацией о nsqadmin.

3.1 Топология

В эксперименте используются 3 службы NSQD и 2 службы LOOKUPD. При использовании официально рекомендованной топологии служба публикации сообщений и NSQD находятся на одном хосте. Всего 5 машин. NSQ принципиально не имеет конфигурационного файла, а в конфигурации задаются параметры через командную строку. Основные команды следующие: Команда ПРОСМОТР

                                    

                                        

                                            
bin
                                                /nsqlookupd
                                                    
                                                    
                                            
                                        
                                    
                                    скопировать код

команда NSQD

bin/nsqd --lookupd-tcp-address=172.16.30.254:4160 -broadcast-address=172.16.30.254
скопировать код

bin/nsqadmin --lookupd-http-address=172.16.30.254:4161
скопировать код

Класс инструмента, который сохраняется в локальном файле после использования.

bin/nsq_to_file --topic=newtest --channel=test --output-dir=/tmp --lookupd-http-address=172.16.30.254:4161
скопировать код

опубликовать сообщение

curl -d 'hello world 5' 'http://172.16.30.254:4151/put?topic=test'
скопировать код

3.2 nsqadmin

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

Список всех узлов NSQD:

Статистика сообщений:

Список поисковых хостов:

4. Резюме

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

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

В сочетании с нашей бизнес-системой мы относительно чувствительны к сообщениям о счетах, которые нам необходимо передать, и не можем допустить простоя определенного nsqd или неиспользуемого диска, а сообщения, накопленные на этом узле, не могут быть извлечены. Это основная причина, по которой мы не выбрали это промежуточное ПО для сообщений. Простота и надежность не удовлетворяют в полной мере. По сравнению с Kafka, ops берет на себя более ответственные операции. С другой стороны, у него есть воспроизводимый, упорядоченный журнал, который может служить нам лучше. Но для других потребителей, которым подходит NSQ, он сослужил нам хорошую службу, и мы с нетерпением ждем возможности продолжить работу на его прочном фундаменте.

Добро пожаловать, чтобы обратить внимание на мой общедоступный номер

---

ps: Эта статья была впервые опубликована в блоге csdn автора, и я добавлю ее в свой личный блог здесь.

Ссылаться на

1. NSQ: распределенная платформа обмена сообщениями в реальном времени.

2. NSQ - NYC Golang Meetup

3. NSQ Docs