多线程文件迁移（NFS to S3）

由于项目比较老，所以原先使用的是NFS，NFS的效率、性能还是有限的，当然最主要的是公司配备的NFS容量快不够了，这台服务器也没有多余的容量来拓展。所以公司买了亚马逊的对象存储S3，所以我得想一套迁移方案，此文档就是记录我想的一套迁移方案。

方案

迁移文件过程中系统仍然使用NFS，为了不影响系统使用，所以先把NFS上的文件复制到S3（不删除NFS上的数据），每天晚上八点跑（不影响线上使用，多线程从NFS拉取文件难免影响用户下载效率）。存量数据复制完成后，校验一遍，确保文件复制过去了。然后每天需要跑定时任务拉取增量文件。最后项目发版时，跑一边增量数据，发版完成后NFS的数据就可以完全不用了。

导出过程

• 每天20点自动执行程序，从NFS复制文件到S3

• 通过最后修改时间降序查询srm_sys_doc表中前10万条未迁移过的数据，确保第二天早上八点前完成全部任务

• 遍历查询出来的数据，启动线程，线程池大小16（IO密集型，线程池大小核心数*2）

• 线程内执行

  1. 从NFS拿到流文件

  2. 把流文件上传到S3

  3. 成功：保存srm_sys_doc_move表

     失败：保存srm_sys_doc_move表并保存日志

注意事项

• 生产中需要新增srm_sys_doc_move表（表结构详见附件）
• 每天查看srm_sys_doc_move表失败的文件，查看错误原因。（如有必要，可以手动操作复制文件）

附件

• move表DDL

  CREATE TABLE `srm_sys_doc_move` (
    `id` varchar(32) NOT NULL COMMENT '主键',
    `doc_id` varchar(32) DEFAULT NULL COMMENT 'srm_sys_doc ID',
    `move_flag` bit(1) DEFAULT NULL COMMENT '是否转移成功 1 成功 0失败',
    `log` text COMMENT '日志',
    `check_flag` bit(1) DEFAULT NULL COMMENT '校验标志',
    `check_log` varchar(255) DEFAULT NULL COMMENT '校验日志',
    `CREATED_TS` datetime DEFAULT NULL,
    PRIMARY KEY (`id`),
    KEY `bf26c6e7401c450ba0f0d4eeac28ed21` (`doc_id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8;