1. Предпосылки

Временные задачи — неизбежная вещь в нашем редевелопменте, например, в некоторых системах электронной коммерции купоны на день рождения могут рассылаться пользователям регулярно, а в некоторых системах сверки аккаунты могут регулярно сверяться. Давным-давно у каждой службы мог быть только один компьютер, и Timerschedule непосредственно на этом компьютере мог в основном удовлетворить наши бизнес-потребности, но с изменением времени одна машина больше не может удовлетворить наши потребности. , в настоящее время нам может понадобиться 10, 20 или даже больше машин для ведения нашего бизнеса и приема нашего трафика, что мы называем горизонтальным масштабированием. Но здесь есть проблема, что произойдет, если так много машин все еще будут использовать наш Timerschedule? В приведенной выше системе электронной коммерции можно выдать много купонов на день рождения определенному пользователю, что приведет к большим потерям для компании, поэтому нам нужны некоторые другие методы, позволяющие выполнять запланированную задачу только один раз на несколько раз. машины.

Здесь я хотел бы спросить вас, как вы выполняете временные задачи, прежде чем вы знаете или используете структуру распределенного планирования задач? В проекте Spring все должны знать Spring-Scheduler, достаточно добавить соответствующий метод бина в Spring@SchedulerАннотация может завершить нашу временную задачу, но использование этой аннотации далеко не гарантирует, что временная задача будет выполнена несколько раз. Нам нужны какие-то другие средства гарантии. Вообще говоря, методы могут быть не более чем следующими (все основаны на проекте Spring ):

Машина, мы можем использовать выделенную службу поддержки для выполнения некоторых менее важных запланированных задач, а затем использовать одну машину для запуска, даже если она зависнет, пока мы восстанавливаем ее в течение приемлемого времени, наш бизнес не сможет .будет затронут.
Несколько компьютеров плюс распределенные блокировки, если мы сначала получаем распределенную блокировку при выполнении задачи, если получение не удается в течение длительного времени, это доказывает, что другие службы снова работают.Если приобретение успешно, это доказывает, что нет service выполняет запланированное задание, после чего может быть выполнено.
Несколько машин используют ZooKeeper для выполнения задач по времени на машине-лидере. Многие предприятия уже использовали ZK, поэтому при выполнении задач по времени определяйте, являетесь ли вы лидером. Если нет, не выполняйте его. Если да, выполняйте бизнес-логику. Наша цель .

В настоящее время наша компания также использует три вышеупомянутых метода для выполнения задач, рассчитанных на время.На ранней стадии бизнеса эти методы в основном могут быть удовлетворены.Однако с течением времени мы сталкиваемся со все большим количеством проблем.Позвольте мне поделиться с вами :

Первая проблема обособленного.Как поделить бизнес не очень важно.Эта часть по своей сути более сложная.Возможно каждый говорит что свое дело важное.Второе то что если обособленный зависнет, это может быть вниз, или это может быть другое. В некоторых случаях, как на этот раз мы можем гарантировать, что мы сможем восстановиться в приемлемом диапазоне, это все сложные моменты.
В настоящее время, когда мы используем временную задачу, если мы хотим, чтобы она выполнялась немедленно, нам может потребоваться написать дополнительный интерфейс Rest или написать отдельное задание в это время.
Другое дело, что нам нужно изменить время выполнения запланированной задачи.Например, есть требование, чтобы она выполнялась каждые 12 часов на каждые 6 часов.Мы должны изменить код, отправить пр, а затем запаковать и идти онлайн, просто измените время Это занимает у нас много времени.
Невозможно приостановить наши запланированные задачи.Когда наши запланированные задачи могут иметь некоторые проблемы, такие как потребность в некоторых запланированных сигналах тревоги, когда сигналов тревоги внезапно становится слишком много, нам нужно приостановить на некоторое время, чтобы прекратить отправку сигналов тревоги.В это время , мы можем использовать какой-то дистрибутив. Сделайте это с помощью переключателя типа конфигурации, а затем оцените, включен ли переключатель временной задачи в логике, а затем сделайте это. Это относительно просто, но нам нужно добавить новую логику, не связанную с задачей.
Отсутствует мониторинг запланированных задач, и разработчики не могут узнать об этом после сбоя задачи. Некоторые люди говорят, что журнала ошибок нет. Если журнал ошибок выдает сигнал тревоги в одно время, может ли ваш сервис это выдержать? это вызовет несколько последовательных ошибок.Тревога, и периодический характер нашей задачи по времени не так просто вызвать непрерывную ошибку.

