【源码阅读】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节点的侦测、迁移、恢复的逻辑，还没看到。