【IM】十万用户规模

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

一、前言

学习：掌握十万用户规模 IM 架构设计的关键点

总体思路：

0. 业务背景
1. 总体架构思路
2. 存储架构设计
3. 计算架构设计
4. 其它架构设计

业务背景：

假设你现在正在一个创业公司担任 CTO, 因为微信工作生活娱乐不区分,已经发生了很多次将敏感信息(可以自行脑补一下)发错人甚至发错群的尴尬事件了!你司 CEO 决定做一款 IM 工具, 为了区别微信和 QQ 大众化的 IM 需求, 你们公司主打安全 IM, 这款产品的竞争力如下: 主打私密聊天,严格控制私密好友的数量,而不是像微信一样,买个菜都可能要加个微信。 【公司背景】

0. 技术团队大约10个人,后端6个,前端2个,Android 2个, iOS 还没有;
1. 后端 Java 为主,大部分是 P6~P7;
2. 后端具备 MySQL、微服务、Redis 等开发使用经验;
3. 后端没有大数据和推荐相关经验。

业务基本场景：

0. 每个用户都会通过算法生成非对称的公钥和私钥;
1. 用户发送的消息会通过公钥加密,接收用户的消息使用自己的私钥解密;
2. 只能创建一对一聊天;
3. 聊天消息“阅后即焚”,最多只保留60分钟;
4. 无需使用手机号注册;
5. 每个用户最多20个好友。

二、总体架构思路

老板说我们 3 年内要做到1千万注册用户, 作为 CTO 的你应该如何做架构设计?

架构设计思路：

0. 十万规模：落地块，但是如果业务发展很快，架构很快不适应了怎么办？
1. 百万规模：落地慢一些，但同样面临业务发展过快的风险。
2. 千万规模：落地时间可能要 6个月以上，但基本3年内无需再动架构。

架构演进，遵循：

0. 业务规模变化：可以超前化设计应对
1. 业务多样性：无法预测会做什么功能,业务多样性会导致团队人数增多到多少更加无法预测。
2. 3. 技术发展：无法预测,尤其是和法律政策相关的,例如区块链、国产化等。

三、存储架构设计

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

0. 【注册】：十万用户注册信息。
1. 【登录】：虽然 IM 是比较活跃的产品, 但由于是全新的产品, 我们假设十万注册用户, 每天活跃用户有40%, 登录数据是每天4万。
2. 【加好友】：每个活跃用户最多20个好友, 好友关系数 4万 * 20 = 80万关系数据。
3. 【聊天】：假设每个活跃用户每天向 5位好友发送100条消息, 则消息数量为: 4万 * 5 * 100 = 2000万, 且数据当天基本都被删除了, 所以写入、读取、删除次数都可以估算为2000万。

存储架构：

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

10万用户注册信息, 4万登录信息, 80万关系数据。

2. Redis 主备(聊天数据)

2000万写入, 2000万读取, 2000万删除。

MySQL 为什么不用主从读写分离? Redis 为什么不读写分离?

四、计算架构设计

十万用户规模计算性能估算：

0. 【注册】：1年达到十万用户注册, 注册 TPS 很低。
1. 【登录】：虽然 IM 是比较活跃的产品, 但由于是全新的产品, 我们假设十万注册用户, 每天活跃用户有40%, 假设登录时间集中在早晚4小时, 登录 TPS 均值:4万 / 14400 = 3。
2. 【加好友】：每个活跃用户最多20个好友, 好友关系数 4万 * 20 = 80万数据, 按照1年内来计算, TPS 可以忽略不计。
3. 【聊天】：假设每个活跃用户每天向5位好友发送100条消息, 则消息数量为:4万 * 5 * 100 = 2000万;假设每天集中在早中晚3个时间段6小时内(早上1小时中午1小时晚上4小时), 发送消息 TPS:2000万/(3600*6)≈ 1000，读取消息 QPS = 发送消息 TPS, 删除消息 TPS ≈ 发送消息 TPS

计算架构之负载均衡

负载均衡架构如图：

计算架构之缓存架构：

五、其它架构设计

可扩展架构设计：

高可用架构设计 - 同城数据灾备：