Конечно, есть еще какие-то более-менее мелкие проблемы, которые здесь не перечислены.

2. Основные принципы исследования

В первой главе выше говорилось о причинах нашей структуры. Независимо от того, что вы хотите внедрить или улучшить, вам нужны причины, потому что все требует затрат. Я часто вижу, как некоторые небольшие проекты начинают внедрять очереди сообщений или распределенные транзакции и т. д. ., но это означает ставить телегу впереди лошади. Например, некоторые системы блогов могут реализовывать очередь сообщений, чтобы сократить пики и потоки, которые могут происходить не так быстро, как синхронные вызовы.

Когда у нас есть причины, мы можем начать проводить исследования или разрабатывать технические решения. Здесь я расскажу о некоторых основных принципах моей исследовательской структуры.Если в будущем у вас возникнут аналогичные потребности в исследовательской структуре, вы можете применить ее к этому.

Простой — легкий доступ для разработчиков и простой в использовании для пользователей.
Богатая документация, есть много проектов с открытым исходным кодом с очень небольшим количеством документов.Конечно, некоторые проекты с открытым исходным кодом имеют только документы на английском языке.Если вы не владеете английским языком, вам может потребоваться рассмотреть документы, которые в основном китайские.
Есть интерфейс управления, в котором очень удобно выполнять операции и вести статистику.
Поддержка основных фреймворков: таких как Spring, Springboot и т. д. Конечно, это должно как минимум поддерживать основные фреймворки в вашем бизнесе.
Платформа легкая и легко настраивается в соответствии с вашими потребностями.
Высокая производительность, высокая надежность и высокая доступность: инфраструктура не может быть узким местом в бизнесе.
Частота обновления кода и использование сообщества: чем больше компаний используют его, тем больше людей его любят. Чем выше частота обновления кода, тем меньше проблем будет. Лучше открывать исходный код и поддерживать его крупной компанией.
Многоязычные требования: если в вашем бизнесе есть многоязычные требования, например, ваша компания использует много языков разработки и требует структуры планирования, то вам необходимо использовать многоязычную поддержку. Например, представителем Rpc, поддерживающим несколько языков, является Thrift.
Можете ли вы решить текущую болевую точку: это самое главное, если вы не можете решить свою проблему, какой смысл использовать это?

Когда у нас есть вышеупомянутые принципы, мы можем приступить к исследованию.

3. Рамки исследования

3.1 TBSchedule

Как правило, при изучении некоторых фреймворков в отделе Java вы можете сначала проверить, есть ли у Alibaba открытый исходный код. В конце концов, Alibaba проделала очень хорошую работу в области открытого исходного кода в последние годы. Затем я провел поиск в Интернете и обнаружил, что Alibaba открыла фреймворк планирования. в 2012 году под названием TBSchedule, теперь поищите код и обнаружите, что код был очищен. Конечно, есть и личный проект, который его разветвляет и поддерживает постоянно, но пользователей там действительно мало, поэтому я не буду объяснять это здесь. адрес гитхаба:GitHub.com/Taobao/TBS C…

3.2 elastic-job

Elastic-Job — это решение для распределенного планирования с открытым исходным кодом от Dangdang, состоящее из двух независимых подпроектов: Elastic-Job-Lite и Elastic-Job-Cloud. Позиционируется как легкое децентрализованное решение, оно предоставляет услуги по координации распределенных задач в виде пакетов jar. Он поддерживает координацию распределенного планирования, гибкое расширение и сжатие, аварийное переключение, повторный запуск пропущенных заданий выполнения, параллельное планирование, самодиагностику и восстановление и т. д.

Этот фреймворк был очень популярен года 2 назад.В то время его использовали многие компании,и многие наверняка слышали о нем.К сожалению,сейчас он не поддерживается.Код не обновлялся 2 года.Это нарушает принцип частота обновления.Если возникнет проблема, помочь вам может некому, поэтому очень не рекомендуем. адрес гитхаба:GitHub.com/эластик-работа/…

3.3 Некоторые относительно нишевые

В Интернете есть несколько относительно небольших звезд github, и частота обновлений также очень мала: Uncode-Schedule, LTS, openCron и т. д., это тоже не соответствует нашим принципам и рассматриваться не будет.

3.4 XXL-JOB

