物流系统原有40T数据加上每天至少要比之前多3G数据产品，这种该怎么解决

        今天早上接到一个学生的电话，说他现在有40T物流数据，且今年比去年每天至少要多3G数据，访问量也要比去年每天多1千万次。在少量增加成本或是在原有的服务器的前提下，将系统进行升级及拓展。希望我给他提供方案。

        听完之后，首先我问题物流业务的安排(主要是查询服务、数据更新、接口对接)。其次再问到40T数据全是物流数据呢还是物流数据+日志数据。最后问到岗位安排及服务器数量。

        学生回复我说，目前物流系统最大的困难就是数据更新及自家运营统计分析。因为数据过于庞大，加上现在每日新增数，数据库的写入能力大大降低，已经排队到3分钟左右才能更新一条(物流数据)，而日志数据基本要10分钟左右才能写入一条。40T数据中有12T多是物流数据，有28T多是日志数据。整个开发有40多人。有运维工程师15个，6个高级工程开发C及C++的，有8个go普通开发，还有一个DBA日常维护。业务开发6个前端(4个高级前端，2个普通前端)，10个PHP开发(6个高级PHP开发，4个普通开发)。还有5个PHP与go混合开发的，能力也在高级工程师中。2个kafka开发工程师，2个rabbitmq开发工程师，3个swoole专业开发工程师。剩下就是一个部门经理与技术总监(自己)。因机房是托管的，他们已经有了40台物理服务器。留了20台服务器在做备份，其中有10台也在做测试服务器,10台是长期做备份服务的。

        听完之后，首先我问到物流业务这块，更新数据，每个订单号最长流水线是多少，而每日查看统计及分析的数据流水线是多少。每块硬盘最小多大，服务器的最小核数及CPU是多少。

        学生回复我说，每个订单号最长的流水线不超过30天，基本上都是7天内。而每日统计及分析的数据流水线是2内年。被正常调用查询的订单大多数都是3个月内的，只有少数是6个月以内的。与第三方核对订单基本上是半年一次。除了数据库服务器外，有2台服务器是8核32G的，专门做对外服务器，8台16核32G专门做内部处理服务器，还有一台6核32G专门做长链接的，swoole服务。而kafka、rabbitmq、Redis及MySQL9台服务器，都采用的是24核96G的，硬盘统一用的是10T一块。除了kafka、rabbitmq、Redis及MySQL这9台服务器采用了6块盘，而其他的都采用了2块盘。目前最大的问题是CPU及内存基本都是使用率40%左右，除了swoole、rabbitmq、kafka这几台达到80%左右，而硬盘的读写速度只有40%。

        听完之后，我沉默了5分钟。最后给了他一个解决思路：数据分仓已经是必然的，其次就是分业务库。首先说业务分库，比如说运营需要的统计、分析库，他的规律是2年以内的数据，那么他对应的数据只要存2.5年，超过2.5年的数据就自动删除掉(最好是存3年的)，特殊情况，到总库查询。而第三方需要用到的数据也单独存储一套库，只要存储一年就行，超过的也是自动删除掉。而用户查询的话，到总库里面去查找。而运维库不要与业务库放到同一台服务器里面。运维日志最多存3年，超过的自动删除掉，但是异常IP要单独保留。再说数据分仓问题，不管是哪种业务库，都必须分层。访问率较低或者是业务重要性低的数据，可以使用机械硬盘，可以单独使用一套库，命名为冷数据层；访问率一般或是业务重要性一般的，可以使用固态硬盘或是机械硬盘，也是单独一套库，命名为温数据层；访问率高或是业务重要性高的数据，一定要使用固态硬盘或是内存库来解决，命名为热数据层。最后说一下备份服务器，留太多了。拿出4台加入rabbitmq队列，拿出2台加入到kafka队列，拿出4台做日志数据库。因IDC机房有自动发电机能力，就只要做好硬盘检测及硬盘备份就行。