LTS和其余解决方案的比较(官方)

主要根据LTS支持的几种任务（实时任务、定时任务、Cron任务，Repeat任务）和其余一些 开源框架在应用场景上作比较。

实时任务，实时执行

这种场景下，当任务量比较小的时候，单机均可以完成的时候．本身采用线程池或者去 轮训数据库取任务的方式（或者其余方式）就能够解决 · 但若是是任务执行时间比较长 或者任务量比较大，单机不足以知足需求的时候，就须要本身去作分布式的功能，还有 很重要的是，怎么作容错，怎么保证同一个任务只被一个节点执行，怎么解决执行失败 异常的情形等等，你就须要本身去作不少事情，头可能就大了。这时候 LTS 就派上用场 了．由于这些问题 LTS 都帮你解决了，你只需关注你的业务逻辑，而不用为上面的这些 事情而烦恼。固然这时候有人可能会想到若是用 MQ 去解决，利用 MQ 的异步去解耦， 也同时能够实现分布还有容错等。固然有时候是能够的，为何说是能够的呢，由于 LTS 的架构也和 MQ 的相似， JobClient 至关于 MQ 的 Producer , JobTracker 至关于 MQ 的 Broker , TaskTracker 至关于 MQ 的 Consumer ，通过我这么一说，是否是以为 貌似是很像哈。可是我又为何说是有时候是能够的呢，而不是必定是能够的呢，由于 若是你同一个任务（消息）提交 MQ 两次． MQ 队列中有两条一样的任务消息，那么当 你这个任务不能有两个节点同时执行的时候（同时执行一个任务可能出现各类问题） , MQ 就不能知足了，由于他不知道你这两条消息是同一个任务，它会把这两条消息可能 会发给两个不一样的节点同时执行（或者同一个节点的不一样线程去执行），这时候你就需 要本身去作一些事情去保证同一个任务不能同时被两个线程（或节点）去执行问题，这 时候头又大了，那么 LTS 又派上用场了，觉得 LTS 就能够保证这一点。说到任务调度． 不少人一下就想到了 QuartZ ，对于这种实时任务的状况． QuartZ 是不太适合的，它也 不能很好的解决故障转移（譬如执行中的节点忽然停掉了， QuartZ 不能将这个执行中的 任务立马分配给其余节点执行，最多设置了 QuartZ 的可恢复性，在停掉的节点重启以后 从新执行该任务．但若是这个节点不再启动起来了呢？那就只能呵呵了）等问题，这 类场景 QuartZ 就不作比较了。有些人可能问，说了这么多，你却是举个例子呀。嗯，我 举几个例子： 1 ．发短信验证码，这种能够用 MQ 去实现，也能够单机去实现（若是你 量不大的话），固然 LTS 也是能够的．若是你量很是很是大的话，建议仍是用性能比较 好的 MQ 代替 2 ．实时的给在线用户算数据，触发者是用户本身（本身手动点），可是 算任务的只能同时由一个线程去执行，这是就能够用 LTS 了。

定时任务

某个时间点触发这种场景下，和实时任务相比，只有一个不一样，就是要指定一个时间点 去执行，多是 1 个小时以后，多是 1 天以后．也多是 1 天，小时以后。有些人可 能用轮训的业务数据库的方式去解决，轮训业务数据库有什么问题呢．固然你数据量很 小我就不说了。若是你数据量还比较大的状况下，轮训数据库，势必会影响业务查询， 若是有其余业务查询的话。还有就是对于分布式的支持不是很好，还有当表中存在多种 不一样执行（延迟）时间的任务，这个轮训频率就比较关键了，过短，影响性能，太长， 影响业务，执行不及时．致使任务执行延迟过久，等等。这时候若是用MQ ，虽然有些 MQ 支持延迟队列 (RabbitMQ , RocketMQ 等）．但他们都是指定的一些特定的 Level 级 别延迟，可是不支持任意时间精度．譬如， 1 min , 5 min . 10 min 等等，但若是是 7 分 钟，或者 20 天以后呢。若是 MQ 支持任意时间精度，那么它的性能就只能呵呵了，这 种状况 MQ 就排除了，可是若是 MQ 的这些特定的 Level 恰好知足你的需求，那么选 MQ 也是能够的。再说说 Quartz吧， Quartz 能够支持定时任务．支持某个时间点触发， 也支持集群，它在架构上是分布式的，没有负责几种管理的节点。 Quartz 是经过数据库 行级锁的方式实现多线程之间任务争用的问题。行锁有嘟些特色呢，开销大，加锁慢， 会出现死锁，并发度相比表级锁，页级锁高一点。可是在任务量比较大的时候，并发度 较大的时候，行级锁就显得比较吃力了，并且很容易发生死锁。那么 LTS 是怎么解决并 发性的问题的呢， LTS 采用预加载和乐观锁的方式，批量的将部分要执行的任务预加载 到内存中，因此在取任务的时候只须要两步： 1 ．从内存中取到一个任务，固然内存中 保证同一个线程拿到同一个任务是很容易的也是很高效的， 2 ．将拿到的这个任务对应 的数据库记录锁住，那么这里采用乐观锁， CAS 的方式去修改记录（若是任务己经被别 的节点拿走了，那么从新执行 1 , 2 步，这种己经被别的节点拿走的状况，主要是在多个 JobTracker 的情形下，单个 JobTracker 不会出现这种状况，可是在多个 JobTracker 下，内存中的预加载数据采用不一样步长的方式来减少两个 JobTracker 内存中数据重复的 几率，很好的解决了这个问题，这里稍微提下 》 ，因此这个时候LTS相对于QuartZ 的优 势一下就体现出来了。还有就是上面说的 Quartz 对故障转移作的不是很好。还有就是当 QuartZ 对应的 MySQL 数据库挂了，这时候问题就来了客户端提交的任务提交不成功 了，那么有人会想将这些数据保存在内存中，等 MySOL 重启起来了再重试提交，那么 若是你当前节点也挂了呢，你内存中的数据就会所有丢失了．因此这时候你须要本身额 外的去作一些失败任务本地持久化的工做．不过若是你用LTS的话， LTS 支持Failstore ，任务提交失败了，自动帮你本地持久化，而后待 JobTracker 可用的时候重试，无论你 是 JobTracker 挂了，仍是 JobTracker 对应的数据库挂了，都是 ok 的。举个例子吧，在 一个小时以后给某些用户发短信，或者当用户点击退款操做以后，从点击退货的这个时 间点开始， n 天后将这个退款关闭。

周期性任务(Cron,Repeat)

这种场景下，和定时任务相比，不同的地方，就只有．这个是会重复执行的，至关于 重复执行的定时任务。因此这种场景下的对比，能够继续考照定时任务的对比。 LTS在 这种场景下提供的特性有，提供统一的后台监控和后台管理。当某次定时任务执行失 败，会执行重试操做，并提供执行日志．