分片的状态什么时侯修改

Question

 

@亮哥 我描述一下我的业务场景及问题

起始我们用的还是ej 的 2.0版本

业务是这样的，我们会通过数据库的origin(始发) dest(到达)hash %shardnum

那么我们会通过shardingindex 来获取当前分片的数据，因为分片可以打到具体的线程上，所以这样可以通过线程隔离的方式并发处理，但在2.0 的场景下，分片会动态变化，而且分片可能存在bug ,可能同时存在多于shardingnum 的线程同时跑，这样会导致数据在同一个时刻被多个线程同时处理。

我们升级最新版本后，好象解决了这个问题，但从后台的分片的监控效果看，分片还是待处理状态，而实际上处理中

所以我想确认一下，这个版本的重分片是在什么时机下产生？

业务代码是不是要考虑数据重复被处理的情况？

如果业务动态扩缩容的情况下，会带来哪些问题？或者说应该注意哪些问题？

谢谢

 

Answer 1

问题比较多，我分别回答下。

1. 但在2.0 的场景下，分片会动态变化，而且分片可能存在bug ,可能同时存在多于shardingnum 的线程同时跑，这样会导致数据在同一个时刻被多个线程同时处理。

这个问题，应该是在没有开启monitorExecution的情况下，服务器产生波动造成的。正常执行会保证每个分片不会在同一时间被分配到两个实例执行，但服务器波动时，会产生这种可能。因此开启monitorExecution可以避免这种情况，但如果作业多且间隔时间短的情况下，开启monitorExecution会极大的影响zk性能。因此需要权衡使用。一个更加适合的准则是由业务方实现幂等性，在分布式的场景下实现幂等性永远是最安全的。

2. 升级和不升级，这里应该都未做修改。但是不开启monitorExecution，所有任务的执行状况是不记录的，因此状态统计那里应该显示的是“-”，即减号。也就是说，无论任务是否运行，不开启monitorExecution，elastic-job不会记录任务的状态，只会记录作业的状态。（作业和任务的区别是：作业是整体概念，每一个分片叫任务）

3. 关于重分片，是在需要的情况下，作业的cron触发时进行。所谓的需要的情况是指：服务器节点上下线、作业节点暂停，修改分片总数等。正常情况下不会重分片。重分片也不会在作业运行中进行，一定是作业下次触发运行时再重分片。

4. 业务代码是不是要考虑数据重复被处理的情况？是的，最好是这样。之前第一点解释了，分布式的情况最好由业务代码实现幂等性比较安全。由于网络问题造成的延迟、丢包甚至脑裂等状况，分布式是不能100%保证一致性的。

5. 如果业务动态扩缩容的情况下，会带来哪些问题？或者说应该注意哪些问题？

动态扩缩容分两种情况。第一种是分片项不改变的情况下上线和下线服务器。这种情况无需任何改动，下次作业运行时，即触发重新分片，动态完成分布式下的分片分配。第二种情况是修改分片总数。理论上来说，修改分片总数对elasitc-job也没有影响，也会在下次执行时重新分配分片，但一般分片总数和业务逻辑是绑定的，比如你上面举得例子，是按照hash模分片总数，这样业务逻辑势必要进行修改，因此这种情况不能做到动态扩容，需要重新部署业务程序才可以。

Answer 2

在分布式环境下的问题，可以参考faq的第4个问题的建议进行调试：http://dangdangdotcom.github.io/elastic-job/elastic-job-lite/01-start/faq/

Answer 3

建议先运行example，把example理解之后在运行自己的业务。理解的偏差会造成对ejob使用的问题。

Answer 4

任务都是根据cron表达式运行的。等待运行的状态应该是在cron之间的时间段，作业运行完毕，等待下次cron到时调度的状态。