Go 大小语义

解释如何（不）使用 proto.Size

proto.Size 函数通过遍历 proto.Message 的所有字段（包括子消息），返回其线路格式编码的大小（以字节为单位）。

特别地，它返回的是**Go Protobuf 将如何编码该消息**的大小。

关于 Protobuf 版本的说明

使用 Protobuf 版本 (Editions) 时，.proto 文件可以启用改变序列化行为的特性。这可能会影响 proto.Size 返回的值。例如，设置 features.field_presence = IMPLICIT 会导致设置为其默认值的标量字段不被序列化，因此不会计入消息的大小。

典型用法

识别空消息

检查 proto.Size 是否返回 0 是检查空消息的常用方法。

if proto.Size(m) == 0 {
    // No fields set; skip processing this message,
    // or return an error, or similar.
}

限制程序输出的大小

假设您正在编写一个批处理流水线，它为另一个我们称之为“下游系统”的系统生成工作任务。该下游系统被配置为处理中小型任务，但负载测试表明，当面对超过 500 MB 的工作任务时，系统会陷入级联故障。

最好的修复方法是为下游系统添加保护（请参阅 https://cloud.google.com/blog/products/gcp/using-load-shedding-to-survive-a-success-disaster-cre-life-lessons)），但当实现负载削减不可行时，您可以决定在您的流水线中添加一个快速修复。

func (*beamFn) ProcessElement(key string, value []byte, emit func(proto.Message)) {
  task := produceWorkTask(value)
  if proto.Size(task) > 500 * 1024 * 1024 {
    // Skip every work task over 500 MB to not overwhelm
    // the brittle downstream system.
    return
  }
  emit(task)
}

错误用法：与 Unmarshal 无关

因为 proto.Size 返回的是 Go Protobuf 将如何编码消息的字节数，所以在解组（解码）传入的 Protobuf 消息流时使用 proto.Size 是不安全的。

func bytesToSubscriptionList(data []byte) ([]*vpb.EventSubscription, error) {
    subList := []*vpb.EventSubscription{}
    for len(data) > 0 {
        subscription := &vpb.EventSubscription{}
        if err := proto.Unmarshal(data, subscription); err != nil {
            return nil, err
        }
        subList = append(subList, subscription)
        data = data[:len(data)-proto.Size(subscription)]
    }
    return subList, nil
}

当 `data` 包含一个非最小线路格式的消息时，proto.Size 返回的大小可能与实际解组的大小不同，这会导致解析错误（最好情况），或在最坏情况下导致数据被错误解析。

因此，这个例子只有在所有输入消息都由（相同版本的）Go Protobuf 生成时才能可靠工作。这是出人意料的，并且可能不是设计初衷。

提示： 请改用 protodelim 包来读/写带大小前缀的 Protobuf 消息流。

高级用法：预先设定缓冲区大小

proto.Size 的一个高级用法是在编组前确定缓冲区所需的大小。

opts := proto.MarshalOptions{
    // Possibly avoid an extra proto.Size in Marshal itself (see docs):
    UseCachedSize: true,
}
// DO NOT SUBMIT without implementing this Optimization opportunity:
// instead of allocating, grab a sufficiently-sized buffer from a pool.
// Knowing the size of the buffer means we can discard
// outliers from the pool to prevent uncontrolled
// memory growth in long-running RPC services.
buf := make([]byte, 0, opts.Size(m))
var err error
buf, err = opts.MarshalAppend(buf, m) // does not allocate
// Note that len(buf) might be less than cap(buf)! Read below:

请注意，当启用延迟解码时，proto.Size 返回的字节数可能比 proto.Marshal（以及像 proto.MarshalAppend 这样的变体）将要写入的字节数更多！因此，当您将编码后的字节写入线路（或磁盘）时，请务必使用 len(buf) 并丢弃任何先前从 proto.Size 得到的结果。

具体来说，一个（子）消息在 proto.Size 和 proto.Marshal 之间可能会“缩小”，当：

  1. 启用了延迟解码
  2. 并且消息是以非最小线路格式到达的
  3. 并且在调用 proto.Size 之前消息未被访问，意味着它尚未被解码
  4. 并且在 proto.Size 之后（但在 proto.Marshal 之前）访问了该消息，导致它被延迟解码

解码导致任何后续的 proto.Marshal 调用都会对消息进行编码（而不是仅仅复制其线路格式），这会导致隐式地将其规范化为 Go 编码消息的方式，目前是最小线路格式（但不要依赖这一点！）。

如您所见，这种情况相当特殊，但尽管如此，最佳实践是将 `proto.Size` 的结果视为一个上限，并且永远不要假设该结果与实际编码的消息大小相匹配。

背景：非最小线路格式

在编码 Protobuf 消息时，存在一个*最小线路格式大小*和多个解码为相同消息的较大的*非最小线路格式*。

非最小线路格式（有时也称为“非规范化线路格式”）指的是诸如非重复字段出现多次、非最优的 varint 编码、打包的重复字段在线路上以非打包形式出现等情况。

我们可能在不同场景中遇到非最小线路格式：

  • 有意为之。 Protobuf 支持通过连接消息的线路格式来拼接消息。
  • 意外情况。 一个（可能是第三方的）Protobuf 编码器编码得不理想（例如，在编码 varint 时使用了比必要更多的空间）。
  • 恶意行为。 攻击者可能特意构造 Protobuf 消息，以通过网络触发崩溃。