总结

1、将不同用户的job进行隔离，不能跨用户进行增删改查。
2、 解决创建job配置新建托管池配置正确，资源池创建成功，job运行结束，资源池未自动删除的bug，熟悉分发模块的流程。重启动态创建池的job时，重新用添加job时的创建池的参数去创建池，并更新job数据库中对应的poolIds字段，运行此job。
3、 添加job相关的缓存，提高获取Job的所有运行态信息时超时的性能问题。
4、多线程并发更新和删除job时，解决操作不一致的问题。
5、dag依赖的job不能同时启动，不能配置关键任务。
6、删除job时，删除cce所占用的资源。
7、重启batch进行服务恢复时，过滤掉queue类型job的状态恢复，使之只有pending或者running状态。
8、batch服务功能测试，找出上线前的问题。
在开发过程中遇到的问题，事后应该进行相关技能的充值。多学习他们代码中的优点。

1、 学习压力测试工具JMeter，测试多线程并发，模拟多用户请求，在测试过程中发现偶现问题。
2、 由于actor模型，一个actor可以接收很多消息，但是这个actor只能一次处理一条消息， task模块向job反馈taskGroup1的状态变更信息，以随时更新job的状态向actor发送消息时还没有被处理到，这个过程中，又有另一个taskGroup2执行失败并更新到数据库，导致轮到消息被处理时，job模块从数据库取出最新的taskGroup状态计算所有taskGroup的状态时拿到了新的TaskGroup2的状态信息，更新job的状态，等到下一个消息（taskGroup2状态改变将状态信息回调给job模块时候）被处理时，job模块从数据库取出最新的所有taskGroup状态计算所有taskGroup的状态时（此时数据库跟上一个消息被处理时候数据相同），又去更新Job状态，这样就会导致错误。为了修复actor异步调用时消息不会被立即处理导致taskGroup的状态信息不准确的情况，在taskGroup状态变更时就将当时数据库中所有taskGroup的状态的信息同时携带进入回调函数（放在消息队列中），这样actor中轮到此时的消息被处理时，job拿到的就是当时发消息时候的数据库中的所有taskGroup信息，然后进行计算。
3、 重启一个job的时候，pool可能处于任务不能被调度的状态(创建中、扩容中、缩容中)，batch服务内部周期性调用重启的的线程的终止次数是三，如果动态创建pool，可能此时pool的状态不能下发task，就会浪费这三次机会，为了解决这个问题，在pool不能下发task的时候，我重新在重启的线程上，结束此线程，重新起一个新的线程不断的去调度直到pool可用，又加了周期性的调度以防job重启后pool的状态改变不能下发任务，用来将次数重新置为0。
4、 创建一个job的时候，由于task的作业内任务亲和性在task被调度时候，将作业内任务亲和性设置改变了导致jobDescription改变，之后再调用getJobDescription接口的时候，不能拿到正确的jobDescription。原因是：getJobDescription()接口中将jobDescription加入缓存的时候，返回的是指针引用，导致再别人改变这个对象时候，引用所指向的对象是随着一起改变后的，也就是是同一个对象。通过深拷贝将其复制一份，每次使用的都是深拷贝后的对象，不会改变最初的对象，这样最初的对象不会影响别的方法的使用。
5、 由于某个TaskGroup变化的时候（会携带此时数据库中所有的taskGroup的状态信息用于job计算TaskGroupEvent），异步多线程调用JobStateChangeActorImpl中 changeJobStateByTaskGroup() 方法时候，此方法对不同的jobId加锁，当两个线程争抢一把锁的时候，会出现线程执行顺序与actor队列顺序不一致，导致状态变化有误。
6、 调用JobScheduleImpl的onSchedule()方法时候，字段futures用来存储线程的执行结果，在启动线程时，jobStateConcurrentHashMap中jobId对应的键值对可能还没有放进去。导致run()中用到jobStateConcurrentHashMap中jobId对应的值的时候，get不到取消了此线程。修改为不断去get此jobStateConcurrentHashMap中jobId对应的值，若还没有get到，就重试五次。

1、 增加一种affinity：{“strategy”: “daemonset”, “taskGroupNames”:[ “taskGroup1”, “taskGroup1”]}支持"daemonset"特性需求。
2、 批量删除50+job会返回500错误，出现超时的现象：优化deleteJobs()接口将操作数据库的操作减少，降低此接口运行时间。
3、 同一个类生产环境中的batch服务共享MemObject 类型的memObj变量（缓存batch服务中的数据），导致不同用户可以操作其他用户的job（此job相关的数据已经被加入缓存），用户隔离存在问题：给getJob（）接口添加限制，从缓存中取出来的job应该具有相同的租户名。
4、 由于某个TaskGroup变化的时候（会携带此时数据库中所有的taskGroup的状态信息用于job计算TaskGroupEvent），异步多线程调用JobStateChangeActorImpl中 changeJobStateByTaskGroup() 方法时候，此方法对不同的jobId加锁，当两个线程争抢一把锁的时候，会出现线程执行顺序与actor队列顺序不一致，导致状态变化有误。
5、 调用JobScheduleImpl的onSchedule()方法时候，字段futures用来存储线程的执行结果，在启动线程时，jobStateConcurrentHashMap中jobId对应的键值对可能还没有放进去。导致run()中用到jobStateConcurrentHashMap中jobId对应的值的时候，get不到取消了此线程。修改为不断去get此jobStateConcurrentHashMap中jobId对应的值，若还没有get到，就重试五次。
6、 完成转正答辩。