lua-seri模快建议增加压缩特性，优化解码性能

[JackLeeDev]

项目玩家数据定期存档，当有大量玩家数据存档(背包物品、任务多的时候)，DB节点会触发socket buffer相关警告，并且消息的解码性能会严重影响DB节点的性能。建议lua-seri支持下数据压缩，减少DB节点通讯流量，优化下解码性能。目前项目的解决方案是重写消息序列化模块，大消息编码大小-50%，解码时间-40%。参考：https://github.com/JackLeeDev/qseri

[cloudwu]

我不希望改动这个核心模块增加复杂度和维护成本。

但如果你在使用 cluster 模块时，如果需要节省 cluster 间的带宽，建议外加上压缩。有两个方案可供选择：

1. 在 https://github.com/cloudwu/skynet/blob/master/lualib-src/lua-cluster.c 这里直接对 cluster 间的数据进行压缩。
2. 在 https://github.com/cloudwu/skynet/blob/master/service/clustersender.lua (发) 和 https://github.com/cloudwu/skynet/blob/master/service/clusteragent.lua (收) 这里插入消息的额外压缩解压。

[cloudwu]

另外，我感觉就类似的应用场景，想修改 lua-seri 的话，有一个比较简单有效的方案：

1. 增加一个叫做 stringid 的类型
2. 每个服务可以注入一个预编码好的 string/id 表
3. 编码的时候，碰到这张表里的字符串，编码为 id
4. 解码的时候，把 stringid 还原为 string

这样只需要先额外同步一下每个服务的预编码表，注入到当前服务中。编码和解码都可以更快，因为查表的时间相对构造字符串的时间，无论是编码还是解码环节都可以大大加快。

[JackLeeDev]

这个方案之前考虑过，进程内消息消息编码使用string id是可行的，但是进程之间涉及到id的同步，会很麻烦，不好维护，比如节点宕机也需要恢复这个id。另外之前在设计双端开发协议库的时候(不需要定义协议),也有考虑过这个方案，最终还是因为id同步问题放弃了。

[cloudwu]

实际上你并不需要进程间同步。你可以硬编码到一个文件中，大家一起加载这个文件就可以了。额外在启动时相互校准一下 hash 值，或者干脆在一开始就从中心节点获取。至于这个文件怎么生成，用经验数据就可以：log 一些实际传输的数据，解码后统计，获取最常用的字符串，生成的表留到下次全量冷启动的时候更新使用。

这只是一个可选加速，不在表内的字符串依然是按常规编码的。

[JackLeeDev]

1、生成文件这个没有考虑过，不过文件生成本身就会增加维护成本。另外热更新过程中，多个进程的短字符串id文件会有短时间差异，运行时新增短字符是否需要支持，不同进程字符id生成可能会有先后顺序，如何保证生成的id一致等等，都是很大的维护成本，这个方案感觉不是很合适。
2、不在表内的字符串依然是按常规编码这个在双端协议库中是有测试过的，单独加了一个stringid的类型，是可行的。目前平衡了性能、消息包大小、可维护性等，将大消息的字符id表单独编码进消息可能是最合适的。但是除了DB消息，其他消息大部分都很小(会损失性能，编码也会变大)，最终的方案是DB消息采用压缩(即使压缩,由于解码更快，总耗时依然会少一点)，非DB消息不压缩。

[JackLeeDev]

即使只是冷启动前生成一份，后续不再变化，但是开发环境，多个进程也有可能出现版本不一致的情况。另外线上环境DB节点可能是长期不停服的，这个运维流程上可能也要修改。

[JackLeeDev]

不管是从文件获取还是从中心节点获取还是动态生成同步，额外的维护成本并不低。根据游戏的业务需求，只压缩DB消息可能是最简单，最好维护的。

[sniper00]

无限制增长的数据，为什么不设计分条存？

[JackLeeDev]

是否分条存取决于项目自身的情况，比如服务器是否有状态，数据状态有变化是否立即存档，立即存档是否会导致DB压力过大，定期存档是否需要引入更多的数据状态维护代码，是否会影响开发效率，收益是否大于可维护性等等。

[sniper00]

是否分条存取决于项目自身的情况，比如服务器是否有状态，数据状态有变化是否立即存档，立即存档是否会导致DB压力过大，定期存档是否需要引入更多的数据状态维护代码，是否会影响开发效率，收益是否大于可维护性等等。

你说的这些问题不大，首要目标的降低你档次存档操作的数据量

[JackLeeDev]

你可能还没理解...

[cloudwu]

如果你要发往 db 节点的数据信息密度很低，我觉得应该考虑在本地一个服务先汇总，然后合并分批压缩，按带宽再传输到 db 节点。

只要做了本地的这个中转点，想怎么压缩加工都能很方便的做。

[JackLeeDev]

这个可以考虑。