业务背景

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

【公司背景】

1. 技术团队大约10个人，后端6个，前端2个，Android 2个，iOS 还没有；

2. 后端 Java 为主，大部分是 P6~P7；

3. 后端具备 MySQL、微服务、Redis 等开发使用经验；

4. 后端没有大数据和推荐相关经验

业务基本场景

图片

1. 每个用户都会通过算法生成非对称的公钥和私钥；

2. 用户发送的消息会通过公钥加密，接收用户的消息使用自己的私钥解密；

3. 只能创建一对一聊天；

4. 聊天消息“阅后即焚”，最多只保留60分钟；

5. 无需使用手机号注册；

6. 每个用户最多20个好友

总体架构思路

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

十万：落地快，但是如果业务发展很快，架构很快不适应了怎么办？

百万：落地慢一些，但同样面临业务发展过快的风险。

千万：落地时间可能要6个月以上，但基本上3年内无需再动架构。

超前设计，架构真的不用动么？

图片

1. 业务规模变化

可以超前化设计应对。

2. 业务多样性

无法预测会做什么功能，业务多样性会导致团队人数增多到多少更加无法预测。

3. 技术发展

无法预测，尤其是和法律政策相关的，例如区块链、国产化等。

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

图片

【注册】

十万用户规模

【登录】

虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设十万注册用户，每天活跃用户有40%，登录每天4万。

【加好友】

每个活跃用户最多20个好友，好友关系数 4万 * 20 = 80万 关系数据

【聊天】

假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：4万 * 5 * 100 = 2000万，且数据当天基本都被删除了，所以写入、读取、删除次数都可以估算为2000万

存储架构设计

图片

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

图片

【注册】

1年达到十万用户注册，注册 TPS 很低。

【登录】

虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设十万注册用户，每天活跃用户有40%，假设登录时间集中在早晚4小时，登录 TPS均值：4万 / 14400 = 3。

【加好友】

每个活跃用户最多20个好友，好友关系数 4万 * 20 = 80万数据，按照1年内来计算，TPS 可以忽略不计。

【聊天】

假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：4万 * 5 * 100 = 2000万;

假设每天集中在早中晚3个时间段6小时内（早上1小时中午1小时晚上4小时）；

• 发送消息 TPS：2000万/（3600*6）≈ 1000；

• 读取消息 QPS = 发送消息 TPS，删除消息 TPS ≈ 发送消息 TPS

计算架构之负载均衡

图片

计算架构之缓存架构

可扩展架构设计

图片

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

图片

Redis 存储的 IM 消息数据为什么不做跨机房备份？

1.性能问题 2.一致性问题 3.成本问题