递归

从数据库中查询出所有数据，然后递归处理

$category = [[
    'id' => 1,
    'pid' => 0,
    'name' => '1级分类',
], [
    'id' => 2,
    'pid' => 1,
    'name' => '2级分类',
], [
    'id' => 3,
    'pid' => 2,
    'name' => '3级分类',
], [
    'id' => 4,
    'pid' => 3,
    'name' => '4级分类',
], [
    'id' => 5,
    'pid' => 4,
    'name' => '5级分类'
], [
    'id' => 6,
    'pid' => 6,
    'name' => '6级分类'
]];

//递归成树形
function recurSionToTree(array $array = [], $pid = 0)
{
    $result = [];

    foreach ($array as $key => $value) {

        if ($value['pid'] == $pid) {
            $children = recurSionToTree($array, $value['id']);

            if ($children) {
                $value['children'] = $children;
            }

            $result[] = $value;
        }
    }

    return $result;
}

引用

从数据库查询出所有数据，然后遍历

function refToTree($data)
{
    $items = array();

    foreach ($data as $v) {
        $items[$v['id']] = $v;
    }

    $tree = array();

    foreach ($items as $k => $item) {
        if (isset($items[$item['pid']])) {
            $items[$item['pid']]['children'][] = &$items[$k];
        } else {
            $tree[] = &$items[$k];
        }
    }

    return $tree;
}

冗余字段，空间换时间

参考连接：https://learnku.com/courses/ecommerce-advance/7.x/database-structure/9086

在开始之前，我们需要先整理好 categories 表的字段名称和类型：

这里我们需要解释一下 path 字段的意义，在无限级分类的实现中我们经常会遇到以下几个场景：

• 场景一：查询一个类目的所有祖先类目，需要递归地去逐级查询父类目，会产生较多的 SQL 查询，从而影响性能。
• 场景二：查询一个类目的所有后代类目，同样需要递归地逐级查询子类目，同样会产生很多 SQL 查询。
• 场景三：判断两个类目是否有祖孙关系，需要从层级低的类目逐级往上查，性能低下。

而 path 字段就是用于解决这些问题而存在的，path 字段会保存该类目所有祖先类目的 ID，并用字符 - 将这些 ID 分隔开，根类目的 path 字段为 -。比如如下类目：

[
    [
        "id" => 1,
        "name" => "手机配件",
        "parent_id" => null,
        "level" => 0,
        "path" => "-"
    ],
    [
        "id" => 2,
        "name" => "耳机",
        "parent_id" => 1,
        "level" => 1,
        "path" => "-1-"
    ],
    [
        "id" => 3,
        "name" => "蓝牙耳机",
        "parent_id" => 2,
        "level" => 2,
        "path" => "-1-2-"
    ],
    [
        "id" => 4,
        "name" => "移动电源",
        "parent_id" => 1,
        "level" => 1,
        "path" => "-1-"
    ],
];

对应的类目树如下：

手机配件(1)
 ├─ 耳机(2)
 │   └─ 蓝牙耳机(3)
 └─ 移动电源(4)

现在我们再来逐一分析刚刚的几个场景：

场景一，查询『蓝牙耳机』的所有祖先类目：取出 path 字段的值 -1-2-，以 - 为分隔符分割字符串并过滤掉空值，得到数组 [1, 2] ，然后使用 Category::whereIn('id', [1, 2])->orderBy('level')->get() 即可获得排好序的所有父类目。

场景二，查询『手机配件』的所有后代类目：取出自己的 path 值 -，然后追加上自己的 ID 字段得到 -1-，然后使用 Category::where('path', 'like', '-1-%')->get() 即可获得所有后代类目。

场景三，判断『移动电源』与『蓝牙耳机』是否有祖孙关系：取出两者中 level 值较大的类目『蓝牙耳机』的 path 值 -1-2- 并赋值给变量 $highLevelPath，取另外一个类目的 path 值并追加该类目的 ID 得 -1-4- 并赋值给变量 $lowLevelPath，然后只需要判断变量 $highLevelPath 是否以 $lowLevelPath 开头，如果是则有祖孙关系。

可以看到我们通过新增一个冗余的 path 字段，就能很好地解决性能问题，这是一种很典型的（存储）空间换（执行）时间策略。

预排序树

参考连接

https://www.jianshu.com/p/48f6db8ea524

https://www.cnblogs.com/sonicit/archive/2013/05/21/3090518.html

问题一

起因,公司的某项目APP客户反馈,ios打开数据响应很慢

2020年4月份出现,在ios系统上,证书解析非常慢,导致ios调取接口经常超时,而且时很多运营商都出现过这个问题,时快时慢.

