树莓派Buster系统切换阿里云源https

sudo vim /etc/apt/sources.list

删掉之前的所有内容,写上如下内容:

deb https://mirrors.aliyun.com/raspbian/raspbian/ buster main non-free contrib
deb-src https://mirrors.aliyun.com/raspbian/raspbian/ buster main non-free contrib

sudo vim  /etc/apt/sources.list.d/raspi.list

删掉之前的所有内容,写上如下内容:

deb https://mirrors.aliyun.com/raspbian/raspbian/ buster main
deb-src https://mirrors.aliyun.com/raspbian/raspbian/ buster main

然后执行命令生效:

sudo apt-get update && apt-get upgrade -y

如何正确地写一个开源库,并解决实际问题

1、分析编码中的痛点

2、整理这些痛点,结合业务中的场景

3、构建一个合适的业务流转图,明确定义开源库要做什么,不要做什么

4、先结合一个实际的业务场景去构建第一个版本

5、写好完备的单元测试

6、收集其他场景下,业务还有哪些痛点和此开源库有关系

7、循环往复迭代新版本,做好老版本兼容。做不了老版本兼容,直接加首位版本号,1.x.x -> 2.0.0

CentOS在线安装,镜像url如何正确填写?

有时候为了方便快速安装CentOS操作系统,不需要用全量镜像,消耗太长时间制作启动U盘。可以选择在线安装方式。

在线安装方式最麻烦的一点是,CentOS镜像url的路径不知道写什么。

已CentOS8.3为例,使用华为云镜像源。

安装时使用https://repo.huaweicloud.com/centos/8.3.2011/BaseOS/x86_64/os/路径为安装源

这个路径下面的文件截图如下图

该路径下,文件列表截图

cURL IPv6地址时,报错误的解决办法

正常思路下,请求一个IPv6地址,这么写:

curl http://[::1]

结果命令给了一个错误:

curl: (3) [globbing] illegal character in range specification at pos 9

经过多次试验,应该这么写:

curl "http://\[::1\]"

为什么这么写,哪位同学可以帮忙解释一下

临时解除composer命令内存限制

最近项目中,安装新依赖一直会有提示composer内存超了很多的提示,也不知道是不是项目过大导致的,问题挺奇怪的。

COMPOSER_MEMORY_LIMIT=-1 composer require ritaswc/zx-ip-address

用以上方式设置shell 全局环境变量后,执行composer 就不会出现因超出php.ini中配置的memory_limit导致执行失败了

json_encode/json_decode与serialize/unserialize性能对比

PHP里面,有时候需要把数组给字符串化,来存储进redis或者其他缓存系统中。能达到这种效果的有两组函数,分别是serialize/unserialize和json_encode/json_decode。其中serialize/unserialize是序列化,json_encode/json_decode是转换成JSON字符串。以下就以上两组函数的优缺点简单作个对比。

前面已经说明了情况,不仅要对变量进行转义,还要将转义后的内容进行存储、读取,经过本人测试发现,在对变量进行转义方面serialize/unserialize相比之下要比json_encode/json_decode高效一些,不过,也没有高得离谱,那么,对于大数据方面,二者就有比较大的区别了。
举个例子,通过下面这段代码,产生一个包含20万个(数组)元素的数组。

$module = [];
for ($i = 0; $i < 200000; $i++) {
    $module[$i] = ['SN' => $S->doSN(), 'str' => $S->randChar(30)];
}
// doSN()的作用是产生一个10位的订单序列号,randChar(30)是产生一个30位的随机字符串

通过前面的代码对$module数组进行赋值,接下来就是对数组进行转义了,实际操作发现,serialize($module)时会报错,“Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 14684160 bytes) in ”,如下图:

使用serialize对大数组进行操作时报Allowed memory size错

大概的意思是内存超过了系统允许的14684160B,当然也可以修改PHP.INI来加大。而json_encode($module)就不存在这个问题,虽然说笔者没有继续测试下去看看json_encode会不会也出现内存溢出的情况,但是,就目前的情况来说,json_encode似乎要更强大一点。
好了,接着测试另一种情况,“容错”,这里的容错指的是当无法判断需要转义/反转义的变量是数组还是字符串的情况,如下:

$str = ‘PHP’; //简单的定义一个字符串变量,
serialize($str)得到的结果是s:3:”PHP”;
json_encode($str)得到的结果是”PHP”;
都没有报错,同样的,我们看下反转义的。
unserialize($str)出错了,Notice: unserialize(): Error at offset 0 of 3 bytes in

使用unserialize对字符串进行操作报错

json_decode($str)没有报错,返回值是NULL,这个好理解,毕竟前面的$str中的内容不是一个有效的JSON格式数据。

