phpor

5月 112021
 

https://mp.weixin.qq.com/s?__biz=MzU2MDc3OTgwOQ==&mid=2247484142&idx=1&sn=b33ee34c8cf1e290171ee896634d3f58&chksm=fc0385a0cb740cb6fad2c11c55aca9764c267d3959980c506c5adfb456a8c111a5fae321f1cc&scene=132&ascene=0&devicetype=android-29&version=28000339&nettype=cmnet&abtest_cookie=AAACAA%3D%3D&lang=zh_CN&exportkey=Aerk5wJCdNN1LngL1e8TI8Y%3D&pass_ticket=KNotPwjCw%2B35X1eg6d7wXioVvWchi1Wp2pWWZfRKkOqdnm71Hm96S1MQcJehSKd9&wx_header=1

了解了一种查看golang数据结构的内部结构的方法,unsafe加自定义结构体

 Posted by at 下午 12:09
5月 112021
 

示例:

  1. 这里的字符串b复用了字符串a的一部分,使得
    1. 截取操作很快
    2. 字符串a离开作用域而字符串b没有离开作用域的话,a不能被gc
 Posted by at 上午 11:35
4月 112021
 

 

连接状态:

相关代码: src/net/http/server.go

 

 

状态说明:

New: 从Accept拿到一个新连接后,连接被标记为New,并触发hook

Active: 对于http2,只要连接上有请求存在,就算是Active的

Idle: 请求处理完毕,处于keep-alive状态

Hijack: 连接被偷走了,自己不需要继续处理了,这种连接不会进入Close状态的,Hijack 是个终态

Close:连接已关闭

 

参考:

Golang Http 学习(一) Http Server 的实现 – SegmentFault 思否

 Posted by at 下午 4:28
3月 152021
 

https://github.com/dolthub/dolt

让MySQL表也能版本管理,这个对于存储配置的数据库非常不错。

通常使用git存储配置的好处是方便查看变更历史。然而,如何让生产服务器访问却不太方便。

所以,很多时候使用MySQL存储配置,但是,查看变更历史就不那么方便了。

现在,有了dolt,简直太棒了!

 Posted by at 下午 1:56
2月 202021
 

golang程序如果build时不是static的话,Linux上基本会依赖glibc的动态库的,通常也不是啥问题,但是,如果你期望一个更高版本的glibc,但是目标机器上没有,就尴尬了,这时候,其实可以编译成一个静态链接的二进制程序的,这时候需要的就是编译环境上有glibc-static,centos上的安装方法为:

 

那么,静态链接和动态链接后的目标文件差别会非常大吗?

  1. 从目标文件大小上来看,应该会大一些,但是并不大的离谱:
  2. 或许这个差值基本比较固定,你的程序越大,这个差值的占比就越小;但是,和你使用到的glibc中的代码的多少有关系
  3. 从执行的角度来看,动态链接是会启动更快一些,也比较节省内存,因为底层的动态库在内存中只需要加载一次;但是,如果我们的程序是跑在容器中的,而且,通常容器中只有一个进程,那么,扩容器共享底层动态库的可能性就很小,因为它能不是同一个文件(或许有技术可以做到这一点)。
  4. 编译的时候,静态链接会比动态链接要慢一点点,应该差别也不会太明显
  5. 所以,过时的静态链接可能真的又可以回来了

 

静态链接只需要添加选项:

 

注意:

  • 静态链接不代表完全没有依赖,有些情况下对内核版本是有要求的
 Posted by at 下午 12:10
2月 132021
 

参考资料: http://tech.it168.com/a2012/0806/1381/000001381007_1.shtml

 

方式1: 简单的aof文件方式

这种方式只生成aof文件;

优点: 不会定期生成snapshot,对磁盘消耗小(不是少),也不会因为生成snapshot时写磁盘对服务带来影响(虽然影响不太大)

缺点: 重新启动服务时可能需要无法估计的时间

 

方式2: snapshot方式

该方式不生成aof文件,定期产生snapshot文件

优点: 重启服务时,启动速度快

缺点: 会丢失最后一次产生snapshot到意外宕机之间的写数据

 

方式3: aof + bgrewriteaof

1. 产生aof文件

2. 通过 bgrewriteaof 命令定期压缩aof(其实是根据内容中的数据重新生成aof)文件

优点: 不会导致aof文件太大而占用太大的磁盘文件,不会因为aof文件太大而导致重启服务时太慢

缺点: 毕竟重启服务还是要加载aof文件的

 

方式4: snapshot + aof + snapshot点   (该方式是否可行未经验证)

1. 定期产生snapshot文件

2. 产生snapshot文件后,删除文件中snapshot点之前的数据,这样aof就不会太大了

3. 服务重启时,先加载snapshop,在加载snapshot时间点后的aof文件

4. 这样的话,aof文件中记录的命令不应该有类似 incr decr之类的命令,应该都是set、delete之类的命令,这个和snapshot点的选择有关系(没法选择一个确切的snapshot点); 或者: snapshot期间允许用户执行写操作吗?不允许的话就没有这个问题了,如果不允许的话,这个条件也太苛刻了

5. 从redis的源码来看,是不会同时参考snapshot的rdb文件和aof文件的

其实, redis4.0之后,是支持rdb+aof 方式的,这时候,loadAppendOnlyFile() 函数中有rdb相关逻辑,而且,这时候的aof文件的前面部分其实就是rdb文件的内容,但是依然叫做aof文件,所以,依然时候loadAppendOnlyFile() 函数就搞定了。

参考: Redis-4.0以后的混合持久化_gdlsky的博客-CSDN博客_redis混合持久化

 

关于snapshot的频率:

原来以为 save 300 10 解释为: 超过300s或者超过10条变更就snapshot,其实不是的,而是: 超过300s并且超过10条变更就snapshot

 

 

 Posted by at 下午 5:20
2月 092021
 

默认情况下:

使用的是普通代理,就是:

如果访问https地址,就是隧道代理:

如果要让http请求也是用隧道代理,则添加 -p 选项:

如果要让https请求使用普通代理呢?没有找到这个选项

 Posted by at 上午 10:37