起初以为时服务器网络问题,在PC上通过mtr检测后发现服务器和网络正常

使用ios网络诊断工具Best Net Tools 检测发现服务器和网络正常

最终通过人工对比测试发现,国内使用Let’s encrypt证书的网站,和其它证书赛克铁门,发现Let’s encrypt证书在ios系统上响应很慢

问题二

起因,公司某项目调取第三方同步数据接口的队列报错

GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: unable to get local issuer certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

使用postman开启ssl验证接口没有响应,

参考https://stackoverflow.com/questions/46080133/laravel-curl-error-60-ssl-certificate-unable-to-get-local-issuer-certificate 修改php.ini curl.cainof 和openssl.cafile 配置新的证书后,还是报错,和原先配置的证书是一样的,所以并不是这个证书的原因.

最后解决方法,使用guzzle的配置项 verify 设置为false不验证ssl

文档 https://guzzle-cn.readthedocs.io/zh_CN/latest/request-options.html#verify

总结

解决问题后,需要问为什么会出现这些问题,重新复习一下ssl相关知识和原理,后续慢慢完善

是什么?简介

干什么?用途

怎么干?应用

为什么?工作原理

微信是一个很好的参照物，被大家广为使用并接受。这个扩展就是通过发送微信朋友圈和聊天会话发送了大量图片，对比原图与微信压缩后的图片逆向推算出来的压缩算法。

TIPS:

• ∞ 符号表示无穷大
• [ 1,3 ) 这是一个区间，表示从1到3之间的所有实数,左边中括号表示闭区间，也就是把1算在区间内。右边小括号表示不包括3。

算法 Luban

参考：https://zhuanlan.zhihu.com/p/56595874

1.判断图片比例值，是否处于以下区间

• [1,0.5625)即图片处于[1:1 ~ 9:16] 比例范围内
• [0.5625,0.5)即图片处于[9:16 ~ 1:2]比例范围内
• [0.5,0) 即图片处于[1:2 ~ 1:∞]比例范围内

2.判断图片最长边是否过边界值

• [1,0.5625)边界值为:1664 * n (n = 1) ,4990 * n （n=2), 1280*pow(2,n-1)(n>=3)
• [0.5625,0.5)边界值为:1280 × pow (2,n-1) (n>=1)
• [0.5,0)边界为:1289*pow(2,n-1)(n>=1)

3.计算压缩图片实际边长值，以第2步计算结果为准,超过某个边界值则：width/pow(2,n-1),height/pow(2,n-1)

4.计算压缩图片的实际文件大小，以第2,3步结果为准，图片比例越大则文件越大

size=(newW*newH)/(width*height)*m

• [1,0.5625)则width& height 对应1556,4990,1280 *n (n>=3),m对应150,300,300;
• [0.5625,0.5) 则width=1440,height = 2560,m=200;
• [0.5,0)则width = 1280,height = 1280/scale,m=500;注:scale为比例值

5.判断第四部的size是否过小

• [1,0.5625) 则最小size对应60,60,100
• [0.5626,0.5)则最小size都为100,
• [0.5,0)则最小size都为100

6.将前面求到的值压缩图片width,height,size 传入压缩流程,压缩图片直到满足以上数值。

算法2

参考:https://blog.csdn.net/a429778435/article/details/80604470

图片尺寸
宽高均 <= 1280，图片尺寸大小保持不变
宽或高 > 1280 && 宽高比 <= 2，取较大值等于1280，较小值等比例压缩
宽或高 > 1280 && 宽高比 > 2 && 宽或高 < 1280，图片尺寸大小保持不变
宽高均 > 1280 && 宽高比 > 2，取较小值等于1280，较大值等比例压缩
注：当宽和高均小于1280，并且宽高比大于2时，微信聊天会话和微信朋友圈的处理不一样。
朋友圈：取较小值等于1280，较大值等比例压缩
聊天会话：取较小值等于800，较大值等比例压缩

图片质量

经过大量的测试，微信的图片压缩质量值 ≈ 0.5

前一段时间,以前一个项目的积分兑换功能出现了库存超扣现象,排查问题时,一看更新时没有加锁,于是以为是锁的问题,加锁之后没有仔细推敲就汇报bug修复完成.

//初始代码
DB::transaction(function () use ($request, $user_model) {
 $goods_model = Goods::find($request->id);
 if ($goods_model->stock <= 0 || $goods_model->stock < $request->number) {
          throw new \Exception('库存不足');
         }
  //扣库存
 $goods_model->stock-=$request->number;
 $goods_model->save();
 ...
});

