background

The code for automatic registration and heartbeat detection of xxl-job is fairly concise, and this article continues to examine how the JobRegistryHelper class is implemented. It’s only a couple of hundred lines, but it’s worth looking at.

This paper will elaborate on two issues:

  1. How does xxL-job detect the offline Executor and update cluster information?
  2. Who initiates the heartbeat detection of the executor of xxL-job and what is performed in the background?

JobRegistryHelper class diagram structure

JobRegistryHelper implements the above two functions. It has a class diagram structure:

Disassembling the class:

  1. A singleton class.
  2. There is a thread poolregistryOrRemoveThreadPoolTo asynchronously process Executor registration requests and update the Registry tableupdate_timeField.
  3. There is a polling threadregistryMonitorThread, pollingfindDeadThe result set of delete lost records, traversalfindAllThe active actuator updates the Group cluster dataaddress_listField.

The process of detecting the offline actuator and updating the cluster

This class starts a polling thread, registryMonitorThread, whose run does only two things:

  1. findDeadIf the actuator has not been updated within 90 seconds, it will be regarded as invalid record and deleted;
  2. findAllQuery the valid actuator to the actuator’sapp_nameTo the corresponding cluster in the Group tableaddress_listField.

With this thread, the control platform can automatically sense the actuator up and down the line, use two SQL can be seen:

<select id="findDead" parameterType="java.util.HashMap" resultType="java.lang.Integer" > SELECT t.id FROM xxl_job_registry AS t WHERE t.update_time <! [CDATA[ < ]]> DATE_ADD(#{nowTime},INTERVAL -#{timeout} SECOND) </select> <select id="findAll" parameterType="java.util.HashMap" resultMap="XxlJobRegistry"> SELECT <include refid="Base_Column_List" /> FROM xxl_job_registry AS t WHERE t.update_time <! [CDATA[ > ]]> DATE_ADD(#{nowTime},INTERVAL -#{timeout} SECOND) </select>Copy the code

The findDead condition is update_time < nowtime-timeout [90 seconds], that is, the last update time is 90 seconds before the heartbeat interval of the executor is 30 seconds. If the heartbeat interval exceeds this interval, the connection is lost.

FindAll, on the other hand, update_time > nowtime-timeout [90 seconds].

It is important to ensure that the time difference between the database server and the executor host is no more than 90 seconds if you use NOW() or sysdate instead of nowTime. Otherwise, Admin will never detect the live actuator.

Executor registration process

The initial process of tracking heartbeat checks starts with the Executor side looking for the beat keyword, but this heartbeat request is made by the Admin side before the scheduled run is triggered and does not involve updating the Registry table. So give up this idea and start with the invocation of the DAO on the admin side.

XxlJobRegistryDaoClass that operates on the Registry tableregistryUpdateThe method is only called in one place, and that isJobRegistryHelperCode for asynchronously submitting tasks:Continue to followregistryTo the API section of the Admin module:It is the Executor side’s API for sending registration requests to the Admin center. I don’t think it’s appropriate to define “Registry” here, which is essentially a heartbeat thread on the Executor side that sends registration requests to the registry every 30 seconds.

Therefore, the answer to the second question is that the Executor side automatically sends a heartbeat to Admin, which then updates the update_time field of the record in the XXL_job_registry table. This field will be used by the admin module to determine whether the Executor is offline or offline.

The revelation of

Today I heard a voice, about the career fast track, good candidates should be learning machines, continuous learning, continuous learning. In the past three years, I have become more aware of my learning thinking and habits. I no longer reject learning new technologies, try to view problems with an open mind, and feel less tangled problems.

At this point, the study notes on XXL-job framework output is finished. Throughout these distributed task scheduling frameworks, the core idea is very similar to micro-service ideas. No system has played SpringCloud, and the next work will use SpringCloud. With an open mind, continue to learn, really learning is endless wow!