Это вторая и заключительная часть блога - Распределенный обмен сообщениями с низкой задержкой с помощью RocketMQ. Мы расскажем о трех ключах к обеспечению емкости, архитектуре RocketMQ и будущей системе обмена сообщениями Alibaba Cloud.
Три ключа к обеспечению производительности
Гарантия оптимизации с низкой задержкой не обязательно может привести к ситуации без задержки для механизма обмена сообщениями. Чтобы обеспечить бесперебойную работу приложений, механизм обмена сообщениями требует гибкого планирования в зависимости от емкости. Как мы можем заставить систему с легкостью реагировать на огромные пики трафика? Чтобы решить эту проблему, необходимо рассмотреть три основных фактора задержки - деградацию, ограничение трафика и слияние. Гарантия ресурсов основных сервисов происходит за счет ухудшения качества и приостановки маржинальных сервисов и компонентов. Приоритет системы - не регистрировать сбой из-за пикового трафика.
С точки зрения стабильности архитектуры и ограниченных ресурсов возможности обслуживания, которые система может предоставлять в единицу времени, также ограничены. Вся служба может остановиться при превышении несущей способности, что приведет к сбою приложения, что может передать риск вызывающей стороне службы и вызвать недоступность службы для всей системы, что в конечном итоге приведет к лавине приложения. Кроме того, согласно теории очередей, среднее время отклика служб с задержками быстро увеличивается с увеличением количества запросов. Для обеспечения обслуживания SLA необходимо контролировать количество запросов в единицу времени. Поэтому ограничение трафика становится еще более важным.
Концепция ограничения трафика также известна в академическом мире как Traffic Shaping. Он возник в области сетевых коммуникаций, как правило, включая алгоритм дырявого ведра и алгоритм маркерного ведра. Ниже приводится дальнейшее объяснение:
Рисунок 1.
Основная идея алгоритма дырявого ведра состоит в том, что у нас есть протекающее ведро, из которого вода капает с постоянной скоростью, и кран над ним, из которого вода перетекает в ведро. Если вода льется быстрее, чем капает, ведро переполнится. В идеале это можно понимать как перегрузку запроса.
Основная идея токена, так же как алгоритм ведра относится к ведру, токены поступают в ведро с постоянной скоростью. Существует ограничение на количество токенов, которые могут попасть в корзину. Каждый запрос будет получать токен. Если на момент поступления запроса в корзине не осталось токенов, запросить результаты перегрузки. Это должно быть очевидно при резком всплеске запросов на токены ведра.
Рисунок 2.
Точнее, мы можем рассматривать либо дырявое ведро, либо ведро токенов, либо любой другой вариант этих алгоритмов как форму ограничения трафика, которая контролирует скорость трафика. Кроме того, существуют режимы ограничения трафика, которые управляют параллелизмом, такие как семафоры в операционной системе и семафоры в JDK.
Асинхронная развязка, сокращение времени пиковой нагрузки и смещение нагрузки - основные функции механизмов обмена сообщениями. Эти функции ориентированы на скорость движения, но нам все еще нужно подумать о некоторых необходимых средствах управления движением. В отличие от того, что мы упоминали ранее, стандартные компоненты скорости и управления трафиком, такие как Guava и Netty, не являются частью RocketMQ. Медленные запросы подвергаются отказоустойчивой обработке в соответствии с теорией организации очередей. Под медленными запросами здесь понимаются запросы со временем ожидания в очереди и временем обслуживания, превышающим указанный порог.
Для сценариев автономных приложений отказоустойчивая обработка использует механизм скользящего окна и путем медленного сворачивания окна, чтобы снизить частоту получения данных с сервера и размеры сообщений, а также минимизировать влияние на сервер. Для сценариев с высокочастотной торговлей и репликацией данных в системе есть стратегии быстрого отказа, применяемые для предотвращения лавин приложений, возникающих из-за цепочек приложений, вызывающих исчерпание ресурсов, и эффективно снижает нагрузку на сервер, эффективно гарантируя низкую сквозную задержку. .
Ухудшение качества обслуживания - типичный пример того, как жертвовать чем-то незначительным ради общего блага, в принципе, составляет 20–80% при практическом применении. Средством деградации является не что иное, как такая простая и грубая операция, как выключение сервера и перевод его в автономный режим. Выбор целей ухудшения в большей степени зависит от определения QoS. Первоначальная обработка деградации механизмами обмена сообщениями в основном происходит из двух аспектов: сбора пользовательских данных и настроек компонентов механизма QoS. В первом случае при передаче данных QoS приложения через системы эксплуатации и обслуживания, а также управления и контроля обычно выводится следующая таблица: для основных функций QoS компонентов двигателя, таких как модули цепной дорожки, обслуживающие отслеживание проблем с сообщениями, имеют низкую градацию и риск закрытия до наступления пика.
Мы не можем говорить о предохранителях без включения предохранителей в классической системе питания. В случае чрезмерных нагрузок, неисправностей цепи или исключений ток будет продолжать расти. Чтобы предотвратить возможное повреждение нарастающим током какого-либо критически важного или дорогостоящего компонента в цепи, сгорания цепи или даже возникновения пожара, плавкие предохранители прерывают ток, когда он быстро повышается до определенного уровня или нагревается, чтобы защитить безопасную работу. схемы.
Кроме того, в распределенных системах, если удаленные службы или ресурсы недоступны по какой-либо причине, отсутствие защиты от перегрузки блокирует запрошенные ресурсы на сервере, заставляя его ждать, тем самым используя ресурсы системы или сервера. Во многих случаях изначально возникают только локальные или мелкие системные сбои. Однако по разным причинам масштабы воздействия этих разломов увеличиваются и в конечном итоге приводят к глобальным последствиям. Этот тип защиты от перегрузки широко известен как автоматический выключатель. Чтобы решить эту проблему, Netflix открыл исходный код своего фьюзингового решения Hystrix.
Рисунок 3.
Рисунок 4.
Рисунок 5.
Три изображения выше описывают сценарии работы системы от начального состояния работоспособности до состояния блокировки в некоторых ключевых зависимых компонентах в нисходящем направлении в сценарии с высоким уровнем параллелизма. Практически такая ситуация может легко вызвать лавину. Внедрение механизма слияния Hystrix позволяет приложениям быстро выходить из строя и позволяет избежать наихудшего сценария.
Рисунок 6.
Ссылаясь на идею Hystrix, команда Alibaba Cloud разработала набор механизмов объединения механизмов обмена сообщениями. Во время нагрузочного тестирования были случаи, когда сервисы были недоступны из-за сбоя оборудования компьютера. При использовании обычных средств обеспечения отказоустойчивости требуется 30 секунд, прежде чем недоступный компьютер перестанет быть частью списка. Однако с помощью этого набора механизмов объединения можно идентифицировать и изолировать затронутые службы за миллисекунды. Таким образом, идея еще больше повышает доступность двигателей.
Решения с высокой доступностью
Хотя мы рекомендуем полагаться на три фактора, влияющих на гарантию мощности; однако по мере того, как масштаб кластеров механизмов обмена сообщениями увеличивается равномерно до определенной степени, вероятность компьютерных ошибок в кластере становится выше. Это значительно снижает надежность сообщений и доступность системы. В то же время кластерные режимы, основанные на развертывании нескольких серверных комнат, также приведут к нарушению сети в серверных комнатах, что еще больше снизит доступность систем обмена сообщениями.
Чтобы решить эту проблему, команда Alibaba Cloud представила высокодоступные решения на основе нескольких реплик, которые позволяют динамически идентифицировать сценарии бедствий, такие как сбои компьютеров и разорванные сети в серверных комнатах. Кроме того, решения позволяют автоматическое восстановление после сбоев. Весь процесс восстановления прозрачен для пользователей и не требует вмешательства обслуживающего и обслуживающего персонала. Этот аспект значительно повысил надежность хранения сообщений и повысил доступность всего кластера.
Повышенная доступность - важная особенность, которую необходимо учитывать почти в каждой распределенной системе. Основываясь на принципе CAP (согласованность, доступность и разделение), невозможно одновременно удовлетворить допуск в распределенной системе. Ниже приведены некоторые общие высокодоступные решения, предлагаемые для распределенных систем в отрасли:
Рисунок 7.
Строки представляют высокодоступные решения в распределенных системах, включая холодное резервное копирование, главный / подчиненный, главный / главный, 2PC и решения на основе алгоритмов Paxos. Столбцы представляют индикаторы, которые формируют основное внимание распределенных систем, включая согласованность данных, уровень поддержки транзакций, задержку данных, пропускную способность системы, возможность потери данных, а также режим восстановления после аварийного переключения.
Как видно из рисунка, степень поддержки индикаторов зависит от решения. Основываясь на принципе CAP, сложно разработать высокодоступное решение, способное соответствовать оптимальным значениям всех показателей. В случае системы ведущий / ведомый, например, она обычно соответствует следующим характеристикам:
• Установка количества ведомых устройств в зависимости от степени важности данных.
Данные попадают в мастер при записи запросов и в главный или подчиненный сервер при чтении запросов.
• После попадания в ведущее устройство при записи запросов репликация данных происходит от ведущего устройства к ведомому в синхронном или асинхронном режиме. Для режима синхронной репликации необходимо убедиться, что и ведущий, и ведомый успешно записывают данные, прежде чем сообщать клиенту об успешном выполнении. Для режима асинхронной репликации необходимо только убедиться, что мастер успешно записывает данные, прежде чем сообщать клиенту об успешном выполнении.
Учитывая возможность копирования данных с ведущего устройства на ведомое устройство синхронным или асинхронным образом, структура ведущего / ведомого устройства может, по крайней мере, гарантировать окончательную согласованность данных. В режиме асинхронной репликации, когда можно сообщить клиенту об успешном завершении успешной записи данных в ведущее устройство, система имеет меньшую задержку и более высокую пропускную способность, но потеря данных все еще возможна из-за неисправности ведущего устройства.
Если не ожидается, что потеря данных будет фактором отказа ведущего устройства в режиме асинхронной репликации, ведомое устройство может только ждать восстановления ведущего устройства в режиме только для чтения, увеличивая время восстановления после сбоев системы. С другой стороны, режим синхронной репликации в структуре «ведущий / ведомый» гарантирует отсутствие потери данных из-за поломки компьютера и сокращает время восстановления после сбоев системы за счет увеличения задержек при записи данных и снижения пропускной способности системы.
Архитектура высокой доступности RocketMQ
Основанный на первоначальном развертывании нескольких серверных комнат, режим кластера RocketMQ использует распределенные блокировки и механизмы уведомления с помощью компонентного контроллера для разработки и достижения высокодоступной архитектуры структуры главный / подчиненный, как показано ниже:
Рисунок 8.
В качестве среды распределенного планирования Zookeeper требует развертывания как минимум трех серверных комнат A, B и C, чтобы обеспечить его доступность и предоставить следующие функции для высокодоступной архитектуры RocketMQ:
• Поддерживайте НАСТОЯЩИЕ узлы и сохраняйте машинные состояния ведущего / ведомого устройства;
• Поддерживать EPHEMERAL узлы и сохранять текущее состояние RocketMQ;
• Уведомлять соответствующих наблюдателей в случае любых изменений текущего состояния машинных состояний главного / подчиненного серверов.
RocketMQ обеспечивает одноранговое развертывание нескольких серверных комнат со структурой главный / подчиненный. Запросы на запись сообщений будут попадать в ведущее устройство и реплицироваться на ведомое устройство для постоянного хранения в синхронном или асинхронном режиме; Запросы на чтение сообщений в приоритетном порядке будут попадать на ведущее устройство, а затем переместятся на ведомое устройство при накоплении сообщений, вызывая большее давление на диск. RocketMQ напрямую взаимодействует с Zookeeper:
• Отчетность о текущем состоянии в Zookeeper в виде EPHEMERAL узлов;
• Наблюдение за изменением состояния машины ведущего / ведомого на Zookeeper в качестве наблюдателя. Если мы обнаружим какое-либо изменение в состоянии машины ведущего / ведомого, текущее состояние изменится в соответствии с новым состоянием машины;
Контроллер высокой доступности RocketMQ - это компонент без сохранения состояния в высокодоступной архитектуре механизмов обмена сообщениями для сокращения времени восстановления после сбоев системы, развернутый отдельно в серверных комнатах A, B и C. Он в основном служит для:
• Следите за изменением текущего состояния RocketMQ в Zookeeper в качестве наблюдателя.
• Управлять переключением состояния машины ведущий / ведомый на основе текущего состояния кластера и сообщать Zookeeper о новом состоянии компьютера ведущего / ведомого
Учитывая сложность системы и адаптируемость самого механизма обмена сообщениями к принципу CAP, конструкция высокодоступной архитектуры RocketMQ использует структуру ведущий / ведомый. Основываясь на предоставлении услуг обмена сообщениями с низкой задержкой и высокой пропускной способностью, система использует репликацию синхронизации главный / подчиненный, чтобы избежать потери сообщений из-за сбоев.
В процессе синхронизации данных поддержание инкрементного и глобально уникального SequenceID обеспечит надежную согласованность данных. В системе одновременно реализован механизм автоматического восстановления после сбоев, чтобы сократить время восстановления и повысить доступность системы.
Оценка доступности
Доступность системы - это способность информационной системы обеспечивать непрерывное обслуживание, измеряемое в информационной индустрии. Он указывает на вероятность того, что система или ее способность нормально работать в определенной среде, в течение заданного временного интервала. Короче говоря, доступность - это результат среднего времени наработки на отказ (MTBF), деленного на сумму MTBF и среднего времени восстановления (MTTR), а именно:
Обычной практикой в отрасли является представление доступности системы числом девяток. Например, три девятки означают, что доступность составляет не менее 99,9%, что означает, что продолжительность недоступности в течение года находится в пределах 8,76 часов. Доступность 99,999%, или пять девяток, означает, что продолжительность недоступности в течение года должна быть в пределах 5,26 минуты. Система без автоматического восстановления после сбоев не может обеспечить доступность «пять девяток».
Гарантия высокой доступности RocketMQ
Как видно из формулы доступности, для повышения доступности системы критически важно еще больше повысить способность системы автоматически восстанавливаться после сбоев, чтобы сократить среднее время восстановления (MTTR) на основе обеспечения устойчивости системы для увеличения времени наработки на отказ. В высокодоступной архитектуре RocketMQ был разработан и реализован компонентный контроллер, который переключает конечный автомат в следующем порядке: состояние единственного ведущего, состояние асинхронной репликации, состояние полусинхронизации и состояние конечной синхронной репликации. В конечном состоянии синхронной репликации, если сбой происходит на каком-либо главном и подчиненном узлах, другие узлы могут переключиться в состояние с одним главным в течение нескольких секунд, чтобы продолжить предоставление услуг. По сравнению с ранее использовавшимся ручным вмешательством для восстановления обслуживания, высокодоступная архитектура RocketMQ предлагает возможность автоматического восстановления после сбоев системы, существенно сокращая время восстановления работоспособности и повышая доступность системы.
На рисунке ниже показано переключение конечных автоматов в архитектуре высокой доступности RocketMQ:
Рисунок 9
• После запуска первого узла Контроллер управляет состоянием машины, чтобы переключиться в состояние с одним ведущим, и уведомляет инициированный узел о предоставлении услуг в качестве ведущего.
• После запуска второго узла Контроллер управляет конечным автоматом для переключения в состояние асинхронной репликации. Мастер реплицирует данные на подчиненное устройство в асинхронном режиме.
• Когда данные ведомого устройства собираются догнать данные ведущего, Контроллер управляет конечным автоматом для переключения в состояние полусинхронизации, что обеспечивает удержание запроса записи, поступающего на ведущее устройство, до тех пор, пока ведущее устройство не реплицирует данные все неточности до раб в асинхронном режиме.
• В полусинхронном состоянии, когда данные ведомого устройства полностью совпадают с данными ведущего, Контроллер управляет конечным автоматом, чтобы переключиться в режим синхронной репликации. Мастер начинает реплицировать данные на подчиненное устройство в синхронном режиме. Если в каком-либо узле в этом состоянии происходит сбой, другие узлы могут переключиться в состояние с одним ведущим в течение нескольких секунд, чтобы продолжить предоставление услуг.
Компонент контроллера управляет RocketMQ для переключения конечного автомата в порядке состояния одиночного ведущего, состояния асинхронной репликации, состояния полусинхронизации и состояния конечной синхронной репликации. Продолжительность промежуточных состояний является фактором несоответствия данных ведущего / ведомого устройства и пропускной способности сети. Однако в конечном итоге они останутся в состоянии синхронной репликации.
Заключение
После нескольких лет онлайн-тестов, таких как тесты, все еще есть возможности для оптимизации механизма обмена сообщениями Alibaba Cloud. Команда пытается еще больше уменьшить задержку хранения сообщений с помощью алгоритмов оптимизации хранения и межъязыковых вызовов. Перед появлением новых сценариев, таких как Интернет вещей, большие данные и виртуальная реальность, команда приступила к созданию механизмов обмена сообщениями 4-го поколения с многоуровневым протоколом QoS. Кроме того, он также имеет кросс-сетевую, кросс-терминальную и кросс-языковую поддержку, меньшее время отклика для онлайн-приложений и более высокую пропускную способность для офлайн-приложений. В идее взять от открытого исходного кода и вернуть тот же открытый исходный код, мы верим, что RocketMQ будет развиваться в направлении более здоровой экологии.
Ссылка
[1] Райан Барретт. Http://snarfed.org/transactions_across_datacenters_io.html
[2] http://www.slideshare.net/vimal25792/leaky-bucket-tocken-buckettraffic-shaping
[3] Http://systemdesigns.blogspot.com/2015/12/rate-limiter.html
[4] Little JDC, Graves S. C. Закон Литтла [M] // Построение интуиции. Springer US, 2008: 81–100.
[5] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Performance_Tuning_Guide/index.html
[6] http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html
[7] Https://www.azul.com/files/EnhibitedJavaInLatencySensitiveEnvs_DotCMSBootcamp_Nashville_23Oct20141.pdf
