Введение в тему:
-
Принцип реализации ядра
-
Распределенный кластер
-
Ключевые параметры производственного развертывания
-
Мониторинг и анализ производительности
Во-первых, принцип реализации ядра
HTTP
Связь между веб-сервером и браузером основана на протоколе HTTP, и браузер отправляет сообщение HTTP-запроса на сервер для доступа к серверу.
Как показано на рисунке, метод get используется для доступа к Web, Index и JSP порта localhost 8080. Сервер возвращает код состояния 200 и возвращает клиенту несколько HTTP-пакетов.
HTTP-сообщение
Как видно из рисунка, сообщение запроса и сообщение ответа в сообщении HTTP состоят из трех частей. Сообщение запроса состоит из трех частей: строки запроса, заголовка запроса и тела запроса. Строка запроса в основном включает метод, uri и версию протокола; заголовок запроса в основном содержит пару kv; в теле запроса обычно используется метод post. для хранения параметров; а ответное сообщение состоит из строки ответа, заголовка ответа и тела ответа, где строка ответа в основном включает версию протокола и код состояния; заголовок ответа содержит пару kv; тело ответа содержит настоящее сообщение.
протокол HTTPS
Мы также можем рассматривать HTTPS как безопасную версию HTTP.В настоящее время это больше не обмен открытым текстом, но после того, как две стороны согласовывают ключ, сообщение шифруется, а затем передается. В этом процессе после шифрования его необходимо расшифровать, прежде чем переходить к следующему шагу.
HTTPS добавляет дополнительный уровень SSL/TLS к верхнему уровню протокола TCP/TP, что делает его прозрачным для веб-приложений. Мы видим, что после того, как клиент подключается к серверу, он согласовывает и определяет ключ через определенные шаги, а Java уже предоставила пакет процесса протокола SSL/TLS, поэтому нет необходимости делать это самостоятельно.
связь через сокет
Все должны быть знакомы с сокетами, поэтому давайте подробно обсудим процесс серверных сокетов:
Когда на прикладном уровне новый ServerSocket блокируется и ожидает, операционная система выполнит ряд операций и отслеживает доступ клиента. Когда сервер получит клиентское соединение, он создаст структуру данных сокета и поместит ее в очередь, а затем запрос прикладного уровня будет опрашивать для получения клиентского сокета.
связь через сокет
Когда клиентский сокет блокируется и ждет после нового сокета, операционная система будет нести ответственность за инициацию запроса на подключение к серверу, а прикладной уровень не освободит ожидание, пока не завершится трехэтапное рукопожатие.
модель сервера
(1) Режим блокировки потока
- режим блокировки одного потока
С точки зрения однопоточного режима блокировки есть два клиента, запрашивающих сервер, где второй клиент должен дождаться завершения обработки первого клиента, прежде чем он сможет начать обработку.
- Многопоточный режим блокировки
Многопоточный режим блокировки также имеет двух клиентов, запрашивающих сервер, но второму клиенту в этом режиме не нужно ждать, пока первый клиент закончит обработку, а два клиента обрабатываются одновременно.
- Однопоточный неблокирующий режим
В однопоточном неблокирующем режиме один поток сервера обслуживает запросы от нескольких клиентов, а поток непрерывно обходит и обрабатывает все сокеты, пытаясь читать и писать. На основе режима мониторинга событий сервер сообщает операционной системе о событиях, требующих внимания, а затем операционная система отвечает за обнаружение всех клиентских подключений и размещение обнаруженных событий в двух списках.Наконец, уровень приложения должен только пройти эти два списка. Начать обработку.
- Многопоточный неблокирующий режим
В многопоточном неблокирующем режиме сервер имеет несколько потоков, совместно отвечающих за несколько клиентов, и соединения клиента равномерно распределяются между каждым потоком для управления.
(2) Реакторный режим
В реальных проектах чаще всего используется режим Reactor. Поток Reactor отвечает за распределение различных событий, связанных с клиентом, на разные процессоры для обработки, такие как процессор приема, процессор чтения, процессор записи и процессор обработки.
Но на самом деле у режима Reactor есть недостаток, который нельзя не учитывать, например, процессор, обрабатывающий длительную операцию, может повлиять на общую вычислительную мощность, поэтому необходимо ввести пул потоков в процессор процесса, который будет время Операции помещаются в пул потоков для обработки, так что общая работа Reactor находится в нормальном состоянии.
Кроме того, есть улучшенный режим Реактора, то есть если одного Реактора недостаточно, то создается еще несколько Реакторов для обработки одновременно. Как показано на рисунке ниже, есть два объекта Reactor, каждый из которых имеет процессор чтения, процессор записи и процессор обработки. Распределение клиентских подключений совместно завершается обработчиком приема, а затем равномерно распределяется по разным объектам Reactor.
весь кадр
Давайте сначала разберемся с общей структурой Tomcat. Его контейнером верхнего уровня является сервер, который включает в себя службы, прослушиватели и глобальные ресурсы. Основными объектами Tomcat являются Connector (их может быть несколько) и Container, где каждому Connector соответствует порт для работы с разными протоколами.
Контейнер содержит четыре уровня: Engine, Host, Context и Wrapper. Engine — это глобальный механизм сервлета, Host — виртуальный хост, Context соответствует веб-приложениям, а Wrapper соответствует объектам сервлета в веб-приложениях.
обработка запроса
Как выглядит полный процесс обработки запроса? Как показано на рисунке, после запуска коннектора JioEngdpoint будет отвечать за прием подключения запроса клиента, а после его получения будет передан в пул задач для обработки. Пул задач будет анализировать и обрабатывать сообщение запроса в соответствии с логикой Http11Processor (в соответствии с протоколом HTTP1.1). Затем адаптер CoyoteAdapter будет адаптирован к соответствующему сервлету для обработки бизнес-логики. Этот процесс будет проходить через четыре конвейера, и каждый конвейер может иметь несколько клапанов.После обработки он, наконец, достигнет сервлета контейнера-оболочки для обработки и вернет ответное сообщение клиенту для завершения всего процесса запроса.
Рабочий механизм сервлета
Главное, о чем я хочу здесь поговорить, — это непоточная безопасность сервлетов. Обычный сервлет имеет только один объект, а сервлет, реализующий указанный интерфейс, будет иметь пул объектов сервлета, и количество объектов по умолчанию в пуле равно 20.
Механизм работы Servlet был вкратце упомянут выше, то есть через четыре уровня контейнеров, через конвейер слой за слоем находится соответствующий запросу сервлет, а ответное сообщение возвращается клиенту после выполнения логической обработки .
Сервлет, реализующий интерфейс SingleThreadModel, сначала выделяет объект из пула сервлетов во время процесса запроса, а затем освобождает его обратно в пул после использования для использования другими потоками.
В соответствии с различными типами запрашиваемых ресурсов сервлет можно разделить на три категории, такие как обычный сервлет, JspServlet и DefaultServlet. Среди них различные типы ресурсов запроса будут сопоставлены с соответствующим типом сервлета через Mapper.
механизм подключения фильтра
В этом процессе также присутствует механизм подключения фильтра, то есть сначала через разные фильтры, а в конце к сервлету.
Режим кометы
Клиент отправляет запрос на сервер, и сервер регистрирует его в очереди NioChannel после его получения, а затем компонент Poller непрерывно опрашивает, есть ли NioChannel, который необходимо обработать. Если есть NioChannel, который необходимо обработать, вызовите созданный ранее сервлет режима Comet.
Здесь в основном используется метод события из оправдания CometProcessor.Поллер инкапсулирует соответствующий объект запроса, объект ответа и событие в объект CometEvent и передает его в метод события, а затем выполняет логику метода события для завершения обработки. различные события, тем самым реализуя режим кометы.
Режим веб-сокета
Во-первых, клиент отправляет на сервер пакет подтверждения «обновление протокола WebSocket»; если сервер поддерживает протокол WebSocket, он возвращает пакет подтверждения «подтверждение обновления». В это время соединение WebSocket с двунаправленной связью успешно установлено, и сообщения могут отправляться с использованием формата кадра данных протокола WebSocket.
После того, как соединение клиента WebSocket получено получателем и зарегистрировано в очереди NioChannel, компонент Poller непрерывно опрашивает, есть ли NioChannel, который необходимо обработать. Если есть, он войдет в Servelt, который наследует WebSocketServelt после обработки конвейера. Метод doGet WebSocketServlet обрабатывает рукопожатие WebSocket, сообщая клиенту о согласии с протоколом обновления. Затем Poller продолжает опрашивать соответствующий NioChannel.Как только он находит конвейер, использующий протокол WebSocket, он вызывает соответствующие методы MessageInbound для завершения обработки различных событий, тем самым реализуя поддержку протокола WebSocket.
Сервлет синхронизации
Процесс обработки сервлета в случае синхронизации показан на рисунке.
Запрос клиента Tomcat обрабатывается конвейером и, наконец, проходит через конвейер контейнера-оболочки.В это время он вызывает метод службы экземпляра сервлета для логической обработки и отвечает клиенту после обработки. Вся обработка выполняется потоками пула потоков Tomcat Executor, а максимальное количество потоков в пуле потоков ограничено, поэтому чем короче процесс обработки, тем быстрее потоки могут быть освобождены обратно в пул потоков. Однако, если логика обработки в сервлете занимает больше времени, она будет занимать пул потоков обработки Tomcat в течение длительного времени, что в конечном итоге повлияет на общие возможности обработки Tomcat.
Асинхронный сервлет
Чтобы решить вышеуказанные проблемы, мы можем ввести сервлеты, поддерживающие асинхронность, как показано на рисунке.
Точно так же, когда приходит клиентский запрос, он сначала проходит через конвейер, затем входит в конвейер контейнера-оболочки, а затем вызывает службу экземпляра сервлета и создает асинхронный сервлет для инкапсуляции трудоемких логических операций и передачи его. в пул потоков, определенный пользователем. Таким образом можно избежать общих вычислительных возможностей Tomcat из-за длинной логики обработки в сервлете.
2. Распределенный кластер
Зачем использовать кластеры?
Для этого есть две основные причины:
-
Во-первых, для некоторых ядерных систем требуется, чтобы обслуживание не могло прерываться на длительное время.Для обеспечения высокой доступности нам нужен кластер, состоящий из нескольких машин;
-
Во-вторых, поскольку количество посещений увеличивается, а бизнес-логика становится все более и более сложной, вычислительной мощности одной машины уже недостаточно для обработки стольких сложных логик, поэтому необходимо добавить несколько машин, чтобы улучшить вычислительную мощность весь сервис.
В чем сложность кластеризации?
Если нет состояния, то очень просто сделать кластер, просто стекить машины напрямую, и запрос может быть обработан правильно, независимо от того, на какой узел он идет. Однако в случае состояния его необходимо правильно обработать после того, как соответствующий узел сможет получить информацию о сеансе, соответствующую клиенту.Самый простой метод обработки — поместить информацию о сеансе в БД, и все узлы получат клиент сессия из БД.информация.
Модель синхронизации сеансов полного узла
Модель синхронизации сеанса с полным узлом может совместно использовать всю информацию о сеансе между всеми узлами сервера, и каждый узел содержит информацию о сеансе всех клиентов, что может гарантировать, что сервер может точно получить информацию о сеансе клиента и правильно ее обработать. Но модель синхронизации сеансов с полным узлом также может создавать риск перегрузки сети.
Модель с одним узлом резервного копирования сеанса
Запрос распространяется на узел в кластере Tomcat через Apache, и генерируется информация о сеансе. Эта информация о сеансе может быть синхронизирована только на определенном узле с помощью определенного механизма резервного копирования вместо синхронизации со всеми узлами, что значительно снижает нагрузку на сеть и позволяет эффективно избежать перегрузки сети.
Выбор производственного развертывания
1. Небольшие приложения могут напрямую использовать встроенную схему совместного использования сеансов Tomcat.
- Для модели полной синхронизации сеансов узлов
Рекомендуемое количество узлов кластера для этого решения в реальном производстве — 3–6. Он не может сформировать кластер большего размера, а большой объем данных является избыточным, а коэффициент использования низкий.
- Для модели резервного копирования сеанса
Рекомендуемое количество узлов кластера для этого решения в реальном производстве может достигать более 10.
2. Большие приложения обычно удаляют сеанс и помещают его в кластер кеша.
-
Redis
-
memcached
Оба имеют связанные пакеты jar для легкой интеграции.
развертывать
Общий метод развертывания показан на рисунке ниже Балансировщик нагрузки используется для перетаскивания нескольких узлов Tomcat, а различные клиентские клиенты получают доступ к Tomcat, обращаясь к балансировщику нагрузки.
обратный прокси
Общие балансировщики нагрузки можно разделить на программные и аппаратные. Аппаратное обеспечение включает F5, A10, Cisco и т. д., а программное обеспечение включает Nginx, Apache httpd, Lighttpd, Squid и т. д.
3. Ключевые параметры развертывания производства
Настройки JVM
Поскольку Tomcat также работает на JVM, JVM также имеет некоторые параметры, которые необходимо установить, а также параметр -server, инициализацию кучи Java и максимальное значение, по умолчанию 1/64 физической памяти и 1/4 физической памяти, как правило, нет более 80 % физической памяти, и эти два значения лучше всего установить одинаковыми, достаточно высокими, слишком большое значение приведет к пустой трате памяти и длительному циклу сбора мусора. Остальные параметры показаны ниже.
-
Обычно используйте HotSpot JVM
-
добавить сервер
-
-Xms/-Xmx: установите инициализацию кучи Java и максимальное значение, по умолчанию 1/64 физической памяти, а 1/4 физической памяти обычно не превышает 80% физической памяти, и эти два параметра лучше всего установить одинаковыми, просто достаточно, слишком большое значение приведет к потере памяти и длительным циклам сбора мусора.
-
-XX:NewSize/-XX:NewRatio: установите значение 25%-33% от общей кучи Java, слишком большое или слишком низкое значение приведет к недопустимому GC.
-
-XX:PermSize/-XX:MaxPermSize: максимальное начальное значение памяти без кучи равно 128M и 256M соответственно.
-
-XX:+AggressiveOpts: используйте новейшие методы оптимизации.
-
Обратитесь к официальному сайту оракула
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html, а другие параметры можно настроить в соответствии с реальной ситуацией.
Настройки кластера
Уровень 4 или уровень 7 используются для балансировки нагрузки, в зависимости от реальной ситуации. в:
-
Уровень 4 и уровень 7: уровень 4 не знает протокол HTTP и распределяет трафик только в соответствии с IP-адресом и портом клиента, но производительность хорошая; уровень 7 знает протокол HTTP и может использовать некоторые заголовки HTTP для распределения трафика. Из-за необходимости расчета производительность относительно низкая.
-
Пул подключений: количество подключений балансировщика нагрузки к tomcat, обычно меньшее или равное сумме возможностей обработки подключений узлов кластера tomcat. Например, в кластере 4 узла, и ожидается, что каждый tomcat будет обрабатывать 500 подключений, тогда максимальное количество длинных подключений в пуле подключений установлено на 2000.
-
Количество узлов кластера в режиме полноузловой репликации (DeltaManager) предпочтительно 3-6.
-
Количество узлов кластера в режиме BackupMnagager может быть больше 10.
настраивать
Есть три режима:
-
JAVA BIO, самый оригинальный и стабильный режим блокировки и режим по умолчанию до tomcat7. Он поддерживает меньшую одновременную обработку, а также может быть предпочтительнее обработка с высокой степенью параллелизма и короткими соединениями. В режиме BIO есть очень важный параметр: maxThreads, который указывает максимальное количество запросов, которые будут обрабатываться одновременно.Общий диапазон составляет 200-800. Его можно настроить от 400 в зависимости от реальной ситуации. Если это приложения с интенсивным использованием ЦП, можно уменьшить, а приложения, не интенсивно использующие ЦП, можно увеличить.
-
JAVA NIO, является режимом tomcat8 по умолчанию, может поддерживать параллельную обработку нескольких подключений и относится к неблокирующему режиму.
-
Native APR, неблокирующий режим, использующий собственный код для повышения производительности, написанный на C++ для поддержки большего параллелизма.
Настройка производительности — это динамический процесс постоянного поиска узких мест, в том числе:
-
Определить показатели производительности приложения
-
Понимание системной архитектуры приложения
-
Проверить параметры производительности текущего приложения
-
Анализируйте проблемы с производительностью, чтобы найти узкие места
-
Устранение узких мест оптимизации
-
Повторяйте вышеуказанные шаги до тех пор, пока не будет достигнута спецификация производительности.
Анализ соединителей
Существует множество факторов, связанных с производительностью Tomcat, обычно включая сетевую карту, параметры соединения TCP, длинные и короткие соединения HTTP, SSL, BIO и NIO, собственные параметры коннектора, выбор балансировки нагрузки и параметры балансировки нагрузки. При анализе узких мест производительности следует учитывать несколько связанных факторов, как указано выше.
JVM-анализ
При анализе JVM мы должны обратить внимание на память кучи Java, прямую память, постоянную генерацию, GC, стек потоков, собственный код и кэш TCP.
Общие инструменты анализа
-
Стресс-тест Jmeter: получите количество одновременных запросов, TPS, время отклика и т. д.
-
Друид поставляется с: отнимающим много времени SQL, использованием пула
-
JVM поставляется с: JPS, jinfo, jstat, jmap, jstack и т. д.
-
Мониторинг Linux: ЦП, память, дисковый ввод-вывод, сетевая карта, подкачка и т. д.
-
Общие инструменты: top, tail, grep, iotop, iftop и т. д.
Общий стресс-тест
После стресс-тестирования и настройки одного Tomcat выполняется коллективное стресс-тестирование всего кластера, чтобы увидеть, соответствует ли производительность линейному росту.
------------- Рекомендуем прочитать ------------
Резюме моей статьи за 2017 год — машинное обучение
Краткое изложение моих статей за 2017 год — Java и промежуточное ПО
Резюме моих статей 2017 года — глубокое обучение
Краткое изложение моих статей за 2017 год — исходный код JDK
Резюме моей статьи за 2017 год — обработка естественного языка
Резюме моих статей 2017 года — Java Concurrency
------------------рекламное время----------------
Меню официальной учетной записи было разделено на «распределенное», «машинное обучение», «глубокое обучение», «НЛП», «глубина Java», «ядро параллелизма Java», «исходный код JDK», «ядро Tomcat», и т.д. Там может быть один стиль, чтобы удовлетворить ваш аппетит.
Моя новая книга «Анализ проектирования ядра Tomcat» продана на Jingdong, и нуждающиеся друзья могут ее купить. Спасибо друзья.
Зачем писать «Анализ проектирования ядра Tomcat»
Добро пожаловать, чтобы следовать: