【源码阅读】vm-insert与vm-storage之间的通讯

先说结论

vm-insert与vm-storage之间采用极其简单的通讯协议
- 对于简单的场景，越简单性能越高
- vm-insert连接到vm-storage后，先发送字符串vminsert.02，vm-storage收到后回复字符串ok，然后握手成功
- vm-insert发送一个字节的压缩标志给vm-storage：1.默认会启用zstd压缩算法；2.除非命令行中使用-rpc.disableCompression来禁止压缩
- 通讯协议使用：固定字节表示长度 + ZSTD压缩内容
  - ZSTD的压缩解压缩速度比最快的snappy稍慢，但是压缩率比zlib还要高。
- 通讯协议看起来是单工的————也就是说，是请求-响应模式；无法在一个TCP通道上做到多个请求+响应。（为了简单嘛，也能理解）
- 通讯的回包也极其简单：返回1代表成功，返回2代表存储节点只读。
序列化方面：
- vm-insert中：直接在一个buffer里面追加内容
- 每个字段使用 length + value的形式
- 因此序列化很快（从占用空间的维度说，并不见得比PB更好）
高数据压缩比：
- 从之前的监控数据统计来看，vm-insert进来的数据和发送到vm-storage的数据相差29倍
- 简单协议+自定义序列化+合并发送+zstd压缩，最终达到了这个效果，牛逼
合并发送：
- vm-insert的每个http处理handle中，每个请求的所有metrics先序列化到context的buffer中
- 然后放到connection对象的buffer中
- connection对象的buffer达到一定长度后，进行压缩，然后发送给storage
- 有坑：vm-insert转发到vm-storage必然有一定时间的延迟；且vm-insert突然崩溃的话，必然丢失部分数据。
  - 在监控数据极少的情况下，会不会一直等待？还没有看到对这种情况的处理。
并发的处理：
- http handle部分的处理是并行的，放到connection的buffer的时候加锁了（还有挺多细节没看明白）
vm-storage的寻址：
- 对所有的label_name + label_value + projectid + accountid进行了hash运算
- 使用了性能吊炸天的xxhash库
- 使用uint64的hashcode，然后通过hash一致性算法，取得后端多个storage节点的下标
- 因此：同一个time series被固定的发到一个后端节点上。storage节点的增加和减少只影响部分time series
- 理论上可以修改源码，比如只对__name__取hashcode，这样的话，同一个监控项会被发到同一个存储节点上
后端容灾的处理：
- 如果发送给vm-storage失败，会对数据反序列化，然后重新计算hashcode，然后重新选vm-storage节点。
  - 新增vm-storage只能重启vm-insert，因此不存在对新服务发现的需要
- vm-storage节点的侦测、迁移、恢复的逻辑，还没看到。

巴特西

【源码阅读】vm-insert与vm-storage之间的通讯

先说结论

最新文章

热门文章