1700509066
1700509067
顾名思义，长连接的连接时间较长。它和短连接的区别在于，在三次握手之后，通常要进行不断往复的数据交互，即在连接建立后，Server和Client之间会一直保持着这个连接，并通过这个连接相互发送数据。
1700509068
1700509069
从功能上来说，长连接的好处是连接断开之前Server能在任意时刻向Client发送数据信息，这个功能是短连接不具备的，好处显而易见。而且，再次从Client向Server发送消息也不用进行三次握手。我们平时用的QQ、微信等各种IM工具都要至少拥有一条基于长连接的连接来保持信息往返的畅通。
1700509070
1700509071
当然，长连接也有它的缺点，就是对Server和Client的内存都有一定的占用——因为要维护这条连接是需要内存保存信息的。而对于可以同时容纳数十万长连接的Server来说，内存占用当然就更为明显。从工程经验角度来看，大部分服务器上的轻传输业务的长连接通常只占用1KB到4KB不等的内存，具体占用的大小与内核设置有关，也同时与长连接上传输的内容多寡有关。具体占用的情况可以在实测时用free命令（Linux命令）查阅。
1700509072
1700509073
数据科学家养成手册 [:1700503611]
1700509074
12.2.6 消息格式
1700509075
1700509076
对于一种已经定制好的日志来说，把日志信息原原本本报送给服务器就可以了，通常不需要进行太多其他处理。但是，如果这种数据收集具有比较大的自主性，甚至在收集数据的生命周期中还需要进行不定时的修改，这个时候就要下点功夫设计整个数据收集的逻辑了。按照我的经验，一般需要注意两点。
1700509077
1700509078
注意点1：报送格式尽量采用Key-VaIue键值对的形式
1700509079
1700509080
这种形式的好处是格式清晰，可扩展性高，Key和Value一一对应，在报送到服务器的时候方便进行切割和对应归档。而且，如果需要进行删减或者增补，只要直接删减或者增加键值对就可以了。
1700509081
1700509082
在处理HTTP Web请求时使用的GET方式就是一种非常典型且非常好用的键值对方式。以“https://www.baidu.com/s?wd=vgg19＆rsv_spt=1＆rsv_iqid=0xf5ddc0c10008f89b＆issp=1＆f=8＆rsv_bp=0＆rsv_idx=2＆ie=utf-8＆tn=baiduhome_pg＆rsv_enter=1＆rsv_sug3=6＆rsv_sug1=5＆rsv_sug7=100”这个URL为例，“https://www.baidu.com/s”是服务器的地址和虚拟路径，“?”表示其后都是GET方式的键值对。这些键值对之间用“＆”分割，键值对内部用“=”分割，内容清晰。Web服务器只要对这个URL进行解析，就可以把所有要报送的值都接收下来。
1700509083
1700509084
wd=vgg19＆rsv_spt=1＆rsv_iqid=0xf5ddc0c10008f89b＆issp=1＆f=8＆rsv_bp=0＆rsv_idx=2＆ie=utf-8＆tn=baiduhome_pg＆rsv_enter=1＆rsv_sug3=6＆rsv_sug1=5＆rsv_sug7=100
1700509085
1700509086
使用Web服务器接收数据时也可以采用POST方式，其接收方式与GET类似，但发送的数据量更大，在此就不赘述了。只补充一句：在这个环节，不论是GET方式还是POST方式，都有一些传输非ASCII字符的场景。在这些场景中，会考虑使用Base64编码进行传输，然后在接收端进行解码（如图12-7所示）。Base64的编/解码方式是开源的，在Java、Python等语言中都有很成熟的实现类。Base64编码不是用来加密的，而是用来实现二进制到文本的传输。
1700509087
1700509088
1700509089
1700509090
1700509091
图12-7 Base64编码
1700509092
1700509093
注意点2：自举要方便
1700509094
1700509095
所谓“自举要方便”，是指在终端采取的数据收集策略要比较灵活，要允许在几乎任意时刻对收集策略进行修改。这种方式很容易实现，可以从两个地方入手，一个是终端自身的自举程序，另一个是策略文件。
1700509096
1700509097
自举程序像PC硬件的自举一样，有一种约定的标准启动方式。
1700509098
1700509099
PC的自举过程是：在启动时先读BIOS，再按顺序读取BIOS中“1st Boot Device”、“2nd Boot Device”、“3rd Boot Device”这些设备的启动扇区，通过启动扇区里面的程序指针完成一系列自举的程序段跳转，最后引导计算机系统启动（如图12-8所示）。如果没有这样一个“雷打不动”的约定步骤，计算机系统是不可能启动的。
1700509100
1700509101
1700509102
1700509103
1700509104
图12-8 PC BIOS中的Boot Device配置
1700509105
1700509106
在每台终端上安装数据收集程序也是一样的。数据收集程序通常要做两件事，第一件事是周期性地前往一个URL地址下载策略文件，第二件事是确定执行这个策略文件的内容。
1700509107
1700509108
所谓“周期性地前往一个URL地址下载策略文件”，是指程序里面要有这样的功能：在每天、每小时或者更短的时间间隔，到一个URL去下载一个策略文件。这个周期可以按照自己的业务需求而定。如果周期太短，不仅会给服务器造成不必要的压力，也没有必要；如果周期太长，策略生效的实时性也会降低。所以，对这个度要好好考量，并且要紧扣业务需要。文件的URL最好是一个域名，这样就不会因为IP地址的迁移而导致地址失效。
1700509109
1700509110
策略文件就是具体的报送逻辑——需要报送什么字段，以什么逻辑收集，报送到哪里，用什么格式承载这些信息。一般的策略文件都是脚本文件，由终端上的脚本库提供支持。在智能手机上，通常通过App版本的迭代直接升级（用C或Java编译的二进制文件居多）。PC上的情况类似，在程序里加入一些升级模块，可以直接升级一个 .dll文件，或者用其他库文件来更新。如果终端环境相对封闭（例如专用的ARM平台），也可以考虑在其中加入Python或者lua库，这样就可以将Python或者lua脚本作为策略文件，可读性更强，版本管理也比较方便。
1700509111
1700509112
数据科学家养成手册 [:1700503612]
1700509113
12.2.7 维度分解
1700509114
1700509115
维度分解是日志收集中在入库前的最后一个环节。所谓维度分解，就是把收集上来的消息格式分解成数据库或数据仓库可以识别并存储的格式（如图12-9所示）。