好友系统设计

内容

好友关系

双向关系（我们使用的）

uid1	uid2	status
玩家id1	玩家id1	好友状态(0：是好友； 1：不是好友)

这种设计需要考虑数据被多个地方同时修改的问题、单做黑名单功能

单向关系 （更好的方案）

uid	friend_uid	status
玩家id	好友id	状态（0：是好友； 1：不是好友；2：黑名单；3：申请中...）

这种设置可以只修改自己的数据，黑名单可以直接在表里体现，申请状态也可以直接在表里体现，可结合业务情况设计“好友申请”、“黑名单”功能

好友申请

这里可能是一个队列，存在多人修改，被加的人从队列取数据，可能后面删除数据（同意或拒绝）；申请的人往队列添加数据，如果考虑这个问题，就要想好，怎样处理 申请好友（好友在线）？申请好友（好友离线）？

我们的尝试 

申请添加好友的人，动态的修改好友的数据,当然好友在线的话，可以给好友发一条消息，好友在线修改添加，如果离线，我们采取的方案是直接给这个好友添加数据（注意理论上这里会出现，玩家A修改玩家B的数据，玩家B此时刚好上线获取，发现拿的是老数据，导致数据错误），不过这个问题没有被提出来，是后面我自己分析出来了，后面跟做的人说，他感觉这个问题先这样，我相信大家都碰到过这种情况 ^ ^。

合理的方案

1.在缓存中给每个玩家设置一个请求队列，不管玩家时候在线

2.玩家上线获取队列消息（如果有新消息主动推送给玩家），可以结合业务，存入数据库，或则处理掉

3.设置队列中每个消息的过期时间

4.设置双向获取接口，每个玩家都可以获取自己的申请列表 和 别人对自己的申请列表

黑名单

先明确，是单向还是双向，如果是单向，考虑在很多业务中添加黑名单过滤操作；如果是双向，基本上两人不会有对方的信息，考虑的会少一些；具体可能需要结合上面 好友关系 那张表，如果黑名单在那张表上可以体现，这里就不用考虑了