文件上传或消息推送方案探讨

场景

一大批文件或者一批消息要推送到另外一个系统。以下以文件为例，一批文件需要上传到文件服务器，目前已经有文件表T_FILE里面存储了文件路径等信息。

实现

方案一

文件表T_FILE新增一字段UPLOADSTATUS标识文件是否已经成功上传。每天0点定时任务，上传前一天新收到的文件和之前上传失败的文件到文件服务器中。对上传失败的文件，进行重试操作，每次重试间隔加一个周期(如30min)。

优点：不需要额外的表支持
缺点：任务一次执行，失败后的重试操作需要的参数都在内存中维护，服务重启后，需要间隔多个周期执行的任务，全部恢复为一个周期后执行；同一个文件可能会被多次上传(如果当天内始终未完成某些文件的上传，第二天的任务会再次扫描到上传失败的文件，重新执行上传，而前一天的任务也在执行这些文件的上传)。

方案二

文件表T_FILE新增一字段UPLOADRECORDCREATED（0-未创建 1-已创建）标识文件是否已经在T_FILE_UPLOAD表中创建上传记录。
新增一个表T_FILE_UPLOAD来标识文件的上传状态等信息，

方案图示：

启动两个任务，
文件上传任务初始化任务 定时启动，每天0点执行一次即可，扫描未在T_FILE_UPLOAD创建上传记录的数据，插入到T_FILE_UPLOAD表中，初始上传状态为未上传，重试上传的次数为0，下次重试上传的时间为创建时间即可。任务如果运行失败，要进行报警通知。

文件上传执行任务，每隔一段时间(如，30分钟)启动一次，扫描文件状态为0的，且下次重试上传的时间小于当前时间的任务，进行文件上传。成功上传的文件更新上传状态为成功，失败的更新重试上传的次数+1，当前下次重试上传的时间+重试周期（30分钟）*重试上传的次数即可。重试超过10次后，要进行报警通知。

优点：逻辑清晰，实现简单，与之前业务耦合性低。
缺点：同一个文件可能被重复上传(本周期上传一个文件没有上传完毕，下一周期又被执行上传了)。

方案三

方案二基础上，丰富文件的上传状态这一字段，更改为0-init 1-上传中 2-上传成功 3-上传失败（也可考虑把上传失败的放到另外一个单独的表里面，这样职责更清晰，也更容易处理）。任务每次运行时，对于状态为0、3的任务尝试重新上传，状态更新为1；对于状态为1的任务，需要先向接收方查询状态，如果明确查询到状态为失败，则重新尝试上传，否则下次继续查询，只有明确查询到状态为失败时，才能重试（如转账消息的场景，不能轻易重试，只有明确状态为失败时，才能重试）。

结论

如果同一文件多次上传时，文件服务器可以根据文件标识等信息识别是否为同一文件，兼容新增或覆盖场景，那么上传方案无需太关注同一文件的多次上传问题。采用方案二即可。

如果文件服务器或者消息接收方要求不能重复推送文件或推送消息，或者业务不能重复推送消息，则采用方案三。

其他需要考虑的问题

• 任务的分布式调度
• 推送失败报警（任务生成失败报警，重试次数超阈值报警）
• 安全机制，申请接入通知文件上传模块（或通知模块）