求教IM架构设计中聊天消息的存储设计（想用levelDB）

即将开发一个集 客服与内部员工 的聊天系统，类似企业微信。整体设计思路参照《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回》。
1.使用Gatewayworker进行消息推送。（这一步应该不会有太大问题，是吧）
2.聊天记录都需要进行存储，扩散写。原本是使用mysql进行消息存储，这样聊天记录数据表设计比较清晰明，查询也相对比较好办。现在组长改变主意，想要参照文章里 基于levelDB模型开发msgkv。想要请教一下大大们 kv型应该怎么设计存储结构呢？小白还是有点懵懵的。谢谢啦~

你们是零基础在做这件事情是吗，我说是im开发基础

引用：JackJiang 发表于 2021-12-08 11:42
你们是零基础在做这件事情是吗，我说是im开发基础

线上是一套稳定运营的客服系统，也是基于gatewayworker进行消息通信。
现在是想重新搞一套，我基本上是之前没做过IM开发，这段时间自己搭了个聊天demo，存储就用redis+mysql，还没涉及到文章中的稳定性等的设计。

引用：Yuntun 发表于 2021-12-08 11:59
线上是一套稳定运营的客服系统，也是基于gatewayworker进行消息通信。
现在是想重新搞一套，我基本上是 ...

纯搞技术的人，很多时候都不站在产品的角度来看im的，im这种产品最重要的就是聊天消息，而聊天消息就是人说话，那么人说话就是有时效性的。这些话包括离线消息、消息记录，

离线消息，比如微信只存72小时（见《史上最全，微信各种功能参数和逻辑规则资料汇总》，你这种企业应用，公司规模再大，几万人顶天了吧，72小时内这离线消息量就该是没有那么夸张的。

另一个消息记录，消息记录这种东西，也一样跟时效性有关，比如热表里只存1周的数据，其它数据要么转储要么删除就好了，这样算下了，数据最多的就是存档表，这个存档表完全可以放在单独的mysql实例，或别的分表里。

这样算下来，其实Im里的数据量（准确的说是热数据），并没有那么夸张，通常情况下，都是用不上levelDB这种号称10亿级别的存储。

引用：JackJiang 发表于 2021-12-08 12:18
纯搞技术的人，很多时候都不站在产品的角度来看im的，im这种产品最重要的就是聊天消息，而聊天消息就是人 ...

感谢回答 Jack的回答~
【捂脸】我也是这样觉得的，公司规模不算特别大，客户数也不算特别多。现在处在开发前的各种模式的确定，也包括mongoDB之类的。实际上还没到那种数据量级 ，确实mysql也是绰绰有余的，而且维护起来也相对简单。
万分感谢~
不过还是好奇 企业微信key-value存储的数据结构设计师怎么样的。

引用：Yuntun 发表于 2021-12-08 13:53
感谢回答 Jack的回答~
【捂脸】我也是这样觉得的，公司规模不算特别大，客户数也不算特别多 ...

别去跟风大厂了，适合的就是最好的。人家还羡慕你小厂的小项目简单好弄，小厂就没必要非得往大了整，那得费多大的劲