听说你会架构设计?来,弄一个微信群聊系统( 二 )

  • 消息历史记录:为了确保新成员能够访问以前的消息 , 将此新群组的群组 ID 与用户消息关联存储 。
  • 除了拉好友建群,微信还实现了面对面建群的能力 。
    接下来 , 我们深入探讨了三到四个核心功能的详细设计 , 包括面对面建群、消息发送与接收及抢红包功能 。
     
    4. 面对面建群用户发起面对面建群 , 并输入一个 4 位数的随机码,周围的用户输入该随机码后可加入群聊,面对面建群功能通常涉及数据表设计和核心业务交互流程如下 。
    4.1 数据库表设计
    1. User 表:存储用户信息 , 包括用户 ID、昵称、头像等 。
    2. Group 表:存储群组信息 , 包括群 ID、群名称、创建者 ID、群成员个数等 。
    3. GroupMember 表:关联用户和群组 , 包括用户 ID 和群 ID 。
    4. RandomCode 表:存储面对面建群的随机码和关联的群 ID 。
     
    4.2 核心业务交互流程
    听说你会架构设计?来,弄一个微信群聊系统

    文章插图
    图片
    用户 A 在手机端应用中发起面对面建群 , 并输入一个随机码,校验通过后,等待周围(50 米之内)的用户加入 。此时,系统将用户信息以 HashMap 的方式存入缓存中,并设置过期时间为 3min 。
    {随机码,用户列表[用户A(ID、名称、头像)]}用户 B 在另一个手机端发起面对面建群,输入指定的随机码,如果该用户周围有这样的随机码 , 则进入同一个群聊等待页面,并可以看到其它群员的头像和昵称信息 。
    此时,系统除了根据随机码获取所有用户信息,也会实时更新缓存里的用户信息 。
    听说你会架构设计?来,弄一个微信群聊系统

    文章插图
    图片
    当第一个用户点击进入该群时,就可以加入群聊 , 系统将生成的随机码保存在 RandomCode 表中,并关联到新创建的群 ID,更新群成员的个数 。
    然后,系统将用户信息和新生成的群聊信息存储在 Group、GroupMember 表中
     
    成员加入 , 刷新群员信息之后 B、C 用户带着随机码加入群聊时,手机客户端向服务器后端发送请求,验证随机码是否有效 。服务器后端验证随机码,检查随机码是否存在于缓存中 , 以及是否在有效期内 。
    然后,判断当前群成员是否满员(目前普通用户创建的群聊人数最多为 500 人),如果验证通过 , 服务器后端将用户 B、C 添加到群成员表 GroupMember 中,并返回成功响应 。
    移动客户端应用收到成功响应后,更新用户 B、C 的群聊列表,展示他们已加入的新群聊 。
     
    其它技术组件这样 , 用户 A 通过创建随机码和周围的用户扫描二维码的方式成功建立了一个面对面建群 。这个功能涉及了多个技术组件,包括分布式缓存、数据库、二维码生成和验证等 。
    同时,在面对面建群的过程中相当重要的能力是标识用户的区域,比如 50 米以内 。这个可以用到 redis 的 GeoHash 算法,来获取一个范围内的所有用户信息 。
    由于篇幅有限,这里不展开赘述,想了解更多和二维码生成及位置算法的细节 , 可以看我之前的文章:听说你会架构设计?来,弄一个公交&地铁乘车系统 。
     
    5. 消息发送与接收当某个成员在微信群里发言,系统需要处理消息的分发、通知其他成员、以及确保消息的显示 。以下是这一功能的详细交互步骤,以及数据库存储方案 。
     
    5.1 交互流程消息发送和接收时序图如下:
    听说你会架构设计?来,弄一个微信群聊系统

    文章插图
    图片
    1. 用户A在群中发送一条带有图片、视频或音频的消息 。
    2. 移动客户端应用将消息内容和媒体文件上传到服务器后端 。
    3. 服务器后端接收到消息和媒体文件后,将消息内容存储到 Message 表中,同时将媒体文件存储到分布式文件存储集群中 。在 Message 表里,不仅记录了媒体文件的 MediaID , 以便关联消息和媒体;还记录了缩略图、视频封面图等等 。
    4. 服务器后端会向所有群成员广播这条消息 。移动客户端应用接收到消息后,会根据消息类型(文本、图片、视频、音频)加载对应的展示方式 。


      推荐阅读