1. 项目背景与核心价值

即时通讯（IM）系统中的好友管理模块，就像现实生活中的通讯录一样重要。这个看似基础的功能，实际上承载着用户社交关系的核心数据。我在参与多个IM系统开发后发现，好友管理服务的稳定性直接决定了用户留存率——据统计，约65%的用户流失与好友列表异常相关。

传统的好友管理服务往往存在几个痛点：关系同步延迟导致"幽灵好友"、多端状态不一致、高并发场景下性能瓶颈。我们设计的这套子系统，通过分布式架构和最终一致性模型，实现了毫秒级的关系同步，支持千万级用户同时在线的水平扩展能力。

2. 系统架构设计

2.1 分层架构解析

系统采用经典的四层架构：

接入层 → 逻辑层 → 存储层 → 同步层

接入层使用Netty处理长连接，单机支持5W+ TCP连接。逻辑层采用Spring Cloud微服务架构，关键点在于：

• 好友验证采用异步消息队列削峰
• 关系变更通过事件驱动模式通知下游
• 热点用户数据使用二级缓存策略

2.2 数据存储方案

采用混合存储模式：

• MySQL存储基础关系数据（分库键=用户ID%16）
• Redis缓存全量好友列表（采用Hash结构存储）
• Elasticsearch构建关系图谱（用于推荐好友）

特别设计了"冷热分离"机制：活跃用户的好友列表常驻内存，30天未登录用户数据自动降级到磁盘存储。

3. 核心功能实现

3.1 好友关系建模

使用有向图模型表示关系状态：

enum RelationStatus { PENDING, // 等待验证 ACCEPTED, // 已添加 BLOCKED, // 已拉黑 DELETED // 已删除 }

关键业务逻辑：

1. 添加好友时生成双向关系记录
2. 删除好友采用逻辑删除标记
3. 黑名单实现优先于其他状态

3.2 实时同步方案

基于WebSocket实现多端同步，采用差分更新协议：

[操作类型][时间戳][变更数据]

同步流程示例：

1. 用户A在手机端删除好友B
2. 服务端生成删除事件（OP:DEL, TS:123456789, DATA:{uidB}）
3. 推送到用户A的所有在线设备
4. 各端本地数据库原子性更新

4. 高并发优化实践

4.1 缓存策略

采用三级缓存架构：

1. 本地缓存（Caffeine）：存储用户最近操作记录
2. 分布式缓存（Redis）：全量好友列表+关系状态
3. 持久层（MySQL）：最终数据落盘

缓存更新采用"先更数据库再删缓存"策略，通过消息队列保证顺序。

4.2 热点数据处理

针对明星用户（如客服账号）的特殊处理：

• 独立部署关系服务实例
• 读写分离架构
• 客户端限制频繁操作（如10秒内最多添加5人）

5. 异常处理与监控

5.1 数据一致性保障

采用Saga事务模式处理分布式事务：

1. 正向操作记录操作日志
2. 失败时触发补偿事务
3. 定时任务扫描异常状态

5.2 监控指标

关键监控项包括：

• 关系变更成功率（要求>99.99%）
• 同步延迟时间（P99<200ms）
• 好友列表加载耗时（平均<300ms）

我们开发了关系图谱可视化工具，可以实时查看任意用户的好友网络状态。

6. 安全防护措施

6.1 防骚扰机制

• 添加频率限制：每小时最多发起30次请求
• 验证消息内容过滤（敏感词库+AI检测）
• 举报处理流程自动化

6.2 数据安全

• 关系数据加密存储
• 接口调用需要动态令牌
• 重要操作需要二次验证

7. 实战经验分享

7.1 踩坑记录

1. MySQL死锁问题：早期版本在批量处理关系时出现死锁，通过改为异步队列处理解决
2. 缓存雪崩：某次大促期间Redis集群故障，导致数据库被打垮，后来引入多级降级方案
3. 消息乱序：移动端弱网环境下消息顺序错乱，增加了序列号校验机制

7.2 性能调优技巧

• 好友列表分页加载采用"游标+时间戳"双重定位
• 批量操作使用pipeline减少网络往返
• 热更新配置开关控制降级策略

8. 扩展能力设计

系统预留了多个扩展点：

1. 关系变更回调接口（用于触发积分等业务）
2. 自定义关系类型插件机制
3. 第三方系统对接协议

我们在实际项目中曾通过这些扩展点，快速实现了企业通讯录同步、跨平台好友推荐等功能。