亿级中转场：30倍内存优化算法设计与实现

    一句简介：内存最大可存100万，有一天能存300万，再有一天储900万，再一天可存1800万，直到3000万！

    需求背景

     随着公司的快递业务日益增长，特别是节假日或购物节，如五一、618、双十一的快递单量瞬间暴增，中转场需缓存大量数据等待分拣，在去年双十一高峰期，有些场地的进港和出港数据仅保留2到3天的数据，但分别都已经高达到2000至4000万之间，而场地有些服务器高达38G的内存都无法支撑起数千万数据内存的消耗，导致后台服务直接开档空挂，巴枪使用瘫痪！

     记忆去年双十一只要当天当收件量超过1800万以上，基本都会出现内存溢出的情况，运维只能重启后台应用，重启后巴枪需等待30~40分钟缓存数据加载，无奈却在胜仗关键时刻出叉子，不但影响分拣效率，且在工作压力较大情况下，场地人员也出现较大情绪！

    业务痛点（传统解决方式）

1、顺丰接近拥有300个中转场，若需每台服务器拆解更换内存条，费时费力；

2、因服务器内存插槽有限，没空闲插槽时，只能以舍弃现有4G换成8G方式进行，造成资源浪费； 

3、如果有些中转场服务器较早期，内存扩展支持已到极限，需要更换服务器，造成成本费用则更高；  

4、假设所有服务器均有无限内存插槽和扩展支持，但在千万数据量起步，吞吃内存胃口会增加几倍，甚至更多，不久后又要扩展；  

    算法概述

1、对象类型的数据转换字节类型的数据；

2、千万级别的List集合缩小为万级别的List集合；

3、需要缓存的数据进行批量且快速压缩处理；

4、更新缓存数据时，对压缩数据断点判断与拼接；

5、请求缓存数据时，对数据定点标识与二叉树快速查找； 

流程图如【图1-1】所示：

                                              

    模拟演视

1、2倍以上加载效率（数据量越大越明显）：jdk1.6，最大内存256，90万数据；

A、旧算法时间截图

B、新算法时间截图

 2、30倍内存优化（数据量越大越明显）：jdk1.6，最大内存256；

 A、旧算法内存截图，101万时已经溢出

B、新算法内存截图，3000万正常  

 

    算法难点

1、数据段算法对残缺数据、特殊数据、超长数据、一表多个中转场等容易丢数据情况的拼接； 

2、针对数据量较大时，对各种类型（long型、char型、String型等）转换字节算法的性能要求较高；

 

---

创新点

1、 以习惯扩展硬件内存方式对比，省时省力省钱，只要伴随正常版本的发布，即可达到降低内存的使用。 

2、在数据量较大时，不但内存节省，还提高的加载和提取的效率， 能使巴枪终端反应灵敏，同时负载更多巴枪；

3、在后续缓存结构程序，都可以使用本内存优化算法，有效达到无边界效益反应，叠加节省更多的人力物力；

---

带来的影响

1、主要对进港、出港等几个数据量大的缓存进行算法优化就能达到2~6倍的内存使用效果，10.5版本已在进港验证功能使用正常（现10.8版本）；

 

2、无论是互联网发展或公司业务扩展，又或者搭载新应用，如人工智能程序等，中转场内存必须是扩展的过程，假设一个16G的中转场原本要花费600元（按中关村三星8G内存400元~800元取平均值）扩展8G内存，但使用优化算法后，能空出了8G以上的内存，即是双倍节省，作280个中转场计算（中转场还在增加），双倍费用节省33.5万元左右，当然以后的叠加效果可以会更多；

 

3、部分中转场的服务器已经出现无法支持扩展更大的内存，面对内存不足时，只能更换服务器，这会是更大一笔费用，优化内存后实现资源再利用！

 

转载于:https://www.cnblogs.com/deepis/p/9298508.html