Distributed Task Scheduling Alternatives

 1. In addition to the JVM-based java, a new JVM language - SCALA, a script-oriented and function-oriented language at the same time, the spark big data framework is based on the scala language. According to the online tutorial, I simply wrote a few examples. I feel that there are still some differences in the context of object, class and java, but they are well integrated with the java system, and the groovy language is a relatively small and agile language. Class, but not really practical, this year to be a simple practical application.

 

2. In the process of searching for API GATEWAY open source products, in addition to the netflix zuul component, I found that the KONG component can be applied. It is implemented based on openresty. At the same time, openrestry is implemented in lua language. It is a small but powerful scripting language with simple contact with lua. JD's Kaitao used nginx + lua programming to solve many problems in the high concurrency scenario of JD.com pages. KONG implements access control of interface gateways, request current limiting, distribution, monitoring, load balancing, etc. KONG is based on data storage and implemented with the help of postgresql or cassandra database.

 

3. The Quartz component has been used all the time, but the mechanism of misfire is not involved. For practical application scenarios, different strategies can be adopted to deal with it. The commonly used xml configuration method is based on the RAMJOBSTORE method, and there is also a JDBCJOBSTORE method, which uses the database to store tasks and supports different databases. At the same time, the configuration of the cluster is realized by using jdbcjobstore. However, the coupling is relatively strong, and the task scheduling and execution can be separated to operate, to separate the scheduling and execution, and improve the operating efficiency and scalability.

 

4. The open source product of xxl-job perfectly implements this method. The admin configuration, scheduling center, and executor are independently deployed. When deploying, it can be deployed in two ways: jar or war. Due to the built-in jetty middleware, there is no obstacle in the communication method. A central, multiple cluster high-availability executor, task monitoring, and task logs at a glance. xxl-job is based on the database to jointly manage tasks, which is a good distributed task scheme. In addition, there are options for Tbschedule and elstic-job, both of which are based on db and can also be implemented based on zookeeper middleware.

 

I just understand that it has not been practically applied to the project, and it is necessary to test the reliability and feasibility.

 

Follow the official account to get more related skills

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326569983&siteId=291194637