Приветствую всех вОблако Tencent + сообщество, получить больше крупной технической практики Tencent по галантерее ~
Эта статья написанаmariolu Опубликован вКолонка «Облако + сообщество»
Предисловие (первоначальное намерение)
Первоначальная цель разработки этой системы состоит в том, чтобы проанализировать взаимосвязь между дисковым хранилищем прокси-сервера кэширования и скоростью возврата на основе описания бизнес-модели (или кластера машин) хранения. Значение системы заключается в количественном руководстве расширением оборудования компьютерного зала в процессе оптимизации затрат Tencent Cloud. Первая половина — введение в предысторию и теоретические размышления о модели кэширования CDN. Во второй половине фактически будет построена миниатюрная, но хорошо оснащенная распределенная общая системная архитектура, и, наконец, система получит некоторые фоновые функции для решения практических проблем, возникающих при оптимизации затрат.
Схема модели хранилища кэш-сервера (фон):
Онлайн-маршрутизация Tencent CDN заключается в том, что пользователи à OC->SOC->SMid->исходные станции распределены по разным регионам и операторам. Каждый узел уровня развертывается с сервером кэширования. Часть трафика запросов от пользователя попадает на сервер, а другая часть создает обратный трафик.
При естественном увеличении пропускной способности службы и увеличении пропускной способности на стороне пользователя, предполагая, что скорость возврата службы к источнику остается неизменной, скорость устранения и обновления (удаления) дискового кэша увеличивается, что проявляется в следующих узких местах службы: (высокий iowait, высокая полоса пропускания обратно к источнику, более высокая скорость возврата из-за вытеснения кеша с ограниченным размером дискового пространства).
Чтобы проиллюстрировать этот принцип. Мы предполагаем, что две крайности: одно состоит в том, что емкость диска устройства бесконечна, а кэш трафика бизнеса ограничен только правилами кэша исходной станции. До тех пор, пока кэш не истек, диск может быть неограниченным, и обратный трафик требуется только трафик для доступа, поэтому этот исходный код (скорость) связан только с характеристиками бизнеса (скорость повторения). Еще один экстремальный предел диска невелик (ноль), то количество клиентского доступа составляет от 1 до 1 в количестве от 1 до 1 независимо от того, просрочен ли кэш бизнес-настройки. Предполагая, что средний цикл кэширования бизнеса составляет 1 час. Затем первый час первой пропускной способности кэша (множественный доступ к одному клавишу кеша, мы считаем, что это однажды) будет необходимым пространством для этого жесткого диска. Этот размер является разумным, гарантируя, что диск достаточно для размещения величины бизнеса. Предполагая, что эта сумма не достигнута, или она достигнута, но поскольку бизнес естественно растут, первая группа кэша велика в материке в течение 1 часа, а пространство жесткого диска недостаточно.
Расширение оборудования является решением. Однако до системы измерения давления нет объективных данных, подтверждающих, насколько оборудование необходимо расширить. Или сколько устройств было расширено без проверки оттенков серого, и оборудование на месте, и машина напрямую развернута в сети. Мы воспроизводим онлайн-журнал на экспериментальной машине и моделируем кривую моделирования хранилища, чтобы определить разумное хранение оборудования в онлайн-компьютерном зале. В этом заключается важность построения системы журнала повторов.
Хоть воробей и маленький, но модель бревна повтора со всеми внутренними органами (обзор)
В этой главе мы определяем следующие модули:
Имитация сервера журналов: загрузка журнала доступа к определенному компьютерному залу в режиме онлайн за определенный период времени. В журнале хранятся записи доступа за 10 минут. В компьютерном зале есть несколько машин для загрузки нескольких журналов. Сервер журналов также предоставляет службы запросов для получения информации о фрагментации задач. Предположим, нам нужно воспроизвести фрагмент задачи с идентификатором задачи pig_120t. На следующем рисунке показаны детали среза задачи.
Контроллер задач: запуск или завершение главного переключателя задач. Распределение задач равномерно распределяется между конкретными бройлерами и прокси-серверами. Вставьте задачи в пул задач, соберите в режиме реального времени общий трафик, обратный трафик, общее количество запросов и данные обратного исходного трафика сервера и вставьте их в таблицу данных о скорости обратной связи.
Бройлер: опрос таблицы задач пула задач. Если есть задача, запросите у лог-сервера загрузку лога шарда в соответствии с деталями задачи (время, ip компьютерной комнаты в сети). Повторить запрос на указанный прокси-сервер.
Прокси-сервер: предоставление услуг запроса данных обратно к источнику в режиме реального времени. И установите такие компоненты, как кэш-сервер nws, который эквивалентен программному модулю онлайн-компьютерного зала.
Интерфейс отображения в режиме реального времени: вы можете в любое время просмотреть скорость возврата в реальном времени и некоторую информацию об аномальном состоянии задачи.
Рисунок 3 представляет собой схему взаимодействия между клиентом и сервером. На рис. 4 показан процесс связи между терминалом управления задачами и другими модулями во время выполнения задачи.
Функции распределенной системы
Ядром модели воспроизведения журнала является высокопроизводительная система измерения напряжения, но необходимо добавить некоторую логику: загрузка журнала, анализ и реконструкция журнала, сбор данных результатов, отчетность и отображение данных. Суть распределенной системы заключается в том, является ли она масштабируемой, восстанавливаемой, простой в построении, отказоустойчивой и автоматизированной. Следующее содержимое будет расширяться одно за другим.
Начнем с высокой производительности: в универсальной модели. Мы имитируем онлайн-журналы, и эта система должна быть эффективной, потому что скорость воспроизведения нашего журнала выше, чем онлайн-запросы в секунду. Скорость воспроизведения машины определяет скорость результатов анализа. В то же время более высокая скорость требует меньше бройлерных ресурсов. В различных библиотеках запросов URL-адресов Python и Golang автор, наконец, решил использовать golang для реализации бройлеров. 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-адресу. Таким образом, если используется этот метод, данные являются неполными или не совсем правильными. Потому что, возможно, объединенные данные заголовка двух бройлеров просто включают журнал, который бройлер не загрузил (журнал не соответствует высшему стандарту посещений бройлеров с одной машиной).
Итак, как решить эту проблему, фундаментальная причина заключается в том, что файловая система, в которой находятся агрегированные данные, является локальной, а не распределенной (вероятно, hdfs от Hadoop придуман на основе этого требования). Если это широта кода состояния, такое мышление не проблема, потому что общее количество кодов состояния http очень мало. Тогда, если это, например, широта URL-адресов, общий объем данных URL-адресов за 10 минут для одной задачи от компьютерной комнаты до одного жаровни достигает 180 000. Просматривайте только данные о бройлерах с повторением журнала > 100. Таким образом, максимальная ошибка составляет 100*количество бройлеров, поэтому для компьютерного зала с 10 бройлерами при условии, что комплексный комбинированный результат >1000. все заслуживают доверия. Если это широта доменного имени, то на трафик нескольких основных клиентов приходится большая часть пропускной способности. Это также называется горячими клавишами, и на несколько горячих клавиш приходится большая часть трафика. Таким образом, когда доменное имя является широтой, в это время фокус может быть увеличен до списка URL-адресов указанного доменного имени. Если объем данных, передаваемых локально в таблицу данных, слишком велик, URL-адрес также можно использовать для сжатия коротких адресов. Конечно, если вы не хотите обгонять в повороте, вам нужно жестко решить эту проблему, и вам может понадобиться распределенная файловая система, такая как hdfs.
Stream-Processing
Мы реализуем клиентскую систему журналов, и нам нужно загрузить журналы, необходимые для этой задачи, с сервера журналов (обычно это 10-минутный журнал доступа к машине). Во-первых, локальный журнал отправится на сервер задач для запроса задачи воспроизведения. Затем перейдите на сервер журналов для загрузки. Если смоделированный кластер построен в сети ЦОД, загрузка 10-минутного (около 150М файла) лога может быть осуществлена в течение 1-2 секунд, но если распределенная система построена в сети ОЦ, то бройлерный сервер ОЦ сеть должна быть Перейдите в ЦОД (учитывая надежность машинного зала, сервер журналов настроен в сети ЦОД) для загрузки и преобразования внутренней сети во внешнюю сеть через NAT, а загрузка займет около 10 с. . Если вы ждете, пока сервер журналов загрузится, это также дополнительные затраты времени.
В распределенных системах так называемая потоковая обработка данных, в отличие от пакетной обработки, не ограничена. Вы не знаете, когда журнал закончил загрузку. Отношения процесса между пакетной обработкой аналогичны процессу производственной линии: первый процесс завершен, а второй процесс запущен, а для последнего процесса полностью известно, каков объем продукции предыдущего процесса.
Так называемая потоковая обработка должна запускать следующий процесс, когда приходит результат вывода предыдущей части, предыдущий процесс продолжает выводить, а последнему процессу необходимо отреагировать на событие обработки. Последний маршрут требует частых планировщиков.
Брокер сообщений (брокер сообщений): Часть вывода предыдущего шага вводится в систему сообщений. Если система сообщений обнаружит, что это полный журнал, она может сгенерировать входные данные для следующего процесса. Здесь мы столкнемся с проблемой. Скорость загрузки логов (10с) будет намного быстрее, чем скорость воспроизведения этих логов (3мин). Согласно системе сообщений возможные действия: если буфера нет, он будет отброшен, кэширован в соответствии с очередью, и выполняется согласование скорости следующего процесса и предыдущего процесса синхронизации управления потоком. Здесь мы выбираем кэширование этой схемы в соответствии с очередью. Конечно, в строго распределенной базе данных брокер сообщений является узлом, который может выполнять проверку на предмет потери данных. Брокер отправит полные данные в последующий процесс и в то же время кэширует данные буфера в резервную копию жесткого диска, чтобы предотвратить дамп ядра программы. Для медленных интерфейсных процессов можно выполнить комплексную настройку схемы, отбрасывание или управление потоком. Здесь брокер сообщений отличается от базы данных тем, что в ней временно хранятся промежуточные необработанные данные, а обработанные сообщения нужно очищать и сохранять.
Суммировать
Конечно: распределенная система реальной производственной линии будет намного сложнее, чем эта, но распределенная система мини-воробья от 0 до 1, реализованная в этой статье, имеет определенное практическое значение. Это не происходит в одночасье, оно постоянно повторяется. Конечно, система также завершила авторский анализ модели хранилища KPI.При возникновении проблем в середине дизайн-мышление и улучшение обобщаются и передаются вам.
вопросы и ответы
Каковы требования к формату для распознавания текста?
Связанное Чтение
Получается, что вы http2 вот так
Как использовать go step by step, чтобы найти узкое место производительности при измерении стресса
Эта статья была разрешена автором для публикации в сообществе Tencent Cloud + Для получения дополнительных оригинальных текстов, пожалуйстанажмите
Найдите и подпишитесь на общедоступную учетную запись «Сообщество Yunjia», получите технические галантереи как можно скорее и ответьте на 1024 после подписки, чтобы отправить вам подарочный пакет технических курсов!
Огромный технический практический опыт, все вСообщество Юнцзя!