记一次系统优化经历 -php 系统

发布于: 2020 年 07 月 01 日
记一次系统优化经历-php系统

背景

需求背景是这样的:

商城有一批自营店,自营店在商城的商品库存数据和店铺自己的erp账户是打通的(erp是一个saas版的系统,供多家使用)。

虽然自营店铺在平台上是一个一个独立的店铺,各自的erp账户也是独立的,但是实际上他们的库存商品都属于公司,业务上也有一个共同的boss。

基于此,自营店的负责人希望平台能提供一个智能分单功能,根据公司仓库实际的库存情况,将自营店的订单按仓库能处理的数量拆分成多个订单,不再考虑仓库实际属于哪家自营店,只要是公司的仓就统一共管。

产品基于此,提出了一套产品规则。

一个仓库下有多个spu商品,一个spu商品会对应多个商城的sku。

商城订单在拆单时,提交一个或者多个sku,这些sku根据所属spu匹配库存。

仓库的排列顺序,要求按实际到收货地址的地图行车距离由近到远排序,两个仓库之间距离如果小于一定的阈值则认定为同一组仓。

在仓库分组后,按照由近到远的方式一个组一个组的匹配库存,进行拆单。

一个组内的仓库,优先匹配能出货最多的仓。

技术背景

因为一些历史原因和工期的限制。

考虑开发一个独立的服务负责拆单,在创建订单的时候,执行拆单逻辑。

基于此,对拆单动作的时效性要求就非常高。

整个拆单流程中有两个耗时比较严重的地方。

第一、获取仓库、库存、和换算商品spu。

因为仓库数据、库存数据包括spu关系都在erp系统中不断流转变化,拆单服务没办法独立缓存这部分数据。

每次请求进来,都要查询一次db。这部分的查询基本上耗时200ms多点,其中仓库耗时100ms左右,库存耗时100ms左右,spu查询耗时根据商品的多少,不过一般都不超过20ms。

第二、因为仓库需要排序和分组。就涉及到计算仓库到收货地址,以及仓库之间的距离。

这里的距离并不是坐标点之间的直线距离,而是根据地图接口返回的实际行车距离。这就要求每次计算距离都要请求一次地图接口。

每次地图接口请求基本耗时在10ms左右。

难题

实际生产中,仓库的数据大概在100个左右。

根据业务的场景,如果按照常规的phpfpm的阻塞模型运行,耗时大概是这样的。

注意图中,两次根据仓库数量循环。每循环一次大概需要10ms。这样算下来,仅仅是计算一个收货地址到每个仓的距离,就需要100*10 = 1000ms = 1s。

每个仓两两之间计算距离,大概需要4950 * 10ms = 49500ms = 49.5s。

这个耗时,同步接口是绝对不可能用的。

优化第一步:并行化查询

先考虑查询仓库、库存、和spu的问题。

因为这些数据基本只能查库获取,没法cache。

按照php-fpm的阻塞模型,这个时间基本没法改。不过还好,拆单系统采用了php的hyperf框架。hyperf基于swoole开发,能够给php提供协程特性。

我们利用这个协程特性,将查询仓库、查询库存、查询spu的工作并行化,这样这块的时间消耗基本等于其中最大的一个。

时间消耗变成:

参考:hyperf-parallel特性swoole-waitgroup特性

优化第二步:缓存

有了第一步,只是解决了问题的很小一部分,最大的麻烦还是在距离计算上。

不过好在,距离的计算是可以缓存,坐标点之间的行车距离一般是不会变的。

解决这个问题的时候,我们要求业务端在用户进入下单页面的时候,提前将用户的收货地址信息提交给拆单系统。拆单系统提前解析收货地址的坐标,以及该坐标到每个仓库之间的距离并缓存到redis中。

另外,做一个定时任务,每一小时起来计算所有现有仓库坐标之间距离信息,也缓存起来。

因为缓存的key是由实际的坐标经纬度组合出来的,所以不用考虑仓库坐标数据的更新,当然实际上仓库更新地理坐标的情况基本没有。