//第一次修复BUG,增加悲观锁 for update
DB::transaction(function () use ($request, $user_model) {
 $goods_model = Goods::lockForUpdate()->find($request->id);
 if ($goods_model->stock <= 0 || $goods_model->stock < $request->number) {
          throw new \Exception('库存不足');
         }
  //扣库存
 $goods_model->stock-=$request->number;
 $goods_model->save();
 ...
});

昨天接的报告,库存超扣BUG又出现了,立即查看Binlog 日志排查sql执行记录

看日志,同一时刻,有两个线程(386609669,370064926)更新库存,线程386609669 先将库存更新为2 ,线程370064926随后又将库存更新为9 ,并且响应时间760ms ,猜想是数据库响应问题,正考虑其它解决方案,队列或限流等.

看日志nginx,发现在抢购兑换时间内只有几十的并发,看了一下RDS的资源统计使用率不高,感觉悲观锁可以应付的来,不是性能问题.

继续看binlog 日志,发现库存被 线程370064926更新为9之后,又被其它线程386850322更新为3,继续往后看发现同一时间内有好多线程在同时更新库存而且更新库存数量不相同.

百思不得其解,网上Google Mysql高并发扣库存方案,其中有一只乐观锁方案,提到在事物中更新库存时,要比对程序中的库存数量和mysql中的库存数量,突然间恍然大悟,仔细一看代码.果然,犯了一个相当愚蠢的错误.

DB::transaction(function () use ($request, $user_model) {
 $goods_model = Goods::lockForUpdate()->find($request->id);
 if ($goods_model->stock <= 0 || $goods_model->stock < $request->number) {
          throw new \Exception('库存不足');
         }
  //扣库存
 $goods_model->stock-=$request->number; 标注1
 $goods_model->save();
 
 ...
});

问题分析

标注1

更新使用的是程序模型中的库存数量 – 兑换数量

假设stock为 9 number 为 2
上述写法生成的sql 为 update goods set stock = 7 where id = ?
在高并发场景下这么写显然是非常错误的. 假设商品的初始库存为10,ABC三个用户同一时刻兑换商品,ABC读取到程序模型中的库存数量 $goods_model->stock 都是10 ,由于用了悲观锁for update(这不是重点,不用悲观锁也会出现这种情况) 更新语句变为阻塞执行,用户A将库存改为9,用户BC同样将库存改为9,最后库存剩余还是9,这显然与预期结果不服,正确的剩余库存应该为7

扣库存应该采用 Update goods set stock = stock -1 where id = ? 这种语句,更新时读取的是当前记录的stock的值.最后修正结果代码如下:

//最后修正
DB::transaction(function () use ($request, $user_model) {
 $goods_model = Goods::lockForUpdate()->find($request->id);
 if ($goods_model->stock <= 0 || $goods_model->stock < $request->number) {
          throw new \Exception('库存不足');
         }
  //扣库存 正确的操作 或者使用原生update
  $goods_model->decrement('stock');
 ...
});

decrement 方法生成的语句为update goods set stock = stock -1 where id = ?

总结

• 外包项目写多了忽略了程序在高并发场景下可能发生的情况.高并发场景要考虑进程线程之间数据一致性和以及程序和数据库(包含nosql) 的数据一致性问题
• 遇到问题要反复仔细验证,不要轻易下结论

疑问

使用错误的的写法用JMeter模拟并发兑换 20threads/1s 200threads/1s 都没有出现库存超扣现象,由于生产环境不允许压测,所以在本机测试 .猜测可能本机的配置高于服务器,处理能力高于服务器所有没有复现,以后验证成功回头再补充

本机(8核16G) 服务器(4核8G)而且跑了很多项目

解决方案引申

乐观锁

//乐观锁
    public function caseOne(Request $request)
    {
        $this->validate($request, [
            'number' => 'bail|required|integer|min:1',
            'goods_id' => [
                'bail', 'required', 'integer',
                Rule::exists('goods', 'id')->where(function ($query) use ($request) {
                    $query->where('stock', '>=', $request->number);
                }),
            ]
        ]);
        DB::transaction(function () use ($request) {
            $goods = Goods::find($request->goods_id);
            $result = DB::update('update goods set stock = stock - ? where id = ? and stock >= ?', [$request->number, $request->goods_id, $request->number]);
            if (!$result) {
                return response()->json(['message' => '失败']);
            }
            Orders::create([
                'goods_id' => $goods->id,
                'goods_name' => $goods->name,
                'number' => $request->number,
            ]);
        });

        return response()->json();
    }

悲观锁

