年后到现在好像一直在做这一个需求，感觉自己好像写过一点相关的内容……没写的话当我是在做梦。感觉已经变成无情的数据搬运工了，每天就是在写数据脚本，建表格拉数据……还是得偷学点能当饭吃的技术，感觉现在干的活找个人来干几个月也就会了。🤔

拉取退款数据

简单来说就是，通过接口请求数据，再把数据结构整理好，存到对应的表结构里，我每天干的事情无非是这些。需要掌握一些像是字符串处理，字符串和数组互转，还有就是特殊格式的数据处理函数，像是json和XML类型的数据。财务数据这里遇到的难点主要是，首先数据类型很多，整理起来很困难，尤其是完整的数据结构，手动拉了很多数据才基本整理出来，最后主要用到的部分存到了数据库，剩下的部分直接存到了MongoDB里面；其次是数据搞清楚是按照区域还是站点拉取，是我做的少，花了不少时间去解决按照站点拉取结果产生的大量重复数据，还有站点确定的问题要解决，所幸还有一个网址可以用来确定站点；最后是，数据没有能确定的唯一键，最后只能采用直接插入的办法来解决这个问题，要考虑的点，像是每次拉取的时间怎么确定，怎么解决上一次拉取结束时数据的完整性问题等等。不过这些问题解决起来的具体实现其实难度还可以。

之后又做了把所有的财务数据存储到MongoDB的工作，这期间也是学习了相关环境的配置，MongoDB的使用是要比关系型数据库简单的，不用确定固定的数据表结构，每个文档就像组装数组一样组装好然后扔到一张表里就搞定任务了，上面说退款数据确定数据结构花了很长时间，这全部财务数据因为暂时用不上，就直接扔到了MongoDB里。

期间，出现了一个问题，当请求传递的速度太快时，服务器会返回429错误，需要降下来请求的频率，目前的解决办法也只有用sleep()和usleep()两个函数进行代码的延迟执行，来尽可能避免这种情况的出现。再就是尽量把请求时间片缩小一些，让请求下来完整时间片的数据的可能提高，尽量减少下次插入数据时对数据的删除量，不然删除一个大时间片中的不完整数据浪费的时间和硬件资源还是挺多的。

拉取退货数据

其实这个逻辑倒是比上面那个简单，唯一的问题是退货数据的接口，稳定性相当差，只要请求的时间长一些，请求的频率高一点，接口基本就会爆炸，没数据，导致每次调试代码，都是一种折磨，巧妇难为无米之炊了属于是。退货数据的唯一键存在，所以可以更新数据，感觉逻辑倒是很简单，但是，FBA数据也是按照区域来拉取的，而且确定站点的数据不像退款数据还有个网址可以利用，最后的解法是根据订单号去订单表里查找对应记录的站点……当然一开始按站点拉的，最后改成按区域拉，那时心态相当炸裂。

数据分表

我一开始以为数据库分表可以用数据库的机制来做，像是一张表数据大的负担很重，就可以像winrar给压缩包分卷那样给表也做数据切分，然后分表之间自动就有联系……但是结果分表只能用程序自己做，一开始挺麻的，主要没做过，就只知道按时间分表，然后是退款和退货的入库逻辑还不一样，导致得写两套逻辑，而且表的更新、插入也要考虑到问题很多。写到最后，感觉死循环条件跳出这种东西最好少写，因为我好几次都是没考虑到额外的跳出条件，结果还得费老大劲去处理相关的错误数据……

反正这块不简单，以后做都得注意一点，时间是一个比较重要的区分指标。

部署

这块内容主要是脚本部署，要配置一些环境，像是线上环境建表的SQL审核，定时脚本用cron解决，还有守护进程的使用之类的。线上跑的定时自动启动脚本用的就是守护进程。一些工具类脚本用的是cron，第一次接触倒是很新鲜。

总结

感觉很难的东西写成文字竟然只有这么一点……还是得继续积累。