通过上述操作,将每次距离计算从10ms,压缩到了1ms左右,这1ms是一次redis的get请求时间。

优化第三步:内存缓存

有了第二步的处理,系统速度有了比较大的改观。但是按照每个仓两两之间计算距离,仓库与收货地址之间计算距离的要求,实际上要请求将近5000次redis(业务上每个仓基本都是全国配货)。

每次1ms,5000*1ms = 5000ms = 5s,也还是达不到可用标准。

这个时候,就考虑一下实际的业务场景。实际场景中,仓库数据虽然有100多,但是实际的物理仓库是达不到100个的,因为很多仓库都是公用仓,只是每家自营店在用的时候都会添加一条仓库数据。

那么就是有很多仓库坐标是相同的,我们可以想办法减少这部分数据的缓存io。

这里我们考虑在内存中缓存这部分数据。

因为hyperf框架是常驻内存运行,static变量是不会在请求结束后释放的。借助这个特性,我们将从redis取到的数据,存储一份到内存中,每次取距离数据的时候优先获取内存中的数据,其次再去获取redis中的数据。

这里因为仓库的距离数据并不是十分巨大,所以内存占用能接受。

通过这个手段,我们将redis的读取耗时大幅降低,实际运行中看到的结果基本可以减掉一半的redis io。

不过这个操作也导致我们的拆单服务,变成了有状态的服务,这在设计上是不友好的。

会有几个隐患,一方面如果仓库、收货地址数据暴增,内存的占用会十分可观,需要慎重;另外,内存缓存如何清理,清理频率怎么设计都需要慎重。

优化第四步:计算剪枝

上一个步骤虽然减少了io量,但是副作用比较多。

而且几千次的计算,php本身的耗时也比较客观,最好还是有其他办法能减少io。

通过业务分析,我们了解到,仓库基本都在各个城市分布,一个城市一般最多分布一到两个仓库。

之前计算仓库之间的距离主要是为了进行仓库分组。将距离比较近的仓(低于配置的距离阈值),合并到一个组,组内出货最多的仓优先匹配。

那么如果 仓库A到收货地址的距离 - 仓库B到收货地址的距离 > 距离阈值,是不可能分到一个组的。

如上图,按仓库与收货地址的距离排序,A、B、C、D四个仓的排列顺序是 D、B、A、C。

其中,D到收货地址的距离是10,C到收货地址的距离是20,分组的阈值是5。那么C和D是不可能分到一个组的,因为即使D、C和收货地址在一条直线上,C和D的距离也超过了5。

基于这个想法,我们在第一次将仓库按与收货地址的远近进行排序之后,按照仓库到收货地址的距离预先进行分组。

图例中,分组后的结果是[D] [BA] [C]。

之后,再循环每一个组,根据组内仓库两两之间的距离进行计算,超过阈值的再分成独立的组,从而减少了仓库之间距离的计算量。

实际情况中,因为仓库基本都分布在不同的城市之间,配置的距离阈值是20公里,所以这样的操作能将大部分仓库都预先分配到不同的组内,大大的减少了距离计算量。

后记

经过上述的几个操作,我们把原来需要几十秒才能做完的接口,控制在了300ms以内,基本达到了业务可接受的范围。

如果后续能针对仓库、库存等增加缓存,那么相信性能还能进一步提升。

这里有两个问题有待优化,一方面我们一次访问redis耗时在1-2ms,这个速度不怎么令人满意,后续还是要继续挖掘这块性能,看到这里的朋友如果有什么想法也可以留言告诉我。

我们使用的redis是阿里云的集群版,redis操作基本就是简单的get操作。

还有一个就是php创建对象,100个仓库对象创建,耗时接近80ms。之前没细究这个时间,看到耗时之后很惊讶,这个创建速度确实让人头大,这怎么敢大规模的采用面向对象的写法呢。不知道其他语言是个什么状态,知道的小伙伴也可以留言告诉我。

用户头像

而立

关注

还未添加个人签名 2018.01.25 加入

还未添加个人简介

评论

发布
暂无评论
记一次系统优化经历-php系统