场景好友系统玩家搜索其他玩家并发送好友请求对方同意后成为好友。好友之间可以查看在线状态、私聊、组队邀请。每个玩家有好友上限。约束中大型手游DAU约50w实时性好友状态变化需秒级好友请求发送可及时查看一致性好友关系必须双向一致选型方案一定时检测好友状态通过MQ发送好友请求。由于玩家可能离线好友请求需存盘可新增eventlog表。对方同意后同样用eventlog发送同意保证一致性。存储快照便于查好友数据。优点实现简单玩家离线也可接收好友请求实时更新好友状态eventlog保证一致性。劣势定时监测会增加服务器压力且可能大部分时候都是无效扫描需额外实现eventlog机制玩家数量大数据库在高并发下成为瓶颈。方案二redis存储好友关系可使用Sub/Push订阅好友在线状态变化。离线请求可存redis使用AOF/RDB存储内存缓存部分快照查询不到时到redis拉取玩家数据。一旦玩家数量增长可通过部署集群。决策采取方案二中大型手游玩家数量大通过redis可以通过集群拓展响应快。批改扣分项方案一提及MQ发送好友请求但MQ通常用于最终一致性它的消息消费有延迟那么秒级实时的约束就不可实现。概念混淆方案二中提及Sub/Push订阅好友状态但该机制是广播如果有200个好友上线时就广播200个人后果是200个人同时在线瞬间产生200条redis消息网关可能被打爆。正确做法单播例如A上线挨个RPC/推送通知好友。优化redis clusterhashlua脚本本地缓存存储设计redis hash存好友列表friend:{uid} - {{fid1,status}, {fid2, status}}理由Hash能在一个key中存储好友ID和状态减少IOstatus直接支持在线/离线查询无需二次查库一致性保障使用Lua执行添加/删除理由Lua在redis端原子执行保证Add(uid1,uid2),Add(uid2,uid1)同时成功杜绝单向好友。状态同步上线Hash加载到本地缓存遍历好友ID单播推送上线下线修改redis状态为离线单播通知好友下线理由单播更可控