（JAVA）批次转联机接口设计

导读：

• 以下是最初版的设计稿，目前系统稳定运行，也取得所有业务人员的认可，该系统主要处理excel文件上传文件后，通过接口处理超时，执行状态不可知、宕机风险等等问题进行处理，使系统更加稳定的运行。让批次系统处理所有批次的问题，业务系统关注业务问题，两者可达到完全解耦。系统层面支持横向扩展，通过线程池、限流等技术手段控制并发频次，只要下游系统并发量支持，理论上文件处理并发速度无上限扩展。excel数据转存是个复杂的操作，有条件的最好使用ftp、sftp来异步通知，通过缓冲流下载是最优解。正考虑封装成开源出来，让大家使用。

背景

现状：目前文件一般通过异步处理：会造成文件异常不可知，处理进度不可知，处理结果不可知，造成数据遗漏处理，可能这些问题，对于目前我们的影响危害是比较小的，随着业务体量的增长，业务数据对于我们越来越重要，那么，做好数据监控，成为关键的一环。
期望： 建立批量转联机应用， 存储批量数据的内容、处理进度、处理结果以及可控批次暂停中断限流等等操作。

模块

1. 数据入库（文件上传）：基于POI文件入库，基于FTP、SFTP文件入库。
2. 数据处理：批量执行不同业务类型的数据，可控制并发控制限流，并针对批次进行中断、重试、手动执行、归档、一键归档（自动归档+手动归档）等操作。
3. 数据清理：约定每月进行对处理成功或已归档数据进行清理。
4. 数据导出：数据库按分页读取数据导缓冲流通过阿里OSS上载云端，用户从云端下载数据。

设计

数据入库（文件上传） ：

• 在Excel导入开发中，我们时常考虑使用异步或者同步去处理数据，当使用同步线程处理问题时，我们不确定文件的大小，时长会因为文件比较大，业务处理耗时长，导致批次中断，若有事务的情况下，该批次可能全部执行失败；当选择以异步的方式，用户往往希望获取批次获取结果及处理进度，怀揣着一种忐忑的心态处理批次。从系统安全出发、对数据处理的准确性，所以，数据必须入库，且数据入库前必须校验数据的准确性，后采用同步的方式添加进数据库，而数据处理是异步的。
  
  batch-service会给每条数据定义实例id，主要指定不同实例执行不同任务，避免数据重复处理。
  Excel文本入库

• 使用：通过现有的POI框架，支持@Excel字段映射导入数据库，导入后将所有字段进行拼接，拼接示例：用户，姓名，年龄，拼接方式： 用户\u0007姓名\u0007年龄。

• 优点：使用方便快捷，通过POI注解直接映射字段，进而导入数据库。

• 缺点：和系统内存直接挂钩，存在内存溢出风险，不利于大文件传输，POI存在6w+条数据限制，超过6w+直接导出失败（目前POI版本低，高版本可使用stream流写入）

  其他文本入库

• 使用：约定文本结构，以特殊分隔符间隔不同字段存储，存储示例：用户，姓名，年龄，存储方式： 用户\u0007姓名\u0007年龄，一般数据处理分为两部分，数据上传、文件处理，阿里OSS有监听文件变更的通知，当某个文件变更后，我们系统会收到消息，进而对数据进行下载保存至数据库。

• 优点：以缓冲流下载上传文件， 对系统负荷小等。

• 缺点：需对接OSS文件变更通知接口，当字段分隔符合文本内容存在一致时，数据处理存在冲突，需约定特殊分隔符。

数据处理

• 数据清理（归档）定时默认每天，将t_batch_import_head表设置为归档状态，清除t_batch_import_detail表数据。
• 数据导出
  (1)数据库每次读取500条数据–》写入缓冲流–》OSS（需处理深分页问题）。
  (2)用户通过导出页面进行下载。
  (3)通知用户下载。

实例心跳设计

目前mysql版本较低，无法使用锁机制让每个实例获取不同的数据，故采用路由的概念，将数据和实例进行绑定，每个实例只能处理当前实例下的数据，实例每五分钟上报一次心跳状态，若实例超过6次未上报心跳信息，则认为实例下线，则会剔除当前实例列表。当实例发生扩容缩容时，支持新入数据动态分配，存量数据则保持原有实例运行。
(1)实例每五分钟上报一次心跳信息。
(2)若实例下线超30min则认为该实例下线，则将未处理数据进行迁移至在线状态的实例。
(3)提供准实时实例列表。

前端页面原型设计：

处理流程（期望）

成品展示