前言
由于业务的增长，传统的基于磁盘的文件存储需要迁移到阿里云OSS对象存储中。我们的业务主要是涉及GPS轨迹小文件，大致有1TB，文件数量5千万。在使用阿里云ossimport工具的过程中有些基本概念不明确，导致了一些操作失误，特写下本文记录实战过程中的一些问题。
环境
- Ubuntu（阿里云ECS）
- 数据盘1TB，5千万个文件，数据层级最大6层
- 业务持续读写数据盘
- ossimport使用local模式，单机部署通过内网传输，使用方法请参考官方文档
问题汇总
ossimport具体怎么用？
首先肯定是下载ossimport到主机中，然后unzip解压，然后修改conf中的配置文件。我们实战过程中仅修改了以下配置，请酌情参考：
- srcPrefix：要上传的文件夹全路径
- destAccessKey：OSS密钥
- destSecretKey：OSS密钥
- destDomain：OSS上传域名，可在控制台中查看，如果内网能通建议使用内网（免流量费）
- destBucket：目的bucket，只填名称，不是路径
- destPrefix：OSS中的路径，不要以“/”开头，不然会报错
- taskObjectCountLimit：子任务最大的文件个数，见下文
- workerTaskThreadNum：在sys.properties中，见下文
需要明白srcPrefix和destPrefix的关系，比如本地路径：/data/files/gps/1.gps，如果srcPrefix配置为：/data/files/，destPrefix配置为：files/，那么OSS中文件访问路径则为：files/gps/1.gps。
配置完成后直接使用./import.sh即可开始上传，如果之前上传过则会提示是否放弃之前的日志文件，输入y即可。
线程数怎么配置？
在conf/sys.properties里面可以通过workerTaskThreadNum配置线程数。线程数建议根据机器硬件资源酌情配置，可以使用默认配置尝试运行查看具体的CPU和内存消耗。我们8核32G的机器配置的是100个线程，实际CPU消耗45%左右，内存上升不明显。在我看来应该是和文件大小和数量有关系，所以可以先在某一个文件夹测试后再做决定。
子任务最大的文件个数怎么配置？
在conf/local_job.cfg里面可以通过taskObjectCountLimit配置子任务最大的文件个数。此参数十分重要，决定了上传的速度。建议设置为1000-10000之间，由文件数量决定。比如共10万个文件，线程数为100，此参数设置为1000时则会跑满100个线程，即速度最快；如果设置为10000，则只会使用10个线程，相比之下速度差距是很大的。当然并不是越小越好，线程切换和初始化都是需要时间的，我们文件数量太大，实际使用的值是10000。当然我的理解不一定准确，是在本次迁移时得出的经验总结，欢迎指正。
迁移过程中怎么查看进度？
在执行./import.sh后会打印开始上传，上传任务是在后台进行的，可以直接使用ctrl+c退出，不影响后台上传任务。如果不退出，程序会每30s打印一次job状态，输出内容如下：
---------------- job stat ------------------
JobName:local_test
JobState:Running
PendingTasks:0
DispatchedTasks:160
RunningTasks:100
SucceedTasks:300
FailedTasks:0
ScanFinished:true
TotalFileCount:4594039
TotalFileSize:165240197722
FailedFileCount:0
RunningTasks Progress:
26D7FFA590E79C6DB605C7620A137AF7_1689756034461:358418080/358418080 10000/10000
FE87826B81BD5C4FAAAB1D46C6C784A7_1689755926530:423527527/423527527 10000/10000
C1C8E718F992115F570C9DD93F8EBC98_1689756070177:364428333/364428333 10000/10000
BD5789F28B1579AC72F5E36D14E8503E_1689756175042:374358890/374358890 10000/10000
...省略若干...其中需要关注的内容如下：
- DispatchedTasks：已分配的任务数量，会根据已扫描的文件数量、线程数、子任务文件数进行自动创建任务
- RunningTasks：正在运行中的任务，包含上传和检查
- SucceedTasks：成功的任务数，结合已分配的数量可以大致知晓目前进度
- FailedTasks：失败的任务
- ScanFinished：是否扫描完成所有文件
- TotalFileCount：已扫描的文件数量
- TotalFileSize：已扫描的文件大小（B）
- FailedFileCount：失败的文件数量
任务全都显示1000/1000，但是不进行下一个任务？
先说结论：耐心等待即可，不要做任何操作。我最开始也是看到任务一直卡住，明明显示任务中的文件都上传完成了，但是迟迟不开始下一任务进程，但是还结束整个进程重试了很多次，每次都会遇到这种情况。后面在log中查看import.log发现在上传完成后还会有一个check的过程，check过程中未输出任何日志，所以看起来是卡死了，其实程序在对已上传的文件进行校验，所以只需等待即可。
上传过程中的计费项有哪些？
- 流量费用：上传到OSS端免流量费，但是从云服务器出网需要流量，如果云服务器和OSS在同一VPC下可以通过内网直接上传，此时流量全免费
- PUT请求费用：上传一个文件计一次PUT请求，阿里云收费0.01/万次
- GET请求费用：验证文件是否存在和统计OSS文件数量时会收费，阿里云收费0.01/万次，ossimport可能还会由一些其它的必要请求，不过整体成本还算可控
一点小建议，不要中断ossimport任务，让ossimport一次性上传完成可以节省很多GET费用，我们一开始中断了多次，导致了很多无效的GET请求，不过还好收费不算高。
上传过程中的注意事项？
- 在扫描的过程中如果已被程序记录的文件被业务系统删除了会导致该文件失败，当然还有其它的情况，我们只遇到了这一种。如果有失败的文件，上传后会询问是否重传失败的文件，可以根据error.log中的错误类型决定是否重传
- 上传过程中如果业务系统有写操作，则不能保证新增的数据被上传，需要自行适配增量数据的重传逻辑。我们是记录一个上传开始的时间，只要在该时间之后写过的文件都重新覆盖上传一遍
上传成功后业务怎么迁移到OSS中？
每个业务系统落地方案都不禁相同，我这里大致描述一下我们的迁移步骤。
- 迁移本地文件到OSS，此时有业务产生的增量数据在本地未上传
- 修改业务代码适配OSS相关文件操作
- 重启业务服务，所有访问重定向到OSS，所有新增数据业务直接上传OSS，此时上传阶段的增量数据无法访问，业务会受影响
- 上传迁移期间的增量数据到OSS，业务恢复，迁移完成
上述流程最大的问题是迁移时的增量数据会有一段时间访问不到，如果增量数据过多则会导致业务影响范围扩大，所以应当在业务低峰进行服务重启。当然也有无缝解决方案，阿里云OSS提供了回源配置，在OSS中找不到文件时会到源站下载转发，具体可以查看官方文档。我们业务低峰可保证增量数据在10分钟内上传完毕，且业务端对于增量数据的请求并不多，所以未进行回源的实践。
如果看完有收获可以来个三连，谢谢！
)
