【IM】百万用户规模前言架构要解决的核心复杂度：十万：快速验证(核心需求) 百万：快速扩展(辅助需求) 十万用户架构

这是我参与8月更文挑战的第15天，活动详情查看：8月更文挑战

一、前言

学习：

掌握百万用户规模 IM 架构设计关键点

掌握十万用户规模架构如何演进到百万用户规模架构

架构要解决的核心复杂度：

十万：快速验证(核心需求)
百万：快速扩展(辅助需求)

十万用户架构 vs 百万用户架构：

整体思路：

业务背景
总体架构思路
存储架构设计
计算架构设计
其它架构设计

业务背景：

经过公司上下努力, IM 业务蒸蒸日上,数据增长很快,用户活跃数量在短短1年多的时间里面已经上升到60多万了,很快就要迈上百万大关了,你作为公司 CTO, 前瞻性的预判到业务发展给技术带来了挑战,于是准备启动架构演进。

【公司背景变化】：

技术团队从10人增长到30人,后端18个,前端4个, Android 4个, iOS 4个。

公司招聘了2名增长黑客数据分析师,希望能够从数据里面挖掘更多用户痛点和需求。

业务基本场景:

每个用户都会通过算法生成非对称的公钥和私钥;
用户发送的消息会通过公钥加密,接收用户的消息使用自己的私钥解密;
只能创建一对一聊天;（删除）
聊天消息“阅后即焚”,最多只保留60分钟;
无需使用手机号注册;
每个用户最多20个好友;
增加群聊功能,每个私密群聊限制人数为5人。

二、总体架构思路

思路：

百万架构：演进方便快速,但是如果业务发展很快,架构很快不适应了怎么办?
千万架构：落地慢,成本高。
亿级架构：落地慢,成本高,难以演进。

来自老板的两大挑战应对技巧：

挑战1: 纳尼, 这么快就要架构演进?

说明当时的业务不确定性;
说明当时的技术团队规模;
演进的驱动力是业务快速发展;
业务快速发展是老板的英明(关键点 [笑脸])。

挑战2: 为什么不直接做千万或者亿级架构, 这样不就可以一劳永逸了么?

团队规模(“30~100人,按照百万规模设计最好”);
“得加钱”:直接设计千万级别架构要很多钱(多机房、异地多活等);
业务规模可以预测,但是业务复杂度不太好预测(例如:会不会支持比特币支付?)。

三、存储架构设计

百万用户规模存储性能估算：

【注册】：百万用户注册信息。
【登录】：百万注册用户, 每天活跃用户有40%, 登录数据是每天40万。
【加好友】：每个活跃用户最多20个好友, 好友关系数 40万 * 20 = 800万数据。
【聊天】：假设每个活跃用户每天向5位好友发送100条消息, 则消息数量为: 40万 * 5 * 100 = 2亿, 且数据当天基本都被删除了, 所以写入 + 读取 + 删除 = 6亿。
【群聊】：假设活跃用户中有10%的用户发起群聊,平均每人2个,每个群聊每天200条消息。
- 消息写入: 40万 * 10% * 2(群聊) * 200(消息) = 1600万数据;
- 消息删除次数: 等于消息写入数量;
- 消息读取量: 1600万 * 5(每个群最多5人) = 8000万 QPS。

存储架构设计：

MySQL 主备(用户数据 + 关系数据)

100万用户注册信息, 40万登录信息, 800万关系数据。

2. Redis cluster (聊天数据)

聊天: 6亿读写请求; 群聊: 1亿读写请求。

四、计算架构设计

百万用户规模计算性能估算:

【注册】：每日新注册用户不到1万,可以忽略。
【登录】：虽然 IM 是比较活跃的产品, 但由于是全新的产品, 我们假设百万注册用户, 每天活跃用户有40%, 假设登录时间集中在早晚4小时, 登录 TPS 均值:40万 / 14400 = 30。
【加好友】：每个活跃用户最多20个好友, 好友关系数 40万 * 20 = 800万数据, 按照1年内来计算, TPS 可以忽略不计。
【聊天】：假设每个活跃用户每天向5位好友发送100条消息, 则消息数量为: 40万 * 5 * 100 = 2亿, 假设每天集中在早中晚3个时间段6小时内(早上1小时中午1小时晚上4小时), TPS 计算为:2亿/(36006) 3(发+收+删) ≈ 30000。
【群聊】：假设活跃用户中有10%的用户发起群聊, 平均每人2个, 每个群聊每天200条消息, 时间段分布和聊天场景一样。
- 消息写入和删除次数:40万 * 10% * 2 200 * 2(写+删)/(36006) = 1600 TPS;
- 消息读取量:1600 TPS * 5(每个群最多5人) = 8000 QPS。

计算架构之负载均衡：

计算架构之缓存架构：

五、其它架构设计

可扩展架构设计 - 微服务拆分：