批量任务后台执行功能实现细节。

将客户端开启、关闭、修改认证功能后台执行。

一、后台执行过程中出现错误或者遇到系统重启时自动修复。

二、自动修复未启动前,提供提前修复按钮。

三、每个客户端在线程执行过程中提供提前操作处理。

四、前端展示进度。

五、自定义账户展示、恢复默认账户功能。

限制:

1、线程运行过程中或者出现运行错误时不能运行其他线程。(考虑优化为出现错误时,可以运行其他线程。)

2、线程运行过程中不能删除客户端。

3、线程运行过程中还没处理的客户端不能单独操作认证。

 

实现:

需求一实现方案:

原定方案:

线程开启、关闭、修改时,在mon db中写入任务执行状态(operation_type: 0-开启,1-关闭, 2-修改, status: running-运行中, end:执行遇到错误或者系统重启。 end-running-后台修复线程执行中)、认证信息以及所有的客户端信息、进度信息,每处理一个客户端则删除一个客户端,并更新进度。

问题:

每次处理一个客户将端的操作在客户端少的时候不会对性能有影响,但是当客户端达到1000左右时,写入mon db的操作将是一个比较耗时的操作。

优化方案:

1、线程开始后客户端信息、进度信息不存入mon db,针对执行过程中客户端是否已经被开启和关闭是可以通过客户端当前认证状态获取的,针对修改的情况,每次线程处理或者提前处理以后,将已经处理的客户端存储到内存中来达到判断客户端是否已经被修改。

2、进度信息存储在内存中,如果后台任务运行过程中遇到错误或者重启,修复线程运行时进度重新计算,注意,修复线程运行时的进度为总客户端数减去之前已经被提前处理的客户端数。

优化方案优势为能保证系统正常使用时不会出现操作mon db耗时的性能问题,劣势为当后台修复线程运行中出现重启时,会将已经修改过的客户端再次重复修改(因为重启以后内存在记录已经修改的客户端数据已经不存在)。

 

需求二实现方案:

需求背景:

当后台线程出现错误时,后台会有一个5分钟的定时线程尝试自动修复,在修复线程没有自动运行时,用户客户通过前端页面提前修复。

方案:

后端提供修复接口,接口收到请求后则再次启动一个修复线程,这个修复线程运行结束则停止,不再定时执行。修复线程前需要判断当前是否有正常线程以及修复线程已经在运行,如果已经在运行则不启动线程。

修复线程起来时,需要将之前记录的客户端进度信息清空,并将新的进度修改为总客户端数减去提前修改的客户端数,将提前处理的客户端标记为已经处理进度,如果是修改操作将提前处理的客户端标记为已经修改,如果检查到之前已经被操作的客户端,则重新更新进度,如果是提前操作的客户端,修复线程运行到这个客户端时,则不更新进度。

 

需求三实现方案:

需求背景:

线程运行过程中,用户想要提前修改后面的客户端则可以执行提前操作。

方案:

操作每个客户端都需加锁,通过装饰器实现,共享变量的修改需要在操作客户端的方法内实现。

考虑到进度问题,需要将线程处理过或者提前处理的客户端标记为已经已经处理进度,每次操作客户端时,如果是检查到已经操作,则判断是否已经修改进度,如果没有更新进度,则需要更新进度。(处理依据:当客户端被提前处理时,线程运行到这个客户端以后不需要更新客户端,因为提前操作时已经更新,如果是线程出现失败,则进度重新开启,针对已经处理了进度的客户端,需要判断是否是之前的线程处理的还是此次修复线程运行过程中提前处理的客户端,如果是之前线程处理的客户端,则需要更新进度)

考虑到修复线程进度问题,需要将提前处理的客户端记录到mon db,修复线程启动时的进度为总客户端数减去提前处理客户端数。

 

需求四实现方案:

方案:

内存中存储客户端进度数据,如果遇到线程错误或者重启则重新计算。

 

需求四实现方案:

方案:

如果修改客户端单向认证不是线程处理或者提前处理的,则将其标记为自定义认证客户端,记录到mon db,只有当删除客户端、关闭客户端chap、恢复默认认证时将客户端记录清空。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章