物流系统原有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机房有自动发电机能力,就只要做好硬盘检测及硬盘备份就行。

上一篇:GC9118S替代TMI8118的优势分析,可应用在牙刷,电子锁,医疗设备等产品中


下一篇:卡尔曼滤波推导过程|MATLAB滤波|MATLAB卡尔曼|MATLAB卡尔曼导航