Google protobuf使用技巧和经验总结
技巧 & 经验
性能优化
把repeated message结构尽可能摊平为基础类型的repeated字段
基础类型的repeated字段，包含 repeated int32, int64, float,double，bool等，但不包含string、bytes、message
比如：
message Item {
int32 id = 1;
int32 score = 2;
}
message R {
repeated Item items = 1;
}
改为下面的设计，会提升序列化和反序列效率
message R {
repeated int32 item_id = 1;
repeated int32 item_score = 2;
}
原理是非string的基础类型的repeated字段，在申请内存时pb会申请连续线性大块内存，效率高；而message 的repeated字段，会按对象逐个去申请空间。
善用arena管理内存
- arena对基础类型,比如int32, int64, float,double,bool等管理效率优化明显
- arena不会管理字符串类型的内存申请。
用固定长度repeated uint32 替换字符串
字符串是一种不定长的数据结构，内存管理方式成本较高。通过转换成repeated uint32类型，则可以获得更高效的管理。
除此之外，repeated uint32 也支持由arena管理。
善用Any类型
假设3个网络服务的调用关系如下：
A->B->C。
其中存在某些pb结构仅会由B透传给C，而B不需要解析，则可以把这些pb放入定义为any类型的字段中。
利用protobuf一些特性来规避陷阱
良好的可扩展性 & 保留未定义字段
良好的可扩展性使得protobuf更好地向后兼容。上游更新了proto，新增字段，下游虽然没有更新proto文件，但是新增的字段依然可以保留，来自上游的字段可以透传给下游。拼接下游请求的结构pb时，尽可能使用CopyFrom，避免把字段逐个set。
使用编号定位存储的字段
为了更好地向后兼容，应该避免修改proto文件中现有字段的名字、类型。需要修改时，通过追加新字段（字段编号增加），弃用旧字段的方式。
故障相关
protobuf被广泛使用，饱经业界考验，如果遇到问题，绝大多数还是自身软件设计的问题。遇到问题，首先不应该怀疑protobuf，应该把视角集中到去发现自身的系统设计缺陷中。
一次内存泄露的故障排查
现象：
公司里一个c++网络服务中， PV较低时没有内存泄露；而PV较高，cpu idle降到30%以下，开始内存泄露，直到OOM。
排查过程：
用了 tcmalloc和gperf，逐步定位是protobuf 申请 repeated字段的空间，没有及时释放。repeated字段约1k～1w的规模。然后逐步缩小范围。
结果：
竟然是释放内存，都放到了一个线程中。当流量大时，单个线程计算能力成为瓶颈，内存释放变慢，表现为内存泄漏。
转载请注明来源，原地址保持持续更新。
博客首页：作程的技术博客
文章标题：《Google protobuf使用技巧和经验总结》
本文链接：https://it.zuocheng.net/google-protobuf-skills-experience-zh