IM存储问题解析

问题：对IM系统的消息存储应该如何设计呢？（说的通俗一些：如何设计IM系统的消息表？该题目不会故意为难大家，没有上过IM课的同学也是可以思考和判断的）关于【IM消息存储模型】的相关描述，下面说法正确的有哪几项？

    A、 在点对点聊天场景中，如果用户对消息有定制化操作的需求（比如：消息收藏、消息点赞等），可以对每一条消息针对消息收发双方用户的维度分别存一条数据记录；

    B、在互联网每日几百万消息量的情况下，需要对消息表进行分库分表存储；针对点对点的聊天场景，为了将所有用户的消息落入到同一张表中，需要对每一条消息按不同用户的维度分别存一条数据记录；

    C、 在群聊天的业务场景（比如600人群）中，如果用户对消息有定制化操作的需求（比如：消息收藏、消息点赞等），可以对每一条消息针对所有群用户的维度分别存一条数据记录；

    D、在互联网每日几百万消息量的情况下，需要对消息表进行分库分表存储；针对群聊天的业务场景（比如600人群）， 如果对每一条消息按不同用户的维度分别存一条数据记录的话，会导致严重的写扩散问题。

正确答案：ABD

解析：

A选项： 在点对点的聊天场景中，比如：用户A发了一条消息【 “你真棒！”】 给用户B，用户B可以对这条消息点赞或删除； 如果用户B删除了 这条消息，用户A仍然可以看到这条消息；这就是不同用户对 消息的定制化需求。 怎么实现呢？ 通常的处理方案是： 对同一条消息，根据不同的用户（这里就是用户A和用户B）分别存储一条消息记录。该解决方案虽然存在写冗余（写扩散）的问题，但是对性能和存储不会产生太大影响，反而大大方便了消息的定制化操作。

B选项：【对同一条消息，根据不同用户分别存储一条消息记录】； 该实施方案一方面是了方便消息的定制化，另一个很重要的原因就是方便“分库分表”。 我们这样梳理完整的思路：  首先，消息量大了以后，需要通过分库分表来减少每张表记录的数目； 那么以“from_user”维度分表呢还是以“to_user”维度分表呢？ 因为 消息发送者和消息接收者是 “多对多”的关系，以哪个字段作为分表字段都不合适，都无法做到用户所有的记录都能落在同一张表中，怎么办呢？ 于是乎：【对同一条消息，根据不同用户分别存储一条消息记录】，问题解决！ 举例： 用户A发消息【“你真棒！”】给用户B，存储如下：（from_user=A    to_user=B   flag=1  msg=’你真棒！’……）（from_user=B    to_user=A   flag=0  msg=’你真棒！’……）。

C选项：600人的群聊，消息存储方案如果仍然采用【对同一条消息，根据不同用户分别存储一条消息记录】的话，会导致非常严重的 消息写扩散问题： 消息冗余严重、发消息耗时严重等； 想一下，微信为什么要限制群聊人数的上限是 500 人呢？

D选项： 在互联网每日几百万消息量的情况下，需要对消息表进行分库分表存储；针对群聊天的业务场景（比如600人群）， 如果对每一条消息按不同用户的维度分别存一条数据记录的话，会导致严重的写扩散问题。该选项描述已经非常通俗易懂，没有问题。

作者：王棕生