如何写出安全又可靠的PHP脚本
前言
咔咔目前所做的项目是一个saas系统，在开发新功能之后，需要为用户角色添加相应的权限，这时整个系统的所有用户都需要添加相应的权限。
因为以前系统的缺陷现在只能用脚本来处理这些工作，所以接下来咔咔将向你介绍如何编写安全可靠的PHP脚本，以及如何事先设计好这个功能，踩过一个坑直接把它埋起来
一、如何写一份安全又可靠的PHP脚本
1-1 设置合理的内存
PHP中使用memory_limit为每个进程设置内存，跑脚本的内存给256M或512M。
通过设置内存来防止脚本执行死循环占用大量的内存，导致系统崩溃。
在文件开头写入ini_set('memory_limit', '512M');即可。
1-2 可接收命令行传参
在PHP中接命令行的参数为$argv，下标0是文件名，下标1为你传入的参数。
简单来说就是先创建一个 index.php文件，然后打印出$argv
执行index.php文件php index.php kaka，打印出来的数据与上面介绍的数组形式完全一样。第一个值是执行的文件名，第二个参数就是携带给脚本的参数。
之前写了一篇laravel中给命令行携带参数不了解一下吗？可以看看，当时是rabbitmq路由模式遇到问题才知道的这个参数，如今在写脚本就可以直接用了。
1-3 使用while死循环执行
$id = !empty($argv[1]) ? $argv[1] : 0;
while(true){
$sql = "select * from user id > $id order by id asc limit 10000";
$res = 执行$sql语句;
if(empty($res)){
break;
}
foreach ($res as $k => $v) {
// 这个id保存每次执行的值
$id = $v['id'];
$checkDataSql = "检测数据是否已存在";
// 不存在时在进行添加数据
if(!$checkSql){
$sql = "insert into user ...";
$res = "执行添加操作";
// 返回最后执行的主键ID
echo $res."\n";
}
}
// 删除此次的变量，防止内存溢出
unset($res);
}
echo 'ok';
简单的解释一下这份代码
接受命令参数，此参数用于防止脚本执行一半挂掉，可以输入参数继续执行。 使用while执行死循环逻辑 获取需要添加权限的数据，每次查询10000行。 死循环退出条件是查询不到需要添加权限的数据。 循环处理每次查询的10000行数据。 将查询出来的数据ID循环一次就赋值给while外层的ID，防止脚本挂掉知道从哪条数据继续执行。 做一步检测操作，判断此条数据是否已经存在将要给添加的权限。不存在时再进行添加操作。 最后一步也是最重要的一步将添加完成的主键ID返回到终端，脚本挂掉直接用这个ID作为参数继续执行。 删除或者10000行数据的变量，防止内存溢出。 最后一步也是最重要的数据处理完成后需要返回一个标识，知道此次脚本已经执行完成了。
这里举的例子的是添加，若你的数据量大的情况下可以进行批量添加、修改。
这份脚本还不是很完善，如你有更好的想法那咱们评论区见。
二、如何提前设计好类似此种情况
1-1 使用脚本刷数据的缺点
新员工对业务不熟悉，数据刷错后恢复数据工作量更大 前期用户基数少没感觉，用户量起来后每次执行脚本会花费很长时间 用户量大之后MySQL深度分页查询非常慢，会人为造成慢查询影响正常用户使用 在你刷数据的同时会有新用户注册进来，非常容易造成数据库死锁。
为什么会产生死锁？
例如你目前的数据数据是这样的，id、authority_info、name
insert into t values(1,5,5),(5,5,5),(10,10,10),(15,15,15),(20,20,20),(25,25,25);
脚本执行语句为update role set authority_info=authority_info+1 where id = 7
此条语句为等值查询会退化为间隙锁，加锁范围为(5,10)，若此时来了一个用户执行语句为insert into role (8,8,8)很遗憾是执行不成功的。
update将(5,10)的数据加了间隙锁，在没有释放锁的情况下，这个范围的所有数据是无法添加的。
当然这种情况仅在无主键索引的情况下会产生，因为主键索引的等值查询会退化为行锁。
总之使用脚本刷数据是百害而无一利的，接下来看看如何处理这种情况。
1-2 应用场景
每一家公司注册后，默认有几个角色，如超管、子管、财务、行政、人事等，所有权限都绑定在相应的角色下，使用单条记录方式。
既然需要添加一个CUI功能模块，就需要添加此模块对应的权限，默认情况下为所有租户相应的所有角色添加这个权限。
每一个租户对应角色的权限都存储在角色表中，所有权限信息是在一个json串中存储，并切维护了一个更新时间。
那么我们就以获取权限为切入点，主系统单独维护一个权限表，来看看这个过程是怎样的。
1-2 方案落地
那么如何在这个设计上进行优化，确保后期不再使用脚本进行刷数据，而是让用户自主触发。
role表结构数据如下
系统表
系统添加新功能需要设置权限时，将权限名以json存储至系统表的auth_info中，每次更新权限都添加一条数据。
用户登录后获取role表的更新时间，去系统表中做判断将大于role时间的数据拿出来，将查询出来的权限合并到role表中，并更新这条记录的更新时间。
并将新增的权限维护至应用初始化中，新注册的用户需将所有的权限给添加上，这点根据自身系统看是否需要维护。
1-4 方案弊端
此方案虽然解决了每次添加新权限需要执行脚本，但不可避免用户每次登录获取权限时都需要使用自身的权限时间跟系统权限时间做比对。
无形中会多进行一次查询，这也是咔咔目前能想到的方案，你要是有更好的方案可以探讨一下。
三、总结
本文围绕实际业务进行讨论了脚本如何写、设计缺陷如何后期弥补，在脚本中一定要使用正序（防止新用户注册进来）这点相信大家都清楚。
方案在我看来还不是最优的，你要是有更好的思路，可以在评论区扩展一下。
“坚持学习、坚持写作、坚持分享是咔咔从业以来所秉持的信念。愿文章在偌大的互联网上能给你带来一点帮助，我是咔咔，下期见。
”
