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

转载：https://www.cnblogs.com/jager/p/6385420.html

主要根据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在 这种场景下提供的特性有，提供统一的后台监控和后台管理。当某次定时任务执行失 败，会执行重试操作，并提供执行日志．