之前在实际业务中遇到过一个 Protobuf 序列化消息导致存储失败的问题，当时这个问题差点导致重大故障，但是也没写文章好好沉淀下来。刚好最近又遇到另一个 Protobuf 的问题，在写完C++ 中使用 Protobuf 诡异的字段丢失问题排查后，又想起前面的这个问题，这里再补一篇文章，好好介绍上次的踩坑过程。故障回顾业务中某个 HTTP 请求必现超时，通过日志，很快定位到是底层的某个服务读 KV 超时了，这里读 KV 在 5s 内都没有结束。因为这是个核心的 kv，监控粒度比较细，平均耗时和 P99 都是毫秒级别的，之前也没出现过耗时这么久的。好在出现问题的这个 key 是必现超时，对于必现问题，查起来就容易多了。直接写了个工具，把超时设置久一点，这样就能读到完整的内容。因为这里存的是序列化后的 protobuf，读出来之后，直接解序列化，然后可以用DebugString打印内容。奇怪的是打印出来的是正常的业务 proto 字段，字段内容也很少，不应该超时才对。于是又返回去重新查看超时的日志，发现日志中有打印从 kv 中读出来的 value 大小有几十兆，难怪耗时那么久。不过为啥 DebugString 打印出来的内容只有几个字段呢？为了进一步确认这里读出来的序列化后的内容有多大，进一步改了下工具，输出 value 的大小，确实是几十兆，和 KV 的日志对上了。几十兆的内容，反序 ...继续阅读 (112)

在C++ 中使用 Protobuf 诡异的字段丢失问题排查这篇文章中，分析过因为两个一样的 proto 文件，导致链接错了 pb，最终反序列化的时候丢失了部分字段。当时也提到过符号决议的过程，不管是动态链接还是静态链接，实际用的都是靠前面的库的符号定义。本来以为对这里的理解很深入了，直到最近又遇见一个奇怪的“符号重定义”问题。问题背景最开始有一个 utils 目录，里面有一些基础代码，编译为一个静态库 A。后来项目中其他目录下又拷贝了一份出来，编译成另一个静态库 B。由于项目复杂的依赖关系(剪不断理还乱啊)，有的目标 target 会同时依赖 A 和 B，好在编译和链接一直都是 OK 的。最近，在模块 B 中的某个 cpp 中，修改了其中一个类，对构造函数添加了一个默认参数。然后调用的时候，也传了具体的参数进去。结果在编译 target 的时候，报错multiple definition。按照我之前的理解，这里对于静态库中的符号，链接决议的时候，从左到右扫描，如果一个符号在前面已经找到定义，后面就会忽略掉。上面静态库 A 和 B，虽然确实是有重复的函数定义，不过应该每个符号都能找到一个定义，然后丢弃后面出现的，链接不应该出错才对呀。复现步骤项目代码太复杂了，不太好直接拿来分析，先来看看能不能写个简单的例子复现这里的问题。这里复现代码的结构如下：12345678910111213➜ ...继续阅读 (106)