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:
- How does xxL-job detect the offline Executor and update cluster information?
- 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:
- A singleton class.
- There is a thread pool
registryOrRemoveThreadPool
To asynchronously process Executor registration requests and update the Registry tableupdate_time
Field. - There is a polling thread
registryMonitorThread
, pollingfindDead
The result set of delete lost records, traversalfindAll
The active actuator updates the Group cluster dataaddress_list
Field.
The process of detecting the offline actuator and updating the cluster
This class starts a polling thread, registryMonitorThread, whose run does only two things:
findDead
If the actuator has not been updated within 90 seconds, it will be regarded as invalid record and deleted;findAll
Query the valid actuator to the actuator’sapp_name
To the corresponding cluster in the Group tableaddress_list
Field.
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.
XxlJobRegistryDao
Class that operates on the Registry tableregistryUpdate
The method is only called in one place, and that isJobRegistryHelper
Code for asynchronously submitting tasks:Continue to followregistry
To 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!