python msgpack

## 关于msgpack，一个被低估的序列化工具

做后端开发这些年，接触过不少序列化方案。JSON是标配，Protobuf是大厂宠儿，但有一个家伙总是被忽视——msgpack。它就像工具箱里那把不起眼却特别好用的螺丝刀，平时想不起来，真碰上活儿了才发现顺手得很。

到底是个什么东西

可以把msgpack理解成JSON的二进制表亲。JSON用人类可读的文本表示数据，比如{"name": "张三", "age": 30}。msgpack做同样的事，但换成了二进制格式。同样的数据，msgpack表示出来就是一堆字节，人眼看不懂，但机器解析起来快得多。

当初设计msgpack的人目的很直白：要JSON的灵活性，但不要JSON的体积和解析速度。它不像JSON那样需要用大括号、冒号、引号这些分隔符，而是用字节头标明数据类型和长度。比如字符串前面的字节会直接告诉解析器“后面跟着一个长度为N的字符串”。

有意思的是，msgpack的编码规则其实是参考了JSON的数据模型，所以它天然支持JSON里那几种基础类型——整数、浮点数、字符串、数组、映射（字典），外加一些扩展类型。

能派什么用场

msgpack最典型的应用场景是那些对带宽敏感但数据格式又比较复杂的场景。比如游戏的前后端通信，数据包每大一点都意味着更长的加载时间和更多流量费。用JSON的时候，一个简单的玩家状态包可能有两百字节，换成msgpack能压到一百二左右。

另一个常见场景是缓存。很多项目用Redis做缓存，存储结构化的Python对象时，要么手写序列化逻辑，要么直接把对象转成JSON字符串。用msgpack会更省空间，存取速度也快些。特别是存储大量小对象的时候，节省的内存相当可观。

做微服务之间RPC调用时，msgpack也是个不错的选择。它不像Protobuf那样需要预先定义schema，又比JSON省带宽，算是一个折中方案。

最近在一个物联网项目里也用到它。设备上报的数据量很大，每分钟几千条，每条数据包含温度、湿度、电压等十几个字段。用JSON传输，服务器端的解析压力不小。换成msgpack后，不仅带宽省了，解析耗时也降了大约一半。

上手实操

Python里用msgpack特别简单，主要就是两个函数：pack和unpack，和json.dumps、json.loads的用法一样。

importmsgpack data={"name":"张三","scores":[85,92,78,95],"info":{"age":25,"city":"北京"}}# 序列化packed=msgpack.packb(data)# packed 现在是一堆bytes，看不到具体内容，但体积比JSON小# 反序列化unpacked=msgpack.unpackb(packed)# unpacked 和原来的 data 内容相同

有些细节值得注意。默认情况下，unpackb返回的是普通的Python字典，但msgpack的映射类型本身不保证键的顺序。如果需要保持顺序，可以传入raw=False参数。

处理大文件时，最好用流式接口。

# 写入多个对象到文件withopen('data.msgpack','wb')asf:foriteminlarge_data:f.write(msgpack.packb(item))# 从文件中读取withopen('data.msgpack','rb')asf:whileTrue:chunk=f.read(1024)# 不能简单这样，需要处理边界# 实际场景需要用 Unpacker

实际项目中，用Unpacker读流式数据更靠谱。

frommsgpackimportUnpackerwithopen('data.msgpack','rb')asf:unpacker=Unpacker(f)forobjinunpacker:process(obj)# 每个obj就是写入时的一个包

经验之谈

压缩时机要选对。msgpack压的是JSON里的语法结构，不是数据内容本身。如果数据里有很多重复的长字符串，先做gzip压缩再msgpack，效果会更好。但如果是大量的小整数和短文本，msgpack直接处理就够了，加一层压缩反而增加CPU开销。

数值类型有坑。msgpack的整数范围分好几种：正固定整数、负固定整数、8位、16位、32位、64位。Python的int在序列化时会自动选择合适的类型，但反序列化时要注意。默认情况下，64位整数会转成Python的int，但在某些平台上，32位以下的整数会转成int32类型，有时会带来意外的类型差异。

自定义类型扩展。遇到datetime、Decimal这些Python原生类型，msgpack没法直接处理。一种做法是先转成字符串再存，另一种是用msgpack的Ext类型。Ext类型允许注册自定义的编解码器，处理起来更优雅。

importdatetimefrommsgpackimportExtType,Packer,Unpacker# 注册datetime的处理defencode_datetime(obj):ifisinstance(obj,datetime.datetime):# 用4字节存Unix时间戳ts=int(obj.timestamp())returnExtType(1,ts.to_bytes(4,'big'))returnobjdefdecode_datetime(code,data):ifcode==1:ts=int.from_bytes(data,'big')returndatetime.datetime.fromtimestamp(ts)returnExtType(code,data)packer=Packer(default=encode_datetime)unpacker=Unpacker(raw=False,ext_hook=decode_datetime)

版本问题要注意。msgpack有v2版本，改了默认的字符串编码方式。老版本里字符串默认是二进制流，新版本里默认是UTF-8字符串。跨语言调用时容易踩坑，最好明确指定raw参数。

各家对比

和JSON比，msgpack在体积和速度上都有优势，但代价是不可读。调试的时候，JSON可以直接看文本，msgpack就得写工具去解析。所以如果需要经常手动查看数据，JSON更合适。

和Protobuf比，msgpack的优势是不需要定义IDL文件。项目快速迭代时，用msgpack就不用操心维护proto文件。但Protobuf的优势在于强类型约束和跨语言的schema一致性，适合大规模服务架构。

和Avro比，Avro的优势是自带schema和数据的分离，适合大数据场景。msgpack更像一个纯粹的序列化工具，没有这些上层概念。

有次在性能测试中发现，在数据量不大的时候，msgpack的序列化速度其实比json.dumps快不了太多，只有在数据量达到十兆级别时才有明显优势。所以不必神话msgpack，选型要看具体场景。

说到底，msgpack就是一个不张扬但很实用的工具。它不追求像JSON那样一统天下，也不像Protobuf那样需要复杂的学习成本。就是老老实实地做好一件事——让数据在保持结构化的前提下，更小更快。对很多Python项目来说，这就够了。