打点系统

作者gpc

一、打点系统:

(1). 为更好的理解用户,互联网公司会将用户的行为收集上来进行分析.
(2). 互联网公司的用户数和每个用户的行为也很多,会产生打点请求非常多,QPS非常高.
(3). 大数据行为分析

---

二、解决方案:

前端js -> 打点服务器(nginx)收集日志 -> golang并发的消费分析 -> 统计分析 -> 数据显示

1. nginx empty_gif模块设置:

①. 模块ngx_http_empty_gif_module支持:
    location = /abc.gif {    # 输入www.xx.com/abc.gif就会响应1x1的gif图片.
        empty_gif;
    }

②. 为什么用empty_gif来接收与响应?
    a. 如果使用api的json返回,在高并发、网络高峰期、外网高峰期压力非常高.
    b. empty_gif返回数据非常小(Response Headers的Content-Length只有43,network的请求中的size为236B)
    c. 只是单向上报数据,又不用返回给前端具体的数据.(需要返回,因为是http协议,三次握手需要response)

③. 为什么不可以自己存一张1*1的小图呢?
    nginx中的gif空白图片是保存在内存中的,速度绝对比硬盘上读取的快.

1.1 Nginx的405错误:

绝大多数服务器,都不允许静态文件响应POST请求,否则会返回HTTP/1.1 405 Method not allowed错误.

在前端开发中经常模拟后端请求,怎样返回静态数据来查看页面效果?

目前有两种方案解决:

①. 修改配置文件nginx.conf(推荐):
    在nginx.conf中,请求的静态数据路径中,添加如下语句:
    location ~ \.(action|jsp) {
        root $testDataFold;
        error_page 405 =200 $request_uri;         # 把405重新定义一下
    }

②. 修改nginx源码编译:
    找到文件ngx_http_static_module.c,再找到下面代码并注释掉,再按照原来的编译参数,重新编译安装:
    if (r->method & NGX_HTTP_POST) {
        return NGX_HTTP_NOT_ALLOWED;
    }

2. nginx借助access.log记录打点请求:

①. 性能开销最小,最佳方案
②. 为什么不直接用nginx来接收这个请求?
    a. 为了解耦,上层上报应用、上报用户数据和下层统计分析解耦开.
    b. 如果js上报直接发给go也可以.同时要做上报的处理,还要进行运算.
    c. 数据上报与数据分析解耦开

---

三、优化方案:

(1). 减少打点的次数:
     将多个行为事件合并后上传,减少单个客户端的上报次数,会导致事件没有及时上传,影响上报率.该方法是在上报率和服务器资源之间的一种折中方案.可以根据需要定义事件的优先级,分不同的打包策略和上传策略.优先级高的行为,尽量一发生就生成包上传.优先级低的行为,可以将多个行为合并后上传,然后服务端基于统计学的原理来分析数据.
(2). 长连接通道:
     使用长连接通道可以减少客户端和服务端之间的HTTP握手次数,减少服务器的负载,适合用户使用时间长的场景.
(3). 优化NGINX和web服务器之间的连接:
     部分打点系统在qps高的时候丢失数据,可以采用加服务器的方法.让nginx和下游web服务保持长连接,一下将web服务的CPU负载降了下来,提高了单台web服务的负载能力.
(4). 避免流量尖峰的出现:
     带宽、服务器数目等资源往往是由QPS的最高值决定的,而不是平均值决定的.为保证服务可用性,当打点的峰值在10万QPS时,系统就必须保证整个服务能撑起10万的QPS,否则服务的可用性就比较差.为了减少流量尖峰的影响,在设计系统的时候就要尽量避免.如果当时没避免,后面也可以通过观察打点服务的QPS曲线,找到QPS出现尖峰的时候,分析QPS高的原因,看是否可以想办法在业务逻辑上避免,或者在尖峰时刻给每个客户端打点加个随机的延迟,以将尖峰销平.

2. nginx参数优化:

①. gzip on:
    a. 适合几百kb的数据,性能非常好,可以开启节省传输数据大小,但是同时有额外的cpu的计算.
    b. 传输的是几kb的数据,效果不明显.
    c. 内置了数据字典的概念,有相同的字符多的话,效果好一点.