4、二进制协议设计：TLV格式、定长格式、变长格式的优劣对比
做交易所系统，绕不开一个核心问题：数据在网络上怎么传？
说白了，就是协议格式的选择。我见过不少团队，一上来就拍脑袋选了个格式，结果后面性能上不去、扩展性差，改起来想死的心都有。
今天咱们就掰开揉碎，聊聊三种最常见的二进制协议格式：TLV、定长、变长。我会结合自己在交易所项目里的真实踩坑经历，帮你理清什么时候该用哪个。
4.1 定长格式：简单粗暴，但别滥用
定长格式，就是每个字段的长度是固定的。比如一个订单消息，订单ID固定8字节，价格固定8字节，数量固定4字节……整个消息体长度也是固定的。
优点很明显：
- 解析速度极快——直接按偏移量读就行，连循环都不用
- 内存布局友好——可以结构体直接映射，零拷贝
- 实现简单——写代码时几乎不会出bug
我在早期做行情网关时，就用的定长格式。那时候觉得：这玩意儿太爽了！一个memcpy搞定一切。
但后来问题来了。业务方说：「我们要加一个字段，订单来源渠道。」我一看协议，所有消息体都是固定512字节，每个字段的位置都焊死了。加字段？得重新定义整个结构体，还要兼容旧版本……
避坑指南：
我曾经因为定长协议扩展性差，被迫搞了个「协议版本号+预留字段」的补丁方案。结果预留字段不够用，又加了第二个预留字段……代码变得又臭又长。
所以我的建议是：定长格式只适合字段极其稳定、几乎不会变化的场景。比如交易所的「心跳包」、简单的「登录认证」。
4.2 变长格式：灵活，但小心性能陷阱
变长格式，就是字段长度不固定。常见做法是：每个字段前面加一个长度描述符，或者用分隔符（比如换行符）来切分。
举个例子，一个逐笔委托消息，可能包含不定数量的「委托明细」。每个明细的长度都不一样。
优点：
- 空间利用率高——不需要为「最大可能值」预留空间
- 扩展性好——加字段只需要在尾部追加
- 适合嵌套结构——比如列表、变长字符串
但变长格式有个大坑：解析性能不稳定。
你想想看，每次解析都要读长度字段，然后跳转，再读下一个。如果消息里嵌套了好几层变长结构，CPU的指令缓存会频繁失效。我在一个项目中测试过，同样的数据量，变长格式的解析耗时是定长格式的3-5倍。
我的经验：
变长格式适合「控制面」消息，比如查询、配置下发。这些消息频率低，但结构复杂。对于「数据面」的高频行情，慎用。
4.3 TLV格式：最均衡的选择
TLV，全称是 Type-Length-Value。每个字段由三部分组成：
- Type（类型）：2字节或4字节，标识这个字段是什么
- Length（长度）：2字节或4字节，标识Value的长度
- Value（值）：实际数据
说白了，TLV就是变长格式的一种「规范化」版本。它把「类型」信息也编码进去了，解析器可以根据Type知道该怎么处理Value。
TLV的核心优势：
- 自描述——拿到数据就知道每个字段的含义，不需要外部协议文档
- 可扩展——新增字段就是新增一个TLV条目，旧解析器会跳过未知Type
- 解析效率适中——比定长慢一点，但比纯变长快很多
我在设计交易所的「逐笔委托」协议时，最终选的就是TLV。为什么？因为逐笔委托的字段会随着业务发展不断增加。今天加个「订单来源」，明天加个「算法标识」，用TLV的话，老系统直接忽略新字段就行，完全不影响。
注意：
TLV也有开销。每个字段多出4-8字节的Type和Length。如果消息里字段很多（比如几百个），这个开销就不可忽视了。我见过有人把每个字段都做成TLV，结果一个简单消息膨胀了30%。
我的建议是：TLV只用于「可能变化」的字段。那些万年不变的固定字段，比如「消息头」，还是用定长格式更划算。
4.4 三种格式的对比表格
| 维度 | 定长格式 | 变长格式 | TLV格式 |
|---|---|---|---|
| 解析速度 | ★★★★★ | ★★☆☆☆ | ★★★★☆ |
| 空间效率 | ★★☆☆☆ | ★★★★★ | ★★★☆☆ |
| 扩展性 | ★☆☆☆☆ | ★★★★☆ | ★★★★★ |
| 实现复杂度 | ★☆☆☆☆ | ★★★☆☆ | ★★★☆☆ |
| 适用场景 | 固定字段、高频路径 | 低频、复杂结构 | 高频、需扩展的协议 |
4.5 实战中的选择策略
说了这么多，到底怎么选？我总结了一个简单的决策树：
- 如果字段永远不会变（比如协议头部的版本号、长度）→ 用定长
- 如果字段可能会变，但变化频率低（比如业务扩展字段）→ 用TLV
- 如果字段是变长列表或嵌套结构（比如多笔委托明细）→ 用TLV或变长
- 如果追求极致性能，且字段固定 → 用定长，配合内存映射
一个小技巧：
我在实际项目中，经常采用「混合模式」：消息头用定长，消息体用TLV。这样既保证了头部解析的极致速度，又保留了体部的扩展性。你可以试试看。
4.6 核心知识体系图
下面这张图，帮你把三种格式的核心逻辑串起来：
嗯，这张图基本把三种格式的定位说清楚了。你想想看，如果你的协议字段未来三年都不会变，那定长格式就是最优解。但交易所的业务，变化是常态。所以我个人更倾向于TLV，或者混合模式。
最后说一句：没有银弹。每种格式都有它的适用边界。理解它们的优劣，结合自己的业务场景做选择，这才是架构师该干的事。
公众号:蓝海资料掘金营，微信deep3321