Приветствую всех вОблако Tencent + сообщество, получить больше крупной технической практики Tencent по галантерее ~
Эта статья написанаmariolu Опубликован вКолонка «Облако + сообщество»
Предисловие (первоначальное намерение)
Первоначальная цель разработки этой системы состоит в том, чтобы проанализировать взаимосвязь между дисковым хранилищем прокси-сервера кэширования и скоростью возврата на основе описания бизнес-модели (или кластера машин) хранения. Значение системы заключается в количественном руководстве расширением оборудования компьютерного зала в процессе оптимизации затрат Tencent Cloud. Первая половина — введение в предысторию и теоретические размышления о модели кэширования CDN. Во второй половине фактически будет построена миниатюрная, но хорошо оборудованная распределенная общая системная архитектура, и, наконец, система получит некоторые фоновые функции для решения практических проблем, возникающих при оптимизации затрат.
Схема модели хранения сервера кэша (фон):
Онлайн-маршрутизация Tencent CDN заключается в том, что пользователи à OC->SOC->SMid->исходные станции распределены по разным регионам и операторам. Каждый узел уровня развертывается с сервером кэширования. Часть трафика запросов от пользователя попадает на сервер, а другая часть создает обратный трафик.
При естественном увеличении пропускной способности службы и увеличении пропускной способности на стороне пользователя, предполагая, что скорость возврата службы к источнику остается неизменной, скорость устранения и обновления (удаления) дискового кэша увеличивается, что проявляется в следующих узких местах службы: (высокий iowait, высокая полоса пропускания обратно к источнику, более высокая скорость возврата из-за вытеснения кеша с ограниченным размером дискового пространства).
Для иллюстрации этого принципа. Мы допускаем две крайности: первая состоит в том, что емкость диска устройства бесконечна, а трафик от бизнеса кэшируется только по правилам кэширования исходного сайта. Пока срок действия кеша не истек, диск может храниться в кеше неограниченное время, а для обратного трафика требуется только тот трафик, доступ к которому осуществляется в первый раз, поэтому объем (скорость) обратного источника зависит только от деловые характеристики (повторяемость). Другая крайность заключается в том, что лимит диска мал (возвращается к нулю), и тогда независимо от того, истечет ли срок действия кеша бизнес-настроек или нет, клиентский трафик будет 1:1 обратно к источнику. Предполагается, что средний период кэширования бизнеса составляет 1 час. Тогда первая пропускная способность кеша (многократное обращение к одному и тому же ключу кеша, мы думаем, что это один раз) за этот час будет равна требуемому пространству на жестком диске. Этот размер является разумным и может гарантировать, что диска будет достаточно для размещения объема бизнеса. Предположим, эта сумма не может быть достигнута или достигнута, но в связи с естественным ростом бизнеса пропускная способность первого кэша в течение часа увеличивается, а места на жестком диске не хватает.
Расширение оборудования является решением. Однако до системы измерения давления нет объективных данных, подтверждающих, насколько оборудование необходимо расширить. Или сколько устройств было расширено без проверки оттенков серого, и оборудование на месте, и машина напрямую развернута в сети. Мы воспроизводим онлайн-журнал на экспериментальной машине и моделируем кривую моделирования хранилища, чтобы определить разумное хранилище оборудования в онлайн-компьютерном зале. В этом заключается важность построения системы журнала повторов.
Хоть воробей и маленький, но модель бревна повтора со всеми внутренними органами (обзор)
В этой главе мы определяем следующие модули:
Имитация сервера журналов: загрузка журнала доступа к определенному компьютерному залу в режиме онлайн за определенный период времени. В журнале хранятся записи доступа за 10 минут. В компьютерном зале есть несколько машин для загрузки нескольких журналов. Сервер журналов также предоставляет службы запросов для получения информации о фрагментации задач. Предположим, нам нужно воспроизвести фрагмент задачи с идентификатором задачи pig_120t. На следующем рисунке показаны детали среза задачи.
Контроллер задач: запуск или завершение главного переключателя задач. Распределение задач равномерно распределяется между конкретными бройлерами и прокси-серверами. Вставьте задачи в пул задач, соберите в реальном времени общий трафик, трафик обратного источника, общее количество запросов и данные обратного источника сервера и вставьте их в таблицу данных результатов скорости обратного потока.
Бройлер: опрос таблицы задач пула задач. Если есть задача, запросите у лог-сервера загрузку лога шарда в соответствии с деталями задачи (время, ip онлайн-компьютера). Повторить запрос на указанный прокси-сервер.
Прокси-сервер: предоставление услуг запроса данных обратно к источнику в режиме реального времени. И установите такие компоненты, как кэш-сервер nws, который эквивалентен программному модулю онлайн-компьютерного зала.
Интерфейс отображения в режиме реального времени: вы можете в любое время просмотреть скорость возврата в реальном времени и некоторую информацию об аномальном состоянии задачи.
Рисунок 3 представляет собой схему взаимодействия между клиентом и сервером. На рис. 4 показан процесс связи между терминалом управления задачами и другими модулями во время выполнения задачи.
Функции распределенной системы
Ядром модели воспроизведения журнала является высокопроизводительная система измерения напряжения, но необходимо добавить некоторую логику: загрузка журнала, анализ и реконструкция журнала, сбор данных результатов, отчетность и отображение данных. Суть распределенной системы заключается в том, является ли она масштабируемой, восстанавливаемой, простой в построении, отказоустойчивой и автоматизированной. Следующее содержимое будет расширяться одно за другим.
Начнем с высокой производительности: в универсальной модели. Мы имитируем онлайн-журналы, и эта система должна быть эффективной, потому что скорость воспроизведения нашего журнала выше, чем онлайн-запросы в секунду. Скорость воспроизведения машины определяет скорость результатов анализа. В то же время более высокая скорость требует меньше бройлерных ресурсов. В различных библиотеках url-запросов python и golang автор окончательно доработал использование golang для реализации broiler. golang работает так же быстро, как нативный c+epoll, но реализация кода намного проще. Теоретически мы провели анализ узких мест производительности прокси-сервера на одной машине. Онлайн-журналы сложнее, чем смоделированные журналы, и умеренное снижение количества запросов в секунду неизбежно. Клиент Golang достигает желаемой цели.
Масштабируемость: мы можем в любое время увеличить количество бройлеров в смоделированном кластере машин или добавить больше простаивающих ресурсов прокси-сервера для задач стресс-тестирования. Таким образом, система добавляет новые машины в любое время в доступный лист технических данных машины.
Возможность восстановления: распределенные системы отличаются от автономных моделей. Неизбежно, что могут быть различные сбои.Иногда некоторые узлы в системе выходят из строя.Мы предпочитаем не использовать этот узел, вместо того, чтобы продолжать использовать необработанные результаты. То есть это либо 0, либо 1, промежуточного состояния нет. В распределенных системах также существует неконтролируемая задержка передачи по сети. Поэтому система измерения давления разработала набор отказоустойчивых механизмов: в том числе обнаружение сбоя сердцебиения, автоматическое удаление бройлерного сервера из таблицы данных. Исключения интерфейса отказоустойчивы. Незавершенные задачи удаляются по истечении тайм-аута. crontab регулярно тянет и выходит из процесса и т. д.
Простота сборки: используйте интерфейс ajs и скрипт пакетной установки. Автоматизированное развертывание бройлеров и серверов. Настройте IP-адрес разрешения DNS (сервер журнала, пул задач, IP-адрес базы данных, где находится результат скорости возврата), повторное использование состояния tcp time_wait, не забудьте снять некоторые системные ограничения (отпустите ограничение ulimit fd, установите здесь 100000, постоянные настройки требуют редактирование /etc/security/limits.conf). Если у бройлера есть зависимости, необходимо одновременно загрузить библиотеку времени выполнения. Загрузите клиент бройлера и конфигурацию на бройлерную машину, загрузите сервер и конфигурацию на серверную машину, загрузите обычный скрипт программы подтягивания и добавьте его в crontab для регулярного выполнения. Все вышеперечисленное автоматизировано с помощью пакетных сценариев.
Некоторые мысли о парадигмах дизайна
Single-productor and Multi-consumer
В дизайне бройлерного клиента: считывайте файл журнала по одной строке за раз, добавляйте его в конвейер сообщений, а затем несколько исполнителей берут URL-адрес из конвейера сообщений и выполняют смоделированный запрос. Конвейер сообщений передает URL-адрес журнала для выполнения. Программа, потребляющая ввод-вывод, относится к тому, что если потребитель выполняет журнал доступа и мгновенно завершает результат, но производителю необходимо выполнить сложную обработку строк (например, регуляризацию) в журнале, тогда он будет заблокирован конвейером, если он не может получить данные в следующий раз в прямом эфире. Другой — программа, потребляющая ресурсы ЦП.Если URL-адрес журнала был предварительно обработан, производитель просто копирует данные в конвейер сообщений. Потребитель получает доступ к URL-адресу после непредсказуемой сетевой задержки. Если несколько потребителей (поскольку это включает в себя время доступа к сети, количество потребителей рассчитано на превышение количества ядер процессора, например, в 2 раза) одновременного доступа, скорость чтения будет ниже, чем скорость записи. В ходе эксперимента с файлом журнала мы обнаружили, что время обработки записей 18w составляет 0,3 с, а выполнение задач доступа к этим URL-адресам занимает 3 минуты. Таким образом, очевидно, что это процесс, потребляющий процессор. Если это программа, потребляющая IO. В Golang есть модель сообщений, которая называется разветвлением. Мы можем спроектировать это следующим образом: несколько читателей читают чан из нескольких списков чан, и один писатель записывает один чан. Разветвление записывает chan в конце записи в chan списка chan по кругу.
Map-reduce
Иногда мы проводим анализ журнала компьютерной комнаты оператора в географическом месте. Компьютерный зал содержит несколько IP-адресов машин. Разумное планирование журналов параллельного доступа для нескольких клиентов-бройлеров может быстрее получить объединенные данные о норме обратно к источнику.
Параллельный механизм, классический map-reduce, лог-файлы нарезаются и распределяются по ip-широте машины в компьютерной комнате, и N бройлеров запускаются одновременно, когда последний бройлер выполняет задачу, данные каждого бройлера объединяются в соответствии с количеством успешных запросов, трафиком успешных запросов, подсчитывается количество неудачных запросов и трафик неудачных запросов. Также используется для проверки в онлайн-журналах. Маппер здесь — бройлер, а сгенерированная таблица данных, которую мы извлекаем в соответствии с типом заботы, — редуктор.
Упрощенный мап-редьюсер (не основанный на распределенной файловой системе), передача данных между мап и редуктором реализована с помощью таблиц данных. Данные журнала, сгенерированные каждым преобразователем, размещаются локально, а затем передаются в таблицу данных. Однако из-за ограничения размера таблицы данных мы можем загрузить только заголовок для доступа к URL-адресу. Таким образом, если используется этот метод, данные являются неполными или не совсем правильными. Потому что, возможно, объединенные данные заголовка двух бройлеров просто включают журнал, который бройлер не загрузил (журнал не соответствует высшему стандарту посещений бройлеров с одной машиной).
Итак, как решить эту проблему, первопричина заключается в том, что файловая система, где сводные данные являются локальными, а не распределенными (hadoop of hdfs, вероятно, основан на потребностях этого изобретения). Если код состояния представляет собой широту, этот ход мыслей не является проблемой, потому что общий объем кода состояния http очень мал. Так что, если это широта URL-адреса, например, одна комната для одной задачи бройлеров в общем объеме URL-адреса данных 10 минут, чтобы достичь 180 000. Посмотрите в журнале число повторений > 100 данных бройлеров. Таким образом, максимальная ошибка составляет 100*количество цыплят, цыплят на помещение 10, при условии, что суммарный результат больше 1000. Им доверяют. Если доменное имя является широтой, то большая часть полосы пропускания приходится на голову небольшого числа клиентов. Это так называемая горячая клавиша, на долю нескольких горячих клавиш приходится большая часть трафика. Таким образом, когда широта доменного имени, на этот раз вы можете увеличить масштаб, чтобы сосредоточиться на указанном списке URL-адресов доменного имени. Если объем данных, передаваемых в локальную таблицу, слишком велик, URL-адрес можно считать сжатием короткого адреса. Конечно, если вы не прогнулись, чтобы обогнать, то, нужно жестко решить эту проблему, вам может понадобиться получить эту распределённую файловую систему hdfs.
Stream-Processing
Мы логируем клиентскую систему, вам нужно загрузить логи, необходимые для работы (обычно это 10-минутные логи доступа к машине) на лог-сервер. Во-первых, задача будет передана задаче воспроизведения запросов локального сервера журналов. Затем перейдите на сервер журналов для загрузки. Если кластер моделирования представляет собой сеть, настроенную в DC, то загрузите 10-минутный (о файлах около 150M) журнал почти за две секунды, чтобы получить в течение одной, но если система настроена на распределенную сеть OC, сервер сети OC на бройлер ДК (учитывая надежность движка, лог-сервер установлен в сети ДК) скачал по сети во внешнюю сеть nat конвертация, надо скачать около 10с. Если сервер журнала ждать загрузки, но и сумма накладных расходов времени.
В распределенных системах так называемая потоковая обработка данных, в отличие от пакетной обработки, не ограничена. Вы не знаете, когда журнал закончил загрузку. Отношения процесса между пакетной обработкой аналогичны процессу производственной линии: первый процесс завершается, а второй процесс начинается, а для последнего процесса полностью известно, какова производительность предыдущего процесса.
Так называемая потоковая обработка должна запускать следующий процесс, когда приходит результат вывода предыдущей части, предыдущий процесс продолжает выводить, а последнему процессу необходимо отреагировать на событие обработки. Последний маршрут требует частых планировщиков.
Брокер сообщений (брокер сообщений): Часть вывода предыдущего шага вводится в систему сообщений. Если система сообщений обнаружит, что это полный журнал, она может сгенерировать входные данные для следующего процесса. Здесь мы столкнемся с проблемой. Скорость загрузки логов (10с) будет намного быстрее, чем скорость воспроизведения этих логов (3мин). Согласно системе сообщений, возможные действия: если нет буфера, отбросить его, кэшировать в соответствии с очередью и выполнить совпадающую скорость следующего процесса и предыдущего процесса синхронизации управления потоком. Здесь мы выбираем кэширование этой схемы в соответствии с очередью. Конечно, в строго распределенной базе данных брокер сообщений является узлом, который может выполнять проверку на предмет потери данных. Брокер отправит полные данные в последующий процесс и в то же время кэширует данные буфера в резервную копию жесткого диска, чтобы предотвратить дамп ядра программы. Для медленных интерфейсных процессов можно выполнить комплексную настройку схемы, отбрасывание или управление потоком. Здесь брокер сообщений отличается от базы данных тем, что в ней временно хранятся промежуточные необработанные данные, а обработанные сообщения нужно очищать и сохранять.
Суммировать
Конечно: распределенная система реальной производственной линии будет намного сложнее, чем эта, но распределенная система мини-воробья от 0 до 1, реализованная в этой статье, имеет определенное практическое значение. Это не происходит в одночасье, оно постоянно повторяется. Конечно, система также завершила авторский анализ модели хранилища KPI.При возникновении проблем в середине дизайн-мышление и улучшение обобщаются и передаются вам.
вопросы и ответы
Распознавание символов Каковы требования к формату?
Связанное Чтение
Получается, что вы http2 вот так
Как использовать go step by step, чтобы найти узкое место производительности при измерении стресса
Эта статья была разрешена автором для публикации в сообществе Tencent Cloud + Для получения дополнительных оригинальных текстов, пожалуйстанажмите
Найдите и подпишитесь на общедоступную учетную запись «Сообщество Yunjia», получите технические галантереи как можно скорее и ответьте на 1024, обратив внимание, чтобы отправить вам подарочный пакет технических курсов!
Огромный технический практический опыт, все вСообщество Юнцзя!