到这里,大概的总结以下几点:
1、大数组情况下,JSON组函数要更耐用;
2、对未知类型的变量进行反转义时,JSON组函数容错性要更理想;
3、相比而言,JSON组函数转义后的字符串要更短一些,作为文件存储,可以节约一定的存储空间。

顺便,对serialize和json_encode的效率进行一个简单的对比,

$stime = time();
 for($i=0;$i<200000;$i++){
  serialize(['SN'=>$S->doSN(),'str'=>$S->randChar(30)]);
 }
 echo '<br><br>进行20万次serialize运算花费' . (time()-$stime) . '秒';

 $stime = time();
 for($i=0;$i<200000;$i++){
  json_encode(['SN'=>$S->doSN(),'str'=>$S->randChar(30)]);
 }
 echo '<br><br>进行20万次json_encode运算花费' . (time()-$stime) . '秒';
serialize和json_encode的对比结果

通过上面的对比发现,20万次同样的操作,serialize比json_encode快1秒,这样算下来,单次执行而言二者基本上是不相上下了。

转载自:https://www.cnblogs.com/gyrgyr/p/9989786.html

WordPress更新加速

WordPress的自动更新程序一直以来,都是特别炸裂的存在。由于众所周知的原因,访问速度太慢,以至于不断超时重试,导致非常坏的体验。

现在国内有个公益组织来加速WordPress的更新过程以及各种大陆以外的服务资源。

名字叫WP中国本土化社区

下载wp-china-yes插件后,能够静默加速国际服务资源的访问,很畅快

NSQ使用curl命令增加一个新Topic

使用nsq的web面板增加topic会有奇怪的问题,如图

这个匪夷所思的问题到现在没有什么解决方法,只能通过另外一种方式,使用http协议增加一个topic

curl -X POST "http://172.16.164.248:4151/topic/create?topic=purse.withdraw.result"

给Let’s encrypt颁发的SSL证书开启OCSP stapling

在iPhone等客户端打开Let’s encrypt证书的https网站,会出现等待时间过长的问题,究其原因,大概是,https握手的时候,浏览器会去找证书颁发者问,目前已经吊销的证书列表有哪些。Let’s encrypt的服务器在海外,因为神秘力量作用,“查已吊销”动作非常耗时。

Let’s encrypt证书免费到香的不行,配合上计划任务,只要服务器不欠费情况下,可以自动续期,全程做到无需人工介入,这点比花钱的单域名证书香太多了。

网络上查询一段时间,发现有个技术叫“OCSP stapling”。先解释一下OCSP:

OCSP 是一个在线证书查询接口,它建立一个可实时响应的机制,让浏览器可以实时查询每一张证书的有效性,解决了 CRL 的实时性问题,但是 OCSP 也引入了一个性能问题,某些客户端会在 SSL 握手时去实时查询 OCSP 接口,并在得到结果前会阻塞后续流程,这对性能影响很大,严重影响用户体验。(OCSP 地址也在证书的详细信息中)

再解释一下OCSP Stapling:

OCSP Stapling 就是为了解决 OCSP 性能问题而生的,其原理是:在 SSL 握手时,服务器去证书 CA 查询 OCSP 接口,并将 OCSP 查询结果通过 Certificate Status 消息发送给浏览器,从而让浏览器跳过自己去验证的过程而直接拿到结果,OCSP 响应本身有了签名,无法伪造,所以 OCSP Stapling 既提高了效率也不会影响安全性。另外服务器有更好的网络,能更快地获取到 OCSP 结果,同时也可以将结果缓存起来,极大的提高了性能、效率和用户体验。

接下来直接上在nginx中,虚拟主机配置OCSP Stapling

先在服务器上找到三个证书文件:www.aa.com.key www.aa.com.pem

另外一个文件可能叫ca.cer

在Windows上打开这个文件是长这样的:

Windows打开查看

在mac预览的时候,长这样:

Mac预览

其实就是Let’s Encrypt 给咱们颁发证书的上一级证书的公钥证书

准备好了三个证书后,在server_name 同一层加如下配置:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /usr/local/nginx/conf/ssl/your.domain.com/ca.cer;
resolver 8.8.8.8 8.8.4.4 114.114.114.114 114.114.115.115 valid=60s;
resolver_timeout 2s;

配置完毕后,执行nginx -t检查一下有没有语法错误,再nginx -s reload走一下

找一台iPhone 打开网站看看速度有没有飞快许多

参考链接:
https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Browser_support
https://www.feiniaomy.com/post/156.html
https://www.sohu.com/a/204468378_612370
https://www.jianshu.com/p/540124f370e0