在线变更MySQL千万级表结构实战

1.背景

IM作为社交应用的基础服务,承担着即时聊天、群聊、直播、多人语音等功能。即时聊天又是众多功能模块中最重要的一个,需要维护两个用户的会话(多对多)关系,随着应用推广用户量级在不断增加会话关系呈指数级增长,获取会话信息接口调用频率呈指数级增长,由于应用立项比较匆忙,对应用发展速度预估比较悲观,且初期人力资源有限没有引入分库分表,单表数据指数增长所以响应速度肉眼可见的变慢,优化会话表迫在眉睫

相关概念

  • 会话

  • 拉取会话

2.问题现状

假设每个活跃用户会话数是10个,当日活为100时,总会话数大约是在1000左右;当日活到达百万时, 每日的会话数量就是一个较大的数量级,在实际业务场景中只要用户发生对话并且在会话列表中没有当前聊天会话就会调用接口(qps为1000,rt为400ms左右)获取会话信息,调用频率高响应速度慢导致用户体验很差,用户活跃高峰期常因该接口导致服务器cpu长时间处于极高负载状态,严重时直接导致整个系统瘫痪

3.解决方案

问题点

  • uid是会话发起方id,to_uid是会话接收方id,uid在实际业务中是付费者的角色,to_uid是获益者的角色,uid找to_uid聊天需要花费一定的费用。在这样的商业背景下设计出了uid和to_uid的表结构,虽然这种结构满足了商业要求,但是仍然存在业务缺陷,如:

查询用户1(id = 1)与用户2(id = 2)、用户

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值