离线消息服务保证IM系统的高性能

海量历史聊天消息数据存储 群聊分库分表

群id 不要跨表跨库

合理选择Redis数据结构存储离线信息

存redis抗高并发
zset 有序集合

  1. 添加消息 zadd offlinemsg#{receiverId} #{mid} #{msg} //score就存储消息的id
  2. 查询消息 zrevrange offlinemsg#{receiverId} 0 9 //按消息id从大到小排序取最新
  3. 删除消息 zremrangebyscore offlinemsg#{receiverId} key
  4. 如果单个key消息存储过大，可以考虑按周或者按月针对同一个receiverI多搞几个key分段来存储

收发机制 读扩散 写扩散

索引不好实现
单独列表

搜索服务： 写入es
未读数服务： （小红点 实现多端同步）存储redis 原子加减

基于lua脚本保证消息未读数的一致性

hash结构来存储 hincrby msg：noreadcount：gid uid 1（gid ）

万人群聊系统设计难点剖析

  • 可能问题：
    • 查1w次redis找对应netty服务端 转发接口
    • 消息广播100/s * 10000
    • 未读数2* 10000
      解决办法：
  • 内存操作
  • 定时的批量间隔刷redis
  • 宕机：不需要那么精确

百万在线直播互动场景设计难点剖析

路由转发： 网关+业务mq操作层
网关层加缓存
方案：

  • 不查redis 服务端长连接 网关层推送到netty集群（借助mq获取）
    • netty集群有的占用集群 不占用的消息直接丢掉 channel gid不同丢掉
  • 进入直播间维护到内存中

熔断限流机制保证消息收发核心链路高可用

  • 推送消息时 限流 丢弃消息
    • 有针对性的：对非活跃用户消息丢弃

微信朋友圈与微博大V消息收发架构剖析

亿级流量新浪微博
读写扩散混合机制

  1. 大V和活跃用户需要系统自己根据业务情况做评估打标签
  2. 微博是读写扩散混合，微信朋友圈是写扩散，因为微信朋友数上限是5000，但是订阅号可能是读写扩散混合模式