聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

空间优先的 protobuffer / json 解码器

2022-08-12 12:12 浏览: 2317490 次 我要评论(0 条) 字号:

今天同事给我转了一个帖子 ,说的是 golang 在处理大量并发 json / protobuffer unmarshaling 事务时,可能产生大量的 (10GB) 临时内存,无法及时回收的问题。

我的观点是:如果一个系统的某个模块有可能使用 10G 这个量级的内存,那么它必然是一个核心问题需要专门对待。核心问题应该有核心问题的考量方法,这不是 GC 之错,也并非手动管理内存一条解决之道。即使手工管理内存,也无非是把内存块之管理转嫁到一个你平常不太想关心的“堆”这个数据结构上,期待有人实现了一个通用方案尽可能的帮你解决好。如果随意使用,一样有类似内存碎片无法合并之类的问题,吃掉你额外的内存。如果它存在于你的核心模块,你一样需要谨慎考量。

在这个具体问题上,我认为还是应该先简化数据结构,让核心数据结构变得易管理。显然、固定大小的数据结构是最容易被管理的。因为如果你的数据结构大小固定,就不再需要堆管理,而是一个固定数组滚动处理临时数据。

json 这样的弹性数据结构看起来不太好用固定大小的数据结构去描述,但稍微想点办法也不难做到。C 在这方面的库不少,我就不一一列举。核心想法一般是:用一个固定数据结构去引用编码数据中的切片。解码后的结构只保留元素的类型以及在原始数据中的位置。如果你能大致知道需要解码的数据元素的数量级,那么就可以用一个固定大小的结构去承载解码结果,不需要任何动态的内存分配。

只不过大多数库把目标都放在时间因素上,让解码更快;少放在空间因素上,让解码过程少使用内存;所以这样的解码方式并不常用。如果你的核心问题于此,你就得去考虑这样的方案。

protobufffer 会比 json 的结构更适合这样做。因为它已经把数据的 key 部分转换成数组 id ,且整体数据结构是明确的。但只是因为 protobuffer 编码更繁杂,不如json 那么简单,反而相关的库更少。


第二、如果你真的有这样的需求:要解码成千上万的数据结构类似的数据包。就应该考虑下列模式:

假设你要解码的数据块的类型是 X ,可以预先生成一个叫做 X 的 accessor 访问器。当你的业务逻辑需要访问 X.a.b 这个字段的时候,应该去调用 X.a.b(binary) ,此处的 binary 指编码过的 json/protobuffer 数据块,X.a.b() 是一个预生成好的访问器函数,它可以用最优化的方法从数据块中提取出需要的数据。

我们还可以进一步的为 X 做一个索引函数,可以预处理 binary ,制作一个固定内存大小的索引信息结构,为具体字段的访问加速。

这个 accessor 对象不太在乎多复杂,因为它可能在整个程序中只初始化一次。



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复