//悲观锁
    public function caseTwo(Request $request)
    {
        $this->validate($request, [
            'number' => 'bail|required|integer|min:1',
            'goods_id' => [
                'bail', 'required', 'integer',
                Rule::exists('goods', 'id')->where(function ($query) use ($request) {
                    $query->where('stock', '>=', $request->number);
                }),
            ]
        ]);
        DB::transaction(function () use ($request) {
            $goods = Goods::lockForUpdate()->find($request->goods_id);
            $result = DB::update('update goods set stock = stock - ? where id = ? and stock >= ?', [$request->number, $request->goods_id, $request->number]);
            if (!$result) {
                return response()->json(['message' => '失败']);
            }
            Orders::create([
                'goods_id' => $goods->id,
                'goods_name' => $goods->name,
                'number' => $request->number,
            ]);
        });

        return response()->json();
    }

不用事务

//不用事务
    public function caseThree(Request $request)
    {
        $this->validate($request, [
            'number' => 'bail|required|integer|min:1',
            'goods_id' => [
                'bail', 'required', 'integer',
                Rule::exists('goods', 'id')->where(function ($query) use ($request) {
                    $query->where('stock', '>=', $request->number);
                }),
            ]
        ]);
        $goods = Goods::find($request->goods_id);
        $result = DB::update('update goods set stock = stock - ? where id = ? and stock >= ?', [$request->number, $request->goods_id, $request->number]);
        if (!$result) {
            return response()->json(['message' => '失败']);
        }
        Orders::create([
            'goods_id' => $goods->id,
            'goods_name' => $goods->name,
            'number' => $request->number,
        ]);
    }

redis库存

//redis库存
    public function caseFour(Request $request)
    {
        $this->validate($request, [
            'number' => 'bail|required|integer|min:1',
            'goods_id' => [
                'bail', 'required', 'integer',
                function ($attributes, $value, $fail) use ($request) {
                    $stock = Redis::get('goods_id_' . $value);
                    if (is_null($stock)) {
                        return $fail('商品不存在');
                    }
                    if ($stock < $request->number) {
                        return $fail('库存不足');
                    }
                }
            ]
        ]);
        $goods = Goods::find($request->goods_id);
        $result = DB::update('update goods set stock = stock - ? where id = ? and stock >= ?', [$request->number, $request->goods_id, $request->number]);
        if (!$result) {
            return response()->json(['message' => '失败']);
        }
        Orders::create([
            'goods_id' => $goods->id,
            'goods_name' => $goods->name,
            'number' => $request->number,
        ]);
        Redis::decr('goods_id_' . $request->goods_id);

        return response()->json();
    }

队列

public function caseFive(Request $request)
    {
        $this->validate($request, [
            'number' => 'bail|required|integer|min:1',
            'goods_id' => [
                'bail', 'required', 'integer',
                function ($attributes, $value, $fail) use ($request) {
                    $stock = Redis::get('goods_id_' . $value);
                    if (is_null($stock)) {
                        return $fail('商品不存在');
                    }
                    if ($stock < $request->number) {
                        return $fail('库存不足');
                    }
                }
            ]
        ]);
        $goods = Goods::find($request->goods_id);
        SecKill::dispatch($goods, $request->all());

        return response()->json();
    }

https://github.com/yangliuan/shop-demo 有待完善

曳光弹

曳光弹和常规子弹交错装在弹药带上，发射时会照亮弹道路线，如果曳光弹击中目标，那么常规子弹也会击中目标，比提前费力计算更可取，可以及时获得反馈。

类比软件开发，曳光弹适用于新项目。当你构建从未构建过的东西时，与枪手一样，你也没法在黑暗中击中目标。因为你的用户从未见过这样的系统，他们的需求可能会含糊不清。因为你在使用不熟悉的算法、技术、语言或库，你面对这当量未知的事物。同时因为完成项目需要时间，在很大程度上能够确知，你的工作环境将在你完成之前发生变化。

经典的作法是把系统定死，制作大量的文档，注意列出每项需求、确定所有未知因素。限定环境，预先进行大量计算。这种方式非常低效。因为永远有你考虑不到的情况。

注重实效的作法是使用曳光弹，我们要找到某种东西，让我们快速直观和可重复的从需求出发，满足最终系统的某个方面要求。曳光代码并非用过就扔的代码，你编写它是为了保留它。它只是功能不全，可以逐步完善达到最终目标。

曳光开发与项目永不会结束的理念是一致的：总有改动需要完成，总有功能需要增加。这是一个渐进的过程。曳光弹算一种敏捷开发方法。

曳光开发不一定命中目标达到想要的效果。

参考

《程序员的修炼之道从小工到专家》