предисловие
планирование задачМожно сказать, что это промежуточная система, на которой все системы должны опираться, и в основном отвечает за запуск некоторых задач, которые необходимо регулярно выполнять. В традиционных не распределенных системах необходимо встроить только какие-либо временные рамки задач, такие какspringИнтегрироватьquartz, вы можете выполнить некоторые запланированные задачи. В распределенной системе это столкнется с проблемой повторяющегося выполнения задач (запускаемых несколькими серверами). Кроме того, с увеличением проектов компании также требуется единый центр управления задачами для решения проблемы хаотичной конфигурации задач.
Система планирования задач компании разрабатывалась в двух версиях: версия 1.0, запущенная в 2013 году, в основном решала проблему непоследовательной настройки задач и хаотичного управления задачами в различных системах того времени, а версия 1.0 представляла собой единую платформу управления задачами. Версия 2.0 в основном решает проблему одной точки, существовавшую в версии 1.0.
Система планирования задач 1.0
Архитектура системы планирования версии 1.0, показанная на рисунке 1: все задачи, которые должны выполняться одним сервером, ответственным за управление, управление задачами и работу триггера, выполняются машиной, встроенный в раму кварц, синхронизация триггера для выполнения задачи. , в задачах настройки укажите IP-адрес и порт клиента, когда задача запускается, в соответствии с настроенной информацией о маршрутизации, посредством обмена сообщениями http, выполните назначенные инструкции задачи.
Есть более серьезная проблема, служба планирования задач может быть только развернута, поэтому служба стала единой точкой.После простоя или других проблем все задачи не могут быть выполнены.
Система планирования задач 2.0
Версия 2.0 в основном предназначена для решения одноточечной проблемы версии 1.0, то есть для адаптации сервера планирования задач к распределенной системе Преобразованная структура проекта показана на рисунке 2. Сервер планирования необходимо преобразовать для поддержки одновременное существование нескольких серверов. Это приводит к проблеме Среди нескольких серверов планирования только одному серверу разрешено отправлять задачи (если все серверы отправляют задачи, это приведет к тому, что задача будет запускаться несколько раз в одно время запуска), поэтому нужен Лидер, только Лидер Только имеют право отдавать команды на выполнение задач. Другие серверы, не являющиеся лидерами, здесь называются Цветы.Цветочные машины не имеют разрешения на выполнение задач, но как только Лидер выходит из строя, необходимо переизбрать нового Лидера из всех Цветочных машин, чтобы продолжить выполнение последующих задач.
Другой вопрос: если приложение, такое как система центра управления активами, имеет три машины A, B и C и должно выполнить задачу в 12:00 утра, как система планирования обнаружит три машины A, В и С? Если машина Б не работает в 12:00, как система планирования идентифицирует ее? По сути, это проблема обнаружения службы.
Группа
Когда одновременно существует несколько серверов планирования задач, то, как выбрать лидера, является первой проблемой. Могут быть реализованы более зрелые алгоритмы, такие как zookeeper, основанный на алгоритме консенсуса paxos, алгоритме консенсуса Raft и т. д. В этом проекте используется простой подход, основанный на эфемерной функции узла зоопарка.
Узлы Zookeeper делятся на две категории: постоянные узлы и временные узлы.Постоянный узел необходимо удалить вручную, чтобы удалить его, а временный узел этого делать не нужно.Когда клиент, создавший временный узел, дает сбой или соединение с zookeeper отключен, все эфемерные узлы, созданные клиентом, удалены.
Еще одна функция смотрителя зоопарка: сторожевой пост. Клиент, подключенный к zookeeper, может следить за изменениями узла zookeeper. Например, операция мониторинга exists будет отслеживать, существует ли узел. Если узел будет удален, клиент получит уведомление.
Основываясь на двух характеристиках временных узлов и точек мониторинга, zookeeper можно использовать для реализации простой функции выбора лидера группы: когда каждый сервер планирования задач запускается, он пытается создать узел выбора лидера группы и записывает текущий IP-адрес машины в узел. , если узел создан успешно, текущая машина является Лидером. Если узел уже существует, проверьте содержимое узла. Если данные не совпадают с текущим IP-адресом компьютера, отслеживайте узел. После удаления узла повторите попытку создания узла выбора лидера.
Дефекты использования временных узлов zookeeper для выбора лидера группы: иногда даже если сервер планирования задач может нормально подключиться к zookeeper, это не означает, что машина доступна, например, в экстремальном случае сервер не может подключиться к базе данных , но он может быть подключен к zookeeper нормально.В настоящее время функция временного узла на основе zookeeper не может лишить эту ненормальную машину (но эту проблему можно решить некоторыми способами, такими как разработка набора программ самопроверки локально для обнаружить все возможные причины сбоя службы.Используемые исключения, такие как исключения базы данных и т. д., после сбоя программы самопроверки пакет пульса zookeeper больше не будет отправляться, тем самым удаляя ненормальную машину).
проблема с расщепленным мозгом
На выборах лидера группы мы избрали лидера, и мы также надеемся, что в системе будет только один лидер, но в некоторых особых случаях будет явление, когда несколько лидеров отдают приказы одновременно, то есть проблема с разделенным мозгом.
Проблема разделения мозга может возникнуть в следующих ситуациях:
Существует проблема с конфигурацией кластера самого zookeeper, из-за которой сам zookeeper становится разделенным.
Конфигурации зоофиторов нескольких серверов в том же кластере несовместимы.
На одном и том же IP развернуто несколько серверов планирования задач.
Мгновенная проблема сплит-мозговой мозги во время активного / резервного переключения службы планирования задач.
Первые три из них — это проблемы конфигурации, которые приложение не может решить.
Четвертый мгновенный разделенный мозг во время переключения активный/резервный показан на рисунке 4 ниже:
Феномен:
Первый подключается к zookeeper и успешно создает узел /leader.
T1: a Потеря связи с ZooKeeper, и A все еще думает, что вы являетесь Лидером.
t2: zookeeper обнаруживает, что время ожидания A истекло, поэтому он удаляет все временные узлы A, включая узел /leader. Поскольку B в это время отслеживает узел /leader, zookeeper также уведомит сервер B при удалении узла, а B попытается создать узел /leader сразу после получения уведомления.
t3: B успешно создал узел /leader и был избран лидером.
t4: Восстановление сети A. При повторном посещении ZK она обнаруживает, что потеряла разрешение лидера, и обновляет локальный флаг лидера = false.
Как можно видеть
Если машина A обнаружит, что не может подключиться к zookeeper после T1, если разрешение локального лидера не аннулировано, то в период времени T3-T4 может иметь место явление разделения мозга, то есть две машины A и B становятся лидерами. в то же время. . (Здесь, после того, как A находит тайм-аут, причина, по которой полномочия лидера не сразу становятся недействительными, связана с компромиссом между доступностью системы: минимизировать время без лидера. Поскольку, как только A находит тайм-аут, он немедленно аннулирует полномочия лидера. , это приведет к T1-T3. В течение этого периода времени лидера не существует, а влияние отсутствия лидера более серьезно, чем влияние двух лидеров).
Существует много причин для разделения мозга.Разделение мозга, вызванное некоторыми проблемами конфигурации, не может быть решено с помощью программ, и нельзя полностью избежать явления разделения мозга.Для обеспечения согласованности данных системы в случае расщепленный мозг.
Система принимает уникальное ограничение первичного ключа на основе базы данных: каждый раз, когда задача инициируется, будет время запуска (время расписания), которое с точностью до секунд.Если для одной и той же задачи, каждый раз, когда она инициирует выполнение, вставьте задачу в базу данных. Выполните таблицу потока, которая использует время запуска задачи + идентификатор задачи в качестве уникального первичного ключа, чтобы избежать влияния разделения мозга. Если два сервера инициируют задачи одновременно и оба имеют полномочия лидера, в это время один из серверов не сможет выполнить задачу из-за уникального ограничения первичного ключа базы данных, что приведет к отмене выполнения. (Поскольку в распределенной среде могут быть некоторые ошибки в часах нескольких серверов Legends. Если время запуска задачи слишком мало, все еще может быть проблема одновременного выполнения: машина A выполняет задачу в течение 01 секунды, а машина B выполняет задачу в течение 02 секунд.. Поэтому не рекомендуется, чтобы время запуска задачи было слишком коротким).
Откройте для себя клиент выживания
Прежде чем сервер отправит задачу, ему нужно знать, какие серверы активны.Конкретная реализация выглядит следующим образом:
После успешного начала клиента сервера приложений, машина будет зарегистрирована в IP Zookeeper (то есть создание временного узла)
Сервер планирования задач определяет, какие машины доступны, отслеживая данные дочернего узла узла /clients (здесь точки мониторинга используются для постоянного отслеживания изменений клиентских узлов).
Когда в системе есть задачи для отправки, серверу планирования нужно только запросить данные локального кэша, чтобы узнать, какие машины активны, а затем, в соответствии с политикой конфигурации задач, отправить задачу в список задач, подлежащих выполнению, на сервере. указанный клиент в zookeeper.
процесс выполнения задачи
Конкретный процесс запуска задачи показан на рисунке 6:
Описание потока:
Фреймворк Quartz инициирует выполнение задачи (если обнаружится, что текущая машина не является ведущей, она завершится сразу).
Сервер запрашивает данные локального кэша, находит список уцелевших серверов соответствующего приложения и выбирает исполняемый клиент в соответствии с настроенной политикой запуска задачи.
Запишите информацию о задаче в узел назначения задач (/assign), соответствующий клиенту, которому необходимо выполнить задачу в ZK.
-
Сервер приложений обнаруживает назначенную задачу, получает задачу и выполняет задачу.
Тут возникает проблема: что делать, если уцелевший клиент умирает сразу после отправки данных задачи в зк? Поскольку сервер планирования задач отслеживает изменения зарегистрированного узла клиента, после смерти сервера приложений сервер планирования задач получит уведомление о том, что клиент умер.В это время он может определить, соответствует ли узел назначения задач на клиенте есть задачи, которые были выделены, но еще не выполнены.Если есть задачи, удалите узел задач, утилизируйте необработанные задачи, а затем переназначьте задачи на другие уцелевшие серверы для выполнения (здесь работа клиент для выполнения задачи должен сначала удалить узел задачи в zookeeper, а затем выполнить задачу снова.Если узел задачи был удален, это означает, что задача была успешно выдана.Так как только один клиент zk может успешно выполнить удаление операции задача либо перезапускается сервером, либо удаляется сервером (выполнение на стороне клиента).
Эта проблема также приводит к некоторым другим проблемам, например, служба планирования задач обнаруживает, что сервер приложений мертв, и после перезапуска невыполненных задач сервера приложений внезапно отключается питание или теряются полномочия лидера, в результате чего потеря данных в памяти, что приведет к пропуску задачи.
Информационный поток для изменения задач
Когда пользователь изменяет или добавляет задачу в фоновом режиме сервера планирования задач, данные задачи необходимо синхронизировать со всеми серверами планирования задач.Поскольку данные задачи хранятся в БД, ЗК и памяти каждого сервера планирования, непротиворечивость данных задачи является основной проблемой, которую необходимо решить при обновлении задачи.
Последовательность обновления данных задачи показана на рисунке 7:
Пользователь подключается к серверу в кластере, изменяет данные задачи и отправляет их.
После того, как сервер получает запрос, он сначала обновляет данные БД ( версия + 1 ).
Асинхронно фиксирует изменения данных ZK (обновления данных Zookeeper также являются режимом, который вызывает оптимистичные обновления блокировки).
JOB Watcher на всех серверах следит за изменением данных задачи в ЗК, повторно запрашивает ЗК и обновляет данные памяти в локальном Кварце.
Поскольку трехэтапное обновление 2, 3 и 4 принимает оптимистичный режим обновления блокировки, и изменения всех данных задач эксплуатируются в согласованном порядке обновления, проблема параллельного обновления решена. Кроме того, причина, по которой принято причина асинхронного обновления зоотьевого завода, заключается в том, что клиентская программа Zookeeker - это однопоточный режим, любой синхронный код блокирует все асинхронные вызовы, тем самым уменьшая производительность всей системы, и есть также Риск SESSEXPIRED (ZOOOKETER ONE HEREAWES Исключение).
Трехшаговая операция, любой шаг может дать сбой, но нельзя добиться строгой согласованности, поэтому для решения проблемы несогласованности данных можно использовать только окончательную согласованность. Принятое решение состоит в том, чтобы использовать встроенный поток для запроса данных задачи, которые были обновлены в течение 5 минут, а затем сравнить и проверить три данных, чтобы сделать данные согласованными.
Кроме того, его также можно настроить следующим образом: zookeeper не хранит данные задачи, только когда данные задачи обновляются, он может отправить уведомление всем задачам сервера о наличии обновления.После того, как сервер планирования получит уведомление, он может напрямую запрашивать данные БД. Данные нужно только обновлять. Сохранять в БД с каждым сервером планирования.
Краткое изложение практики
Версия 1.0 системы планирования задач решает хаотичную проблему управления задачами компании и предоставляет единую платформу управления задачами. Версия 2.0 решает одноточечную проблему версии 1.0, и конфигурация задач относительно проще, но есть небольшая чрезмерная зависимость от zookeeper, а уровень приложения и уровень сеанса плохо разделены во время кодирования. есть еще много вариантов оптимизированное место.
об авторе
Лу Юнь, медные уличные фонды Инженер-инженер развития, присоединился к команде в декабре 2015 года, и в настоящее время несет ответственность за разработку проекта в группе поддержки фонда.
Для получения более интересного контента отсканируйте QR-код, чтобы подписаться на общедоступную учетную запись WeChat «Tongbanjie Technology».