предисловие
Высокий параллелизм — это опыт, который хочет иметь почти каждый программист. Причина очень проста: по мере увеличения трафика будут возникать различные технические проблемы, такие как тайм-аут ответа интерфейса, увеличение загрузки процессора, частый GC, тупик, большой объем хранилища данных и т. д. Постоянное улучшение технической глубины.
В качестве преимущества чтения редактор также составил набор заметок, связанных с высокой степенью параллелизма (включая карты мозга, интервью, рукописные PDF-файлы и т. д.), и теперь бесплатно предоставляет их Java-программистам, которые читают эту статью.
Наиболее полные заметки об исследовании с высокой степенью параллелизма + вопросы для интервью
На прошлых собеседованиях, если кандидат работал над проектом с высокой степенью параллелизма, я обычно прошу другого человека рассказать о своем понимании высокой степени параллелизма, но не так много людей могут систематически ответить на этот вопрос, который можно условно разделить на следующие категории:
1. Отсутствие концепции показателей, основанных на данных: Не ясно, какую метрику выбрать для измерения системы с высокой степенью параллелизма? Не могу определить разницу между параллелизмом и количеством запросов в секунду и даже не знаю ключевых данных, таких как общее количество пользователей, активных пользователей, количество запросов в секунду и количество транзакций в секунду во время фиксированных и пиковых периодов.
2. Некоторые планы были разработаны, но детали не полностью поняты: Не могу назвать технические моменты и возможные побочные эффекты, на которые программа должна обратить внимание. Например, если есть узкое место в производительности чтения, будет введен кеш, но такие проблемы, как частота попаданий в кеш, горячие клавиши и согласованность данных, игнорируются.
3. Поймите односторонность и приравняйте дизайн с высокой степенью параллелизма к оптимизации производительности.: Говорит о параллельном программировании, многоуровневом кэшировании, асинхронности и горизонтальном расширении, но игнорирует проектирование высокой доступности, управление службами, а также гарантии эксплуатации и обслуживания.
4. Освойте большой план, но игнорируйте самые основные вещи: я могу ясно объяснить основные идеи вертикального многоуровневого, горизонтального секционирования, кэширования и т. д., но у меня нет достаточной осведомленности, чтобы проанализировать, разумна ли структура данных и эффективен ли алгоритм. Я никогда не думал об оптимизации деталей. от самых фундаментальных измерений ввода-вывода и вычислений.
В этой статье я хочу систематически обобщить знания и практические идеи, которые необходимо освоить для обеспечения высокого уровня параллелизма, основываясь на собственном опыте работы с проектами с высоким уровнем параллелизма. Надеюсь, это будет вам полезно. Содержание разделено на следующие 3 части:
- Как понять высокий параллелизм?
- Каковы цели проектирования системы с высокой степенью параллелизма?
- Каковы практические решения для высокой параллелизма?
Как понять высокий параллелизм?
Высокий параллелизм означает большой трафик, и необходимо использовать технические средства, чтобы противостоять влиянию трафика.Эти методы похожи на операционный трафик, который может сделать трафик более плавно обрабатываемым системой и повысить удобство работы пользователей.
Наши распространенные сценарии с высокой степенью параллелизма включают в себя: Taobao Double 11, захват билетов во время путешествия на Весенний фестиваль, горячие новости от Weibo big V и т. д. В дополнение к этим типичным вещам, система шипов с сотнями тысяч запросов в секунду, система заказов с десятками миллионов заказов в день и система информационных потоков с сотнями миллионов ежедневных действий могут быть классифицированы как высокий параллелизм.
Очевидно, что упомянутые выше сценарии с высокой степенью параллелизма имеют разные объемы параллелизма.Итак, сколько параллелизма считается высоким параллелизмом?
1. Вы можете смотреть не только на цифры, но и на конкретные бизнес-сценарии. Нельзя сказать, что seckill 10W QPS — это высокий параллелизм, а информационный поток 1W QPS — не высокий параллелизм. Сценарий информационного потока включает в себя сложные рекомендательные модели и различные ручные стратегии, а его бизнес-логика может быть более чем в 10 раз сложнее, чем сценарий всплеска. Поэтому не в одном измерении нет смысла сравнения.
2. Бизнес ведется от 0 до 1. Параллелизм и QPS являются лишь ориентировочными показателями. Самое главное: в процессе постепенного увеличения объема бизнеса в 10 или 100 раз от исходного, использовали ли вы высокий параллелизм? системы, предотвращать и решать проблемы, вызванные высокой степенью параллелизма, в аспектах проектирования архитектуры, реализации кода и даже продуктовых решений? Вместо того, чтобы просто модернизировать оборудование и добавлять машины для горизонтального расширения.
Кроме того, бизнес-характеристики каждого сценария с высокой степенью параллелизма совершенно разные: есть сценарии информационных потоков с большим количеством операций чтения и меньшим количеством операций записи, а также сценарии транзакций с большим количеством операций чтения и записи.Существует ли общее техническое решение для решения проблемы высокого параллелизма в различных сценариях?
Я думаю, что большие идеи можно использовать для справки, как и планы других людей, но в фактическом процессе реализации в деталях будет бессчетное количество ям. Кроме того, поскольку программная и аппаратная среда, стек технологий и логика продукта не могут быть полностью согласованы, это приведет к одному и тому же бизнес-сценарию, и даже при использовании одного и того же технического решения возникнут разные проблемы.
Поэтому в этой статье я сосредоточусь на базовых знаниях, общих идеях и практическом опыте, надеясь дать вам более глубокое понимание высокой параллелизма.
Каковы цели проектирования системы с высокой степенью параллелизма?
Целесообразно и уместно обсудить план проектирования и практический опыт на основе выяснения целей проектирования системы с высокой степенью параллелизма.
2.1 Макроцели
Высокий параллелизм означает не только стремление к высокой производительности, что является односторонним пониманием многих людей. С макроэкономической точки зрения проектирование системы с высокой степенью параллелизма преследует три цели: высокая производительность, высокая доступность и высокая масштабируемость.
1. Высокая производительность: производительность отражает способность системы к параллельной обработке данных.При ограниченном вводе аппаратного обеспечения повышение производительности означает снижение затрат. В то же время производительность также отражает пользовательский опыт.Время отклика составляет 100 миллисекунд и 1 секунду соответственно, что дает пользователям совершенно другой опыт.
2. Высокая доступность: указывает время, когда система может нормально работать. У одного нет простоев и сбоев в течение года, у другого интернет-аварии и простои раз в три-пять раз, пользователи однозначно выберут первое. Кроме того, если система может быть доступна только на 90%, это сильно затормозит бизнес.
3. Высокая степень расширения: Указывает на возможность расширения системы, может ли расширение быть завершено за короткий период времени, когда трафик достигает пика, и может ли пик трафика быть более плавным, например, событие Double 11, развод знаменитостей и другие горячие события.Эти три цели необходимо рассматривать вместе, поскольку они взаимосвязаны и даже влияют друг на друга.
Например, принимая во внимание масштабируемость системы, вы спроектируете службу без сохранения состояния.Такой кластерный дизайн обеспечивает высокую масштабируемость и фактически косвенно повышает производительность и доступность системы.
Другой пример: Для обеспечения доступности обычно устанавливается тайм-аут для интерфейса службы, чтобы большое количество потоков не блокировало медленные запросы и не вызывало системную лавину. Как правило, мы будем ссылаться на производительность зависимых сервисов для установки.
2.2 Микроцели
С микроперспективы, каковы конкретные показатели для измерения высокой производительности, высокой доступности и высокой степени расширения? Почему именно эти индикаторы?
2.2.1 Индекс производительности
Показатели производительности можно использовать для измерения текущих проблем с производительностью и в то же время в качестве основы оценки для оптимизации производительности. Вообще говоря, в качестве индикатора используется время отклика интерфейса за определенный период времени.
1. Среднее время отклика: чаще всего используется, но дефект очевиден, и не чувствителен к медленным запросам. Например, если есть 10 000 запросов, из которых 9 900 — 1 мс и 100 — 100 мс, среднее время ответа составляет 1,99 мс, хотя среднее время увеличилось всего на 0,99 мс, время ответа 1% запросов увеличилось в 100 раз. .
2. Квантильные значения, такие как TP90 и TP99: отсортируйте время отклика от меньшего к большему, TP90 представляет время отклика, ранжированное в 90-м квантиле, и чем больше значение квантиля, тем более оно чувствительно к медленным запросам.3. Пропускная способность: обратно пропорциональна времени отклика.Например, если время отклика составляет 1 мс, пропускная способность составляет 1000 раз в секунду.
Обычно пропускная способность и время отклика учитываются при установке целей производительности, например, менее 10 000 запросов в секунду, AVG контролируется ниже 50 мс, а TP99 контролируется ниже 100 мс. Для систем с высокой степенью параллелизма квантили AVG и TP должны учитываться одновременно.
Кроме того, с точки зрения пользовательского опыта, 200 миллисекунд считаются первой демаркационной точкой, пользователь не чувствует задержки, а 1 секунда является второй демаркационной точкой, пользователь может почувствовать задержку, но это приемлемо. .
Таким образом, для исправной системы с высокой степенью параллелизма TP99 должен контролироваться в течение 200 миллисекунд, а TP999 или TP9999 — в течение 1 секунды.
2.2.2 Показатели доступности
Высокая доступность означает, что система имеет высокую способность работать без сбоев.Доступность = нормальное время работы / общее время работы системы.Как правило, для описания доступности системы используется несколько девяток.Для системы с высокой степенью параллелизма самое основное требование — обеспечить 3 девятки или 4 девятки. Причина очень проста. Если вы можете достичь только 2 9 с, это означает, что существует 1% времени отказа. Например, некоторые крупные компании могут легко генерировать более 100 миллиардов GMV или выручки каждый год, а 1% - это 1 миллиардное влияние на бизнес.
2.2.3 Показатели масштабируемости
В условиях всплеска трафика временно преобразовать архитектуру невозможно, самый быстрый способ — добавить машины для линейного увеличения вычислительной мощности системы.
Для бизнес-кластеров или базовых компонентов масштабируемость = коэффициент повышения производительности / коэффициент добавления машин Идеальная масштабируемость: ресурсы увеличиваются в несколько раз, а производительность увеличивается в несколько раз. Вообще говоря, способность расширения должна поддерживаться выше 70%.
Однако с точки зрения общей архитектуры системы с высокой степенью параллелизма цель расширения состоит не только в том, чтобы спроектировать службу без сохранения состояния, поскольку при увеличении трафика в 10 раз бизнес-служба может быть быстро расширена в 10 раз. , но база данных может стать новым узким местом.
Служба хранения с отслеживанием состояния, такая как MySQL, обычно представляет собой техническую сложность в масштабировании: если архитектура не спланирована заранее (вертикальное и горизонтальное разбиение), это повлечет за собой миграцию большого объема данных.
Следовательно, необходимо учитывать высокую масштабируемость: промежуточное ПО, такое как сервисные кластеры, базы данных, кэши и очереди сообщений, балансировка нагрузки, пропускная способность, зависимые третьи стороны и т. д. Когда параллелизм достигает определенного порядка, каждый из вышеперечисленных факторов может стать масштабируемое узкое место.
Каковы практические решения для высокой параллелизма?
Поняв 3 основные цели проектирования с высокой степенью параллелизма, затем систематически обобщите схему проектирования с высокой степенью параллелизма, которая будет расширена из следующих двух частей: сначала суммируйте общие методы проектирования, а затем сосредоточьтесь на высокой производительности, высокой доступности и высокой степени расширения. y разработать конкретные методы.
3.1 Общий метод проектирования
Общий метод проектирования в основном начинается с двух измерений «вертикального» и «горизонтального», широко известных как две оси обработки с высокой степенью параллелизма: вертикальное расширение и горизонтальное расширение.
3.1.1 Масштабирование
Его цель - повысить вычислительную мощность одной машины, и программа включает в себя:
1. Улучшить аппаратную производительность отдельной машины: за счет увеличения количества памяти, ядер ЦП, емкости хранилища или обновления диска до SSD и другого оборудования для кучи.
2. Улучшите производительность программного обеспечения на одной машине: используйте кэш для сокращения времени ввода-вывода и используйте параллельные или асинхронные методы для увеличения пропускной способности.
3.1.2 Масштабирование
Поскольку производительность одной машины всегда ограничена, в конечном итоге необходимо ввести горизонтальное расширение и дополнительно улучшить возможности параллельной обработки за счет развертывания кластера, включая следующие два направления:
1. Хорошо поработайте над многоуровневой архитектурой: это шаг вперед в горизонтальном расширении, потому что системы с высоким параллелизмом часто имеют сложный бизнес, а сложные проблемы могут быть упрощены за счет многоуровневой обработки, что упрощает достижение горизонтального расширения.Приведенная выше диаграмма представляет собой наиболее распространенную многоуровневую архитектуру в Интернете.Конечно, реальная архитектура системы с высокой степенью параллелизма будет в дальнейшем улучшаться на этой основе. Например, будет выполнено динамическое и статическое разделение и будет введен CDN.Обратный прокси-уровень может быть LVS+Nginx, веб-уровень может быть унифицированным API-шлюзом, уровень бизнес-сервисов может быть дополнительно микросервисным в соответствии с вертикальным бизнесом и уровнем хранения могут быть различные разнородные базы данных.
2, каждый слой горизонтально расширен: горизонтальное расширение без сохранения состояния, есть статус маршрутов фрагментации. Бизнес-кластеры обычно могут быть спроектированы так, чтобы они не сохраняли состояние, а базы данных и кеш часто являются состояниями, поэтому вам необходимо разработать ключ раздела, чтобы сделать хороший фрагмент хранилища, конечно, также может повысить производительность чтения за счет основного разделения чтения-записи. .
3.2 Конкретные практические решения
Далее, основываясь на своем личном опыте, я суммирую практические решения, которые могут быть реализованы в трех аспектах: высокая производительность, высокая доступность и высокая степень расширения.
3.2.1 Высокопроизводительные практические решения
1. Развертывание кластера снижает нагрузку на отдельные машины за счет балансировки нагрузки.
2. Многоуровневое кэширование, включая использование CDN для статических данных, локальное кэширование, распределенное кэширование и т. д., а также решение таких проблем, как горячие клавиши, проникновение в кэш, параллелизм кэша и согласованность данных в сценариях кэширования.
3. Оптимизация подтаблиц и индексов подбазы данных, а также решение сложных проблем с запросами с помощью поисковых систем.
4. Рассмотрите возможность использования баз данных NoSQL, таких как HBase, TiDB и т. д., но команда должна быть знакома с этими компонентами и обладать мощными возможностями эксплуатации и обслуживания.
5. Асинхронный, вторичный процесс асинхронно обрабатывается посредством многопоточности, MQ и даже отложенных задач.
6. Ограничение тока. Вам необходимо рассмотреть, допускает ли бизнес ограничение тока (например, разрешены сценарии seckill), включая ограничение тока внешнего интерфейса, ограничение тока на уровне доступа Nginx и ограничение тока на стороне сервера.
7. Сократите пики и заполните долины для трафика и проведите трафик через MQ.
8. Параллельная обработка, распараллеливание последовательной логики посредством многопоточности.
9. Предварительный расчет, такой как сцена захвата красного конверта, вы можете заранее рассчитать сумму красного конверта и кэшировать ее, а также использовать ее непосредственно при отправке красных конвертов.
10. Предварительный нагрев кеша, предварительный нагрев данных в локальный или распределенный кеш заранее с помощью асинхронных задач.
11. Сократите количество операций ввода-вывода, таких как пакетное чтение и запись баз данных и кэшей, поддержка пакетного интерфейса RPC или уничтожение вызовов RPC с помощью избыточных данных.
12. Уменьшить размер пакета данных во время ввода-вывода, в том числе принять облегченный протокол связи, соответствующую структуру данных, удалить избыточные поля в интерфейсе, уменьшить размер ключа кэша, сжать значение кэша и т. д.
13. Оптимизация логики программы, например предварительное позиционирование логики суждения, которая с высокой вероятностью блокирует процесс выполнения, оптимизация логики вычислений цикла For или использование более эффективного алгоритма.
14. Использование различных технологий объединения и настроек размера пула, включая пулы HTTP-запросов, пулы потоков (учитывайте параметры с интенсивным использованием ЦП или IO для основных параметров), пулы соединений с базой данных и Redis и т. д.
15. Оптимизация JVM, в том числе размер нового поколения и старого поколения, выбор алгоритма GC и т. д., чтобы максимально снизить частоту и время GC.
16. Блокируйте выбор, используйте оптимистическую блокировку в сценариях с большим объемом чтения и меньшим объемом записи или рассмотрите возможность уменьшения конфликтов блокировок с помощью сегментированной блокировки.
Приведенное выше решение представляет собой не что иное, как рассмотрение всех возможных точек оптимизации из двух измерений вычислений и ввода-вывода.Необходимо иметь поддерживающую систему мониторинга, чтобы понять текущую производительность в режиме реального времени, и помочь вам проанализировать узкое место производительности, а затем Следуйте принципу двух-восьми, чтобы понять основное противоречие.
3.2.2 Методы обеспечения высокой доступности
1. Аварийное переключение одноранговых узлов, как Nginx, так и платформы управления услугами поддерживают доступ к другому узлу после сбоя одного узла.
2. Отказоустойчивость неравноправных узлов определяется пульсом и реализует переключение ведущий-подчиненный (например, дозорный режим или кластерный режим Redis, переключение ведущий-подчиненный MySQL и т. д.).
3. Настройка времени ожидания, стратегия повторных попыток и идемпотентный дизайн на уровне интерфейса.
4. Обработка перехода на более раннюю версию: обеспечение основных служб, отказ от неосновных служб и, при необходимости, слияние; или, когда возникает проблема с основным каналом, существует альтернативный канал.
5. Обработка ограничения тока: непосредственно отклоните или верните код ошибки в запросы, которые превышают мощность системы системы.
6. Обеспечение надежности сообщений в сценариях MQ, включая механизм повторных попыток на стороне производителя, постоянство на стороне брокера, механизм подтверждения на стороне потребителя и т. д.
7. Версия в оттенках серого, которая может поддерживать развертывание небольшого трафика в соответствии с размерами машины, отслеживать системные журналы и бизнес-показатели, а затем передавать полный объем после того, как работа станет стабильной.
8. Мониторинг и оповещение: комплексная система мониторинга, включающая базовый мониторинг ЦП, памяти, диска и сети, а также мониторинг веб-серверов, JVM, баз данных, различного промежуточного программного обеспечения и бизнес-показателей.
9. Отработка аварийного восстановления. Подобно нынешней «инженерии хаоса», в системе применяются некоторые деструктивные меры, чтобы определить, не вызовут ли локальные сбои проблемы с доступностью.
Решение высокой доступности в основном учитывает три направления: избыточность, компромисс, эксплуатация и техническое обслуживание системы. В то же время оно должно иметь вспомогательный механизм работы и процесс обработки сбоев. Когда возникают онлайн-проблемы, их можно отслеживать и обработаны вовремя.
3.2.3 Практики высокой экспансии
1. Разумная многоуровневая архитектура: например, наиболее распространенная многоуровневая архитектура Интернета, упомянутая выше, кроме того, микросервисы могут быть дополнительно разделены на более мелкие уровни в соответствии с уровнем доступа к данным и уровнем бизнес-логики (но производительность требует для оценки, а в сети есть еще один переход).
2. Разделение уровня хранения: вертикальное разделение в соответствии с бизнес-измерением и дальнейшее горизонтальное разделение в соответствии с измерением признаков данных (подбиблиотека и подтаблица).
3. Разделение бизнес-уровня: наиболее распространенным является разделение в соответствии с бизнес-измерениями (такими как товарные услуги, услуги по заказу и т. д. в сценариях электронной коммерции), или в соответствии с основными интерфейсами и неосновными интерфейсами, или в соответствии с источники запросов (такие как To C и B, APP и H5).
напиши в конце
Высокий уровень параллелизма действительно является сложной и систематической проблемой.Из-за ограниченного объема необходимо учитывать такие технические аспекты, как распределенная трассировка, полносвязное стресс-тестирование и гибкие транзакции. Кроме того, если бизнес-сценарии различны, планы реализации с высокой степенью параллелизма также будут другими, но общие идеи дизайна в основном аналогичны решениям, которые можно использовать для справки.
Проектирование с высокой степенью параллелизма также соответствует трем принципам архитектурного проектирования: простота, уместность и развитие. "Преждевременная оптимизация - корень всех зол". Ее нельзя отделить от реального положения дел в бизнесе, не говоря уже о перепланировке. Правильное решение - самое совершенное.
Я надеюсь, что эта статья может дать вам более полное представление о высоком параллелизме.Если у вас также есть опыт и глубокое мышление, из которых вы можете извлечь уроки, оставьте сообщение в области комментариев для обсуждения. Наконец, не забудьте поставить лайк + подписаться, и позже мы обновим больше знаний, связанных с Java!