流式解析http build query 字符串

 

脚本:

 

受jq的启发

这个parser很奇怪, 处理的是 value 嵌套value的情况,生产上有这种情况,但是很少见。

tcp 的滑动窗口

tcp的滑动窗口是用来流控的,但是,如果一方不遵守,会怎样呢?如下:

 

我们发现,虽然8085一直提示说win只有430,但是59822却完全无视,直接发送1448大小的数据; 8085也没有生气,也没有不ack,是不是很好玩。

好景不长,59822 觉得不好意思了,改发500大小的数据包了:

 

对于甲方来说,发送了一个小的win ,乙方未必按照小的win发送数据,只要甲方总能ack乙方发送的所有数据,乙方就可以总是发送一个很大的数据包;对于甲方来讲,其实可以通过不ack乙方,或者ack部分数据来制服乙方的。

最近在忙啥

自从雄飞提离职,我就开始了解lua版本的dmp,开始是性能优化,修补丢数据的情况,添加监控,分析指纹数据的流程,直到添加caid的支持。

最近这些事情不敢太随意,步步细心的去做,只是最近添加caid的事情,催的有些急,测试不到位,出了不少问题。

本来答应凯超那里做一些规则引擎的配置节目的事情,以及试金石的优化,都没时间做呢。

总结:

  • 程序总是要有bug的,写完就上线,一定就出错,欲速则不达。
  • 上完线不等于完事儿,必须多方面验证
  • 尤其对数据的写操作,要有如果写错了的预案
  • 有些时候,错误的认知会关上通往真理的大门,敢于否定自己,想办法来验证自己的想法,没有验证的结论就不一定对,就好比没有测试的程序就一定会出错一样

lua 之 require

lua 的 require 会自动避免重复加载的,如:

hello.lua

要想重复加载也行:

由此也可以通过package.loaded 知道都load了哪些包了:

如何知道进程运行在哪个核上

 

下图是htop能直观看到的数据:

第一个CPU很忙,太多的时间花费在了内核,为什么内核那么消耗CPU:

该CPU主要干了三件事:

  1. 硬终端  (估计这个是导致kacpid非常忙的根源)
  2. 软终端  (主要是网卡中断)
  3. 内核进程kacpid

连续执行如下命令会发现acpi中断非常多,而且确实都是发生在CPU0上的,自然处理该中断的也就是CPU0了;如果说要把网卡软中断和acpi中断分开,那么就是,要么把acpi从CPU0挪走,要么把网卡软中断从CPU0挪走

nginx多进程间的负载均衡

nginx是如何把任务分配到每个worker的呢?这种分配平均吗?合理吗?

通过strace  一个worker进程,部分逻辑如下:

我们发现,accept4是放在epoll_wait后面的,不难推测:

  1. nginx的epoll_wait 是在看那个文件描述符有事件发生了(就是需要处理了),当然,这里不包含listen的那个文件描述符(不是不能,是不应该);如果有事件发生,则处理,这些都是已经接收了的连接,有可能是(已建立的连接上的)新的请求。如果没有事件发生,则调用accept4看看有没有新的连接进来。这个逻辑就保证了,如果我比较闲,那么我就接活儿,如果我没闲着,我就不接活儿了

golang的chan阻塞与deadlock

示例:

如上程序:

如果没有第二个go协程,那么第一个协程是消费者,main协程是生产者,消费者死去后,就会出现deadlock错误; 原以为是runtime检测到我们在写一个没人消费的chan感到奇怪而报错,实际上不是的,甚至也不是写不进去而报错,而是,没有一个协程是能被执行的了(就好比陈佩斯的小偷中说的那样,这大半夜的也每个车让我指挥指挥),所以,runtime才感觉很迷茫,就报了个deadlock; 如果有第二个协程在的话,runtime会很高兴地去执行第二个协程的,真的不在意那个chan是否有人消费的。