Поскольку для распределенных задач синхронизации нет таких основ, как CNCF, Apache и т. д., выбор может оказаться не таким сложным. В отличие от очереди сообщений, в Apache их несколько: Kafka, Rocketmq, Plusar и т.д., у каждого из которых огромное комьюнити, и выбрать бывает сложно. Тогда у нас в основном остается два варианта. Один из них — самостоятельные исследования. Эта структура планирования задач гораздо менее сложна в разработке, чем исследование и разработка очередей сообщений. На самом деле, многие компании выбрали самостоятельные исследования, такие как: . Однако для некоторых сложных промежуточных программ, таких как очереди сообщений, может быть выбрана вторичная разработка.Например, mafka Meituan основана на вторичной разработке kafka, а DDMQ Didi также основана на Rocketmq. В настоящее время, если мы выбираем самоисследование, этого явно недостаточно с точки зрения ресурсов, здесь мы по-прежнему используем стратегию вторичного развития.

Конечно, осталась одна работа XXL:www.xuxueli.com/xxl-jobВыбор , который в основном соответствует нашим принципам, текущий код постоянно обновляется, автор проблемы также активно отвечает, и более 200 компаний используют его, включая предыдущие комментарии, и другие принципы также очень последовательны. Как правило, когда вы решаете выбрать фреймворк, вам необходимо подробно перечислить преимущества, чтобы убедить других.

xxl-job имеет следующие особенности:

Простота: поддержка операций CRUD над задачами через веб-страницы, операция проста, и вы можете начать работу за одну минуту;
Динамический: поддерживает динамическое изменение состояния задачи, запуск/остановку задач и завершение запущенных задач с немедленным эффектом;
Высокая доступность центра планирования (централизованная): планирование принимает централизованный дизайн.«Диспетчерский центр» самостоятельно разработал компоненты планирования и поддерживает развертывание кластера, что может обеспечить высокую доступность центра планирования;
Executor HA (распределенный): Распределенное выполнение задач, задача «исполнитель» поддерживает кластерное развертывание и обеспечивает выполнение задачи HA;
Центр регистрации: исполнитель будет периодически автоматически регистрировать задачи, а центр планирования автоматически обнаружит зарегистрированные задачи и инициирует выполнение. В то же время он также поддерживает ручной ввод адреса привода;
Расширение и сокращение гибкой емкости: как только новый компьютер-исполнитель подключается к сети или отключается, задача будет переназначена в следующий раз, когда она будет запланирована;
Стратегия маршрутизации. Кластер исполнителей предоставляет разнообразные стратегии маршрутизации, в том числе: первый, последний, циклический, случайный, непротиворечивый HASH, наименее часто используемый, последний неиспользованный, отработка отказа, занятая передача и т. д.;
Отказоустойчивость: когда политика маршрутизации задач выбирает «отказоустойчивость», в случае сбоя машины в кластере исполнителей она автоматически переключается на обычный исполнитель для отправки запросов планирования.
Стратегия блокирующей обработки. Стратегия обработки, когда планирование слишком интенсивно для выполнения исполнителем, стратегии включают в себя: автономный последовательный (по умолчанию), отбрасывание последующего планирования и перезапись предыдущего планирования;
Запуск события: в дополнение к «режиму Cron» и «зависимому от задачи режиму», запускающему выполнение задачи, поддерживаются задачи запуска на основе событий. Диспетчерский центр предоставляет сервисы API, запускающие однократное выполнение задач, которые можно гибко запускать в соответствии с бизнес-событиями.
Мониторинг выполнения задачи: поддержка мониторинга хода выполнения задачи в режиме реального времени;
Прокручивающийся журнал в реальном времени: поддержка онлайн-просмотра результатов планирования и поддержка просмотра в реальном времени полного журнала выполнения, выводимого исполнителем в прокручивающемся режиме.

По сути, некоторые из вышеперечисленных функций необходимы в нашем бизнесе, поэтому здесь окончательно выбран XXL-JOB.

4. Резюме

Как говорится: Лучше научить человека ловить рыбу, чем научить его ловить рыбу. В предыдущих статьях всегда вводилась структура того-то и того-то. В этот раз я предпочитаю представить, как я выбрал эту основу, поэтому что каждый может сделать это в процессе будущих исследований.Согласно этой идее, если у вас также есть хорошие и разные исследовательские идеи, вы можете оставить сообщение или присоединиться к группе для общения. Конечно, после завершения общего исследования, как исследователь, если вы не понимаете исходный код и принцип реализации этого фреймворка, то вы неквалифицированный исследователь, поэтому в следующей статье я представлю принцип реализации XXL. -Работа в деталях.

Если вы считаете, что эта статья полезна для вас, то ваше внимание и пересылка - самая большая поддержка для меня, O(∩_∩)O: