CN107621975B - TIMER logic implementation method based on JAVA TIMER high availability - Google Patents
TIMER logic implementation method based on JAVA TIMER high availability Download PDFInfo
- Publication number
- CN107621975B CN107621975B CN201710813834.8A CN201710813834A CN107621975B CN 107621975 B CN107621975 B CN 107621975B CN 201710813834 A CN201710813834 A CN 201710813834A CN 107621975 B CN107621975 B CN 107621975B
- Authority
- CN
- China
- Prior art keywords
- time
- task
- timer
- running
- logic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The invention aims to provide a TIMER logic implementation method based on JAVA TIMER high availability, which ensures that only one scheduling module can preempt the operation right of a task at the same time through a contention mechanism, so that the operation of service logic meets the expectation of a user; meanwhile, a plurality of service execution modules are deployed, if one service execution module fails to execute, the executed logic can be transferred to another server deploying the service execution module by modifying the URL address, and the recovery speed of the failure is greatly improved.
Description
Technical Field
The invention relates to a high-availability TIMER logic implementation method based on JAVA TIMER.
Background
Most of the existing software products are used in the production environment of customers to provide services for the commercial use of the customers. This requires high availability of software products and architectures that can recover in time in the event of a failure, while reducing human intervention. There is an application scenario that needs to execute specific task logic regularly, and the task logic is generally implemented by a timer in software development. Most of the TIMERs in JAVA are implemented by TIMER and Spring Quartz of a third party, and there is no problem in executing task codes at regular time, and even the execution time of the task is very accurate. How to increase the availability of timers and the fault recovery capability becomes a problem when deployed to a production environment.
The existing software timer, no matter what technology is used for realizing, generally combines and writes the task scheduling logic and the business logic together, which causes a problem: once the server deploying the timer fails, the whole timer stops working and the availability is not high. If the timer is deployed with a plurality of services, how to coordinate scheduling among the same timers becomes a difficult problem, because only one timer needs to execute the service logic at the same time, and the execution of the same service logic by a plurality of timers may cause original logic confusion.
Disclosure of Invention
The invention provides a TIMER logic implementation method based on high availability of JAVA TIMER, aiming at improving the availability of a TIMER, separating the TIMER scheduling from service logic and realizing the scheduling implementation of a plurality of TIMERs for the same task.
In order to achieve the purpose, the invention adopts the following technical scheme: a TIMER logic implementation method based on JAVA TIMER high availability is characterized in that: the method comprises the following steps: s1: the TIMER is realized by adopting a JAVA TIMER mode, and task scheduling is executed at certain time intervals according to set parameters; s2: the service execution module is responsible for specific service logic, and the execution of the service module is triggered only when the task scheduling module meets the condition, and the main execution mode is as follows: when the task scheduling module judges that the task can be executed according to the realization logic of the task scheduling module, the HTTP request is sent to the JSP of the service execution module, and the JSP is used as an entrance to enter the execution of the service logic. S3: deploying task scheduling execution modules of the timers to N application servers according to a contention principle among the same timers, contending operation authorities of corresponding tasks by the timing task scheduling modules on the N application servers through a contention mechanism, and performing HTTP access according to a configured URL address of a service execution module to execute service logic after the task scheduling modules contend the operation authorities; n is a natural number of 2 or more.
Compared with the prior art, the invention has the following advantages: through a contention mechanism, the operation right of a task is guaranteed to be contended by only one scheduling module at the same time, so that the operation of the service logic meets the expectation of a user; meanwhile, a plurality of service execution modules are deployed, if one service execution module fails to execute, the executed logic can be transferred to another server deploying the service execution module by modifying the URL address, and the recovery speed of the failure is greatly improved.
Drawings
Fig. 1 is a schematic diagram of a framework according to an embodiment of the present invention.
Detailed Description
The invention is further explained below with reference to the figures and the specific embodiments.
The invention aims to provide a high-availability TIMER logic implementation method based on JAVA TIMER. Which comprises the following steps: s1: the TIMER is realized by adopting a JAVA TIMER mode, and task scheduling is executed at certain time intervals according to set parameters; s2: the service execution module is responsible for specific service logic, and the execution of the service module is triggered only when the task scheduling module meets the condition, and the main execution mode is as follows: when the task scheduling module judges that the task can be executed according to the realization logic of the task scheduling module, the HTTP request is sent to the JSP of the service execution module, and the JSP is used as an entrance to enter the execution of the service logic. S3: deploying task scheduling execution modules of the timers to N application servers according to a contention principle among the same timers, contending operation authorities of corresponding tasks by the timing task scheduling modules on the N application servers through a contention mechanism, and performing HTTP access according to a configured URL address of a service execution module to execute service logic after the task scheduling modules contend the operation authorities; n is a natural number of 2 or more.
In an embodiment of the present invention, the task scheduling executed by TIMER in S1 in the set time interval includes the following steps:
s11: inquiring records of the THREAD number THREAD _ MODE corresponding to the task information table according to the THREAD number THREAD _ MODE transmitted into the TIMER;
s12: traversing the inquired records, comparing NEXT running TIME NEXT _ TIME and current TIME of the task, exiting to enter the NEXT TIMER task scheduling period if the current TIME is less than NEXT _ TIME, and modifying the real-TIME running state RUN _ STATUS of the task real-TIME state table to be 'running' if the current TIME is more than NEXT _ TIME;
s13: when the current TIME is greater than NEXT _ TIME, sending an HTTP request to a URL configured in a URL address field executed by the service logic, and executing the service logic;
s14: automatically calculating the NEXT running TIME according to the task running period field and the NEXT _ TIME field and updating the NEXT running TIME to the NEXT _ TIME, and updating the TIME in the original NEXT _ TIME field to the LAST task running TIME LAST _ TIME field;
s15: updating the real-time running state RUN _ STATUS of the task real-time state table to be 'stop';
s16: and recording the operation result to a task operation log table.
And each TIMER repeatedly executes own task according to S11-S16, if a plurality of TIMER services are deployed, the RUN _ STATUS field of the real-time state table is updated to the running TIMER to obtain the running right of the task among a plurality of TIMER threads according to a contention principle, and other timing task threads which do not obtain the running right return to the first step of the running period to start to repeatedly RUN.
In order to improve the usability and reduce the manual intervention degree, the general idea of the invention is to perfect the scheduling logic of the timer and separate the scheduling from the business logic. And simultaneously, the high availability of a plurality of timers for the same service logic is realized.
The overall module can be divided into: a task scheduling module and a service logic module, which will be introduced below.
Task scheduling module
The module mainly realizes the task scheduling function, and the related main tables comprise:
1. UCSS _ POS _ HTTP _ CONFIG: task information table
The URL of the service module, the scheduling information of the task, the task state and the like are configured, and the main fields and functions are as follows:
URL Address for lEXECUTE _ URL service logic execution
last TIME run TIME of the LAST _ TIME task
Next run TIME of lnnext _ TIME task
Run _ CYCLE task CYCLE, adding LAST _ TIME to yield the TIME of NEXT _ TIME
lRUN _ STATUS task valid State
The lTHREAD _ MODE thread number is used, and each task is only operated by the task under the own thread number
2. UCSS _ POS _ HTTP _ STATE: task real-time status table
The real-time status of a certain task can be checked in real time from the table, and the main fields and functions are as follows:
lRUN _ STATUS task real-time running state
Running the LRUN _ TIME task takes TIME
3. UCSS _ POS _ HTTP _ RUN _ LOG: task running log table
For recording the operation result and time consumption of each task, the main fields and functions are as follows
Run TIME of the LRUN _ TIME task, TIME consumed for this task execution
The running result of the LRUN _ RETURN task calls the URL of the service module, namely the status code returned after accessing the URL configured in the EXECUTE _ URL field
According to the main tables and the function fields, the TIMER is realized in a JAVA TIMER mode, and the TIMER can run service logic at a certain time interval according to set parameters. Each TIMER may run only one task or multiple tasks. In the embodiment of the present invention, the running time interval of the TIMER is 1 minute, and the task scheduling cycle logic executed by the TIMER in this 1 minute is:
1. and inquiring the record of the UCSS _ POS _ HTTP _ CONFIG table corresponding to the READ _ MODE according to the READ _ MODE parameter of the incoming TIMER.
2. Traversing the inquired records, comparing NEXT _ TIME with current TIME, exiting to enter NEXT TIMER task scheduling period if the current TIME is less than NEXT _ TIME, and modifying the real-TIME running STATE RUN _ STATUS of UCSS _ POS _ HTTP _ STATE table to be 'running' if the current TIME is more than NEXT _ TIME "
3. And when the current TIME is greater than the NEXT _ TIME, simultaneously judging whether the RUN _ STATUS field of the task state table is 'stop', if the RUN _ STATUS field is 'stop', sending an HTTP request to the URL configured in the EXECUTE _ URL field, and executing the service logic. And if the RUN _ STATUS field of the task state table is 'operation', the task is operated by the task scheduling module of other TIMERs at the moment, the task scheduling is terminated and the task exits to enter the next TIMER task scheduling period.
4. Automatically calculating the NEXT operation TIME according to the RUN _ CYCLE field and the NEXT _ TIME field and updating to NEXT _ TIME, wherein the TIME in the original NEXT _ TIME field is updated to the LAST operation TIME LAST _ TIME field
5. Updating the real-time running STATE RUN _ STATUS of the UCSS _ POS _ HTTP _ STATE table to be 'stop', and releasing the running right of the task
6. And recording the operation result to a UCSS _ POS _ HTTP _ LOG table, so that the operation result of the task is conveniently tracked.
And each TIMER repeatedly executes own task according to the logic, if a plurality of TIMER services are deployed, the RUN _ STATUS field of the real-time state table is firstly updated to the running TIMER to obtain the running right of the task among a plurality of TIMER threads according to a contention principle, and other timing task threads which do not obtain the running right return to the first step of the running period to start to repeatedly RUN. Therefore, even if the timing task deployed on one server fails, other timing tasks can be continued in time, and high availability of the timer is guaranteed.
(II) service execution module
The service execution module is mainly a specific service logic and runs the service code according to the expectation of the client. The service execution module does not actively execute at ordinary times, and the execution of the service module is triggered only when the task scheduling module meets the condition, and the main execution mode is as follows: when the task scheduling module judges that the task can be executed according to the realization logic of the task scheduling module, the HTTP request is sent to the JSP of the service execution module, and the JSP is used as an entrance to enter the execution of the service logic.
In one embodiment of the present invention, N is 2. According to the logic implementation of the above timers and according to the contention principle among the same timers, the timer task scheduling module can be deployed with a plurality of servers, as shown in fig. 1, taking the deployment of 2 servers as an example, a specific deployment architecture is as follows:
and deploying the timed task scheduling execution module to the two application servers, wherein the timed task scheduling modules on the two application servers contend for the operation authority of the corresponding task through the contention mechanism, and when the scheduling module contends for the operation authority, HTTP access is carried out according to the configured URL address of the service execution module to execute service logic. Therefore, through a contention mechanism, the operation right of the task is guaranteed to be contended by only one scheduling module at the same time, so that the operation of the service logic meets the expectation of a user. Meanwhile, the reason for deploying a plurality of service execution modules is that: because the entry executed by the service execution module is the URL address, if one service execution module fails to execute, the executed logic can be transferred to another server deployed with the service execution module by modifying the URL address, thereby greatly improving the recovery speed of the failure.
The above are preferred embodiments of the present invention, and all changes made according to the technical scheme of the present invention that produce functional effects do not exceed the scope of the technical scheme of the present invention belong to the protection scope of the present invention.
Claims (2)
1. A TIMER logic implementation method based on JAVA TIMER high availability is characterized in that: the method comprises the following steps:
s1: the TIMER is realized by adopting a JAVA TIMER mode and comprises a task scheduling module and a service execution module; the TIMER executes task scheduling at a certain time interval according to set parameters;
s2: the service execution module is responsible for specific service logic, and the execution of the service module is triggered only when the task scheduling module meets the condition, and the main execution mode is as follows: when the task scheduling module judges that the task can be executed according to the realization logic of the task scheduling module, the task scheduling module sends an HTTP request to a JSP (Java Server Page) of the service execution module, and the JSP is used as an entrance to enter the execution of the service logic;
s3: deploying task scheduling execution modules of the timers to N application servers according to a contention principle among the same timers, contending operation authorities of corresponding tasks by the timing task scheduling modules on the N application servers through a contention mechanism, and performing HTTP access according to a configured URL address of a service execution module to execute service logic after the task scheduling modules contend the operation authorities; n is a natural number more than or equal to 2;
the task scheduling executed by TIMER in the set time interval of S1 includes the following steps:
s11: inquiring records of the THREAD number THREAD _ MODE corresponding to the task information table according to the THREAD number THREAD _ MODE transmitted into the TIMER;
s12: traversing the inquired records, comparing NEXT running TIME NEXT _ TIME and current TIME of the task, exiting to enter the NEXT TIMER task scheduling period if the current TIME is less than NEXT _ TIME, and modifying the real-TIME running state RUN _ STATUS of the task real-TIME state table to be 'running' if the current TIME is more than NEXT _ TIME;
s13: when the current TIME is greater than NEXT _ TIME, sending an HTTP request to a URL configured in a URL address field executed by the service logic, and executing the service logic;
s14: automatically calculating the NEXT running TIME according to the task running period field and the NEXT _ TIME field and updating the NEXT running TIME to the NEXT _ TIME, and updating the TIME in the original NEXT _ TIME field to the LAST task running TIME LAST _ TIME field;
s15: updating the real-time running state RUN _ STATUS of the task real-time state table to be 'stop';
s16: and recording the operation result to a task operation log table.
2. The method of claim 1, wherein the TIMER logic is implemented based on JAVA TIMER high availability, and wherein: and each TIMER repeatedly executes own task according to S11-S16, if a plurality of TIMER services are deployed, the RUN _ STATUS field of the real-time state table is updated to the running TIMER to obtain the running right of the task among a plurality of TIMER threads according to a contention principle, and other timing task threads which do not obtain the running right return to the first step of the running period to start to repeatedly RUN.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710813834.8A CN107621975B (en) | 2017-09-11 | 2017-09-11 | TIMER logic implementation method based on JAVA TIMER high availability |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710813834.8A CN107621975B (en) | 2017-09-11 | 2017-09-11 | TIMER logic implementation method based on JAVA TIMER high availability |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107621975A CN107621975A (en) | 2018-01-23 |
CN107621975B true CN107621975B (en) | 2020-08-21 |
Family
ID=61088480
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710813834.8A Active CN107621975B (en) | 2017-09-11 | 2017-09-11 | TIMER logic implementation method based on JAVA TIMER high availability |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107621975B (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109254838B (en) * | 2018-08-21 | 2021-11-23 | 中邮科通信技术股份有限公司 | JAVA-based automation task of BeanShell |
CN112256416A (en) * | 2020-10-22 | 2021-01-22 | 上海英方软件股份有限公司 | Method and system for realizing complex task scheduling and simultaneously cleaning data |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7526551B1 (en) * | 2003-10-01 | 2009-04-28 | Sun Microsystems, Inc. | System and method for highly available timer service in a J2EE cluster |
US7793299B2 (en) * | 2005-08-30 | 2010-09-07 | International Business Machines Corporation | System and method for scheduling tasks for execution |
US9384103B2 (en) * | 2006-05-16 | 2016-07-05 | Oracle International Corporation | EJB cluster timer |
US9292342B2 (en) * | 2012-12-26 | 2016-03-22 | Microsoft Technology Licensing, Llc | Schedule based execution with extensible continuation based actions |
CN103744724A (en) * | 2014-02-19 | 2014-04-23 | 互联网域名系统北京市工程研究中心有限公司 | Timed task clustering method and device thereof |
CN105631006B (en) * | 2015-12-28 | 2019-03-29 | 杭州东方通信软件技术有限公司 | A kind of data dispatch acquisition device and method |
CN105955811A (en) * | 2016-05-05 | 2016-09-21 | 北京思特奇信息技术股份有限公司 | System and method for achieving task scheduling based on remote invoking mode |
CN106126332A (en) * | 2016-06-27 | 2016-11-16 | 北京京东尚科信息技术有限公司 | Distributed timing task scheduling system and method |
CN107092523A (en) * | 2017-04-14 | 2017-08-25 | 浙江数链科技有限公司 | The dispatching method and system of timed task |
-
2017
- 2017-09-11 CN CN201710813834.8A patent/CN107621975B/en active Active
Also Published As
Publication number | Publication date |
---|---|
CN107621975A (en) | 2018-01-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9984140B1 (en) | Lease based leader election system | |
US8856374B2 (en) | Methods and systems for reconfiguration and repartitioning of a parallel distributed stream process | |
CN109558234B (en) | Timed task scheduling method and device | |
US20180270297A1 (en) | Command processing in distributed computing systems | |
CN106325984B (en) | Big data task scheduling device | |
CN106790694A (en) | The dispatching method of destination object in distributed system and distributed system | |
CN113656157B (en) | Distributed task scheduling method and device, storage medium and electronic equipment | |
CN110895484A (en) | Task scheduling method and device | |
CN105554142B (en) | The method, apparatus and system of message push | |
CN110704185B (en) | Cluster system fragmentation timing task scheduling method and cluster system | |
CN107621975B (en) | TIMER logic implementation method based on JAVA TIMER high availability | |
CN110895483A (en) | Task recovery method and device | |
Chan et al. | Reliableweb services: Methodology, experiment and modeling | |
CN110895486B (en) | Distributed task scheduling system | |
CN103500119A (en) | Task allocation method based on pre-dispatch | |
CN110895488A (en) | Task scheduling method and device | |
CN110704172B (en) | Cluster system timing task scheduling method and cluster system | |
CN113220431A (en) | Cross-cloud distributed data task scheduling method, device and storage medium | |
CN105450737B (en) | A kind of data processing method, device and system | |
CN111831424A (en) | Task processing method, system and device | |
CN107368498A (en) | The lock for optimizing MySQL Pessimistic Lockings waits the method and device of time-out time | |
CN110895485A (en) | Task scheduling system | |
CN109558254B (en) | Asynchronous callback method, system, device and computer readable storage medium | |
CN111625414A (en) | Method for realizing automatic scheduling monitoring system of data conversion integration software | |
CN111158930A (en) | Redis-based high-concurrency time-delay task system and processing method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |