websocket协议

RFC 6455

消息结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

 0               1               2               3            
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

问题背景

最近在配合研究部门重构ezmt，顺手把热词服务训练相关的模块进行了重构（其实接手这个服务捋清了逻辑后早就想重构了，这次正好趁机搞一下）。在联调结束后，用wrk压了一下性能，结果大跌眼镜，开了6个worker, 但是提高压测的线程数和连接数，QPS始终不见上涨， 几轮压下来QPS只有16-17左右，随着压力的上升，timeout现象非常严重。

于是单独对上游的ezmt热词训练服务压了一下，QPS在29左右

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[[email protected] /home/aidu35/work/third/wrk]$ ./wrk -t 2 -c 10  -d 30s --latency  -s scripts/hotword.lua http://10.12.8.19:8001
Running 30s test @ http://10.12.8.19:8001
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   341.88ms   46.86ms 520.05ms   69.14%
    Req/Sec    15.19      6.48    40.00     89.67%
  Latency Distribution
     50%  341.40ms
     75%  373.19ms
     90%  403.02ms
     99%  451.30ms
  875 requests in 30.06s, 0.92MB read
Requests/sec:     29.10
Transfer/sec:     31.17KB

难道是重构后性能下降明显？于是我们将版本回退为重构前的版本又压测了一遍QPS还不到10

进入容器查看了一下压测时的情况，实际cpu和内存的占用都非常低，这种情况，怀疑有很大可能是网络进程中出现了阻塞调用，于是准备抓取网络进程的off-cpu火焰图。

前一阵加了一个活跃连接数的监控，顺手发现了服务里一个协程泄露的坑，后面看了commit记录这个bug从这个项目开始就一直存在了。。。

0x0 背景

最近在ddsserver上加入了客户端活跃连接数的监控。这个服务是一个使用openresty开发的项目，连接数监控有现成的nginx c module，加入参数 –with-http_stub_status_module 重新编译openresty后在nginx.conf加入

1

stub_status on

在lua代码中直接可以访问这个内置变量 ngx.var.connections_active 来获取当前的连接数，将这个变量集成进prometheus监控里

1

monitor_logger:set("metric_connections", ngx.var.connections_active, {"active"})

在本地测试没有问题后就美滋滋地更新到线上了。

0x0 背景

我们的网站平台上提供了可定制的语言模型功能，用户在使用定制工具定制完成后，这些模型需要让语音识别服务能够访问到。
为了识别服务能够更快的加载这些资源文件，我们需要将资源同步到每台部署有语音识别服务端物理机器上。

我们快速搭建了一套同步的服务，就是上一篇中提及的resync-server,resync-broker和resync-agent。 我们在每台需要在本地使用这些资源的机器上启动了一个resync-agent，它的作用是实时地将定制平台上新产生的资源拉到本地。

好久没更新博客了， 前一阵踩了一个openresty中使用timer的坑，特此记录一下。

0x0 背景

团队6月份在规划华北机房的事情，运维同事在华北部署了一套resync-broker 和 resync-agent， broker挂在了华东的server下面， 恰好华北机房内跑broker的机器只有8G内存，在运行一段时间后，容器直接OOM了。

proc是一个伪文件系统，它被用作内核数据结构的接口，通常被挂载在/proc上，大部分文件都是只读的，但是有一些文件允许内核变量修改。

多态是指代码可以根据类型的具体实现采取不同行为的能力。如果一个类型实现了某个接口，所有使用这个接口的地方，都支持这种类型的值。

如果用户定义的类型实现了某个接口类型声明的一组方法，那么这个用户定义的类型的值就可以赋给这个接口类型的值。

go语言的接口采用鸭子类型的思想（如果走起路来像鸭子，那么它就是鸭子），实现时不需要显式的声明实现了什么接口。下面的Cat和Dog的实现是一个例子:

gin.Default() 默认带有中间件（日志和恢复）的路由
gin.New() 不带中间件的路由

router.GET/POST/PUT/DELETE …

martini restful风格

最近要加一个文件同步的服务，以daemon的方式部署在每台机器上，其他服务进程如果需要访问本机磁盘文件时，如果访问不到需要告诉文件同步服务去远端服务器把文件同步过来，同步文件的服务我们直接对rsync做了一层包装，文件同步存在一个中间状态，即文件已经存在但内容还没同步完成，这个中间状态时其他的进程不能来读取文件，这里我们使用了建议性文件锁来协调进程间文件的读取。

文件锁（File Lock）是一种在特定的时间内只允许一个 进程进行访问文件的机制，通过使用文件锁，可以使得多进程访问文件更加安全