求教IM好友关系在服务端的存储、检查等设计思路问题

如果好友关系是相互关系的 ，比如 A和B是相互好友关系， 则表存  A --B ， B--A   相当有两条， 1、每次发信息都要鉴定对方是不是你的好友，这个搜索肯定有耗时， 2、如果有1万个用户， 每个用户100个好友， 则表就存储了  10000*100*2 = 200万条数据,  只是举个例子，如何解决这两个问题？

这种好友关系的存储，确实一旦用户量上去，好友量也有了，数据行数会很大，但说实话，这样的设计对于查询是很友好的，而好友关系主要就是用在查询上，所以用空间换时间也值得。
另外，每次发消息都要检查是不是好友，其实不是太必要，因为无论服务端作什么动作（用redis或什么缓存类似的方案）肯定会有性能损耗，而且im这种本来说讲究高并发、高吞吐的场景，这样的性能损失在这么大量的并发下，是很夸张的。其实，如果好友关系这种情况，如果没有特别的检查必要，对于每条消息的传递来说，可以在服务端省掉或想办法不去每条消息都检查，直接发给客户端，让客户端自已决定，如果不是好友到底是扔掉还是怎么处理，这其实没太多的危害。

引用：JackJiang 发表于 2021-11-25 21:49
这种好友关系的存储，确实一旦用户量上去，好友量也有了，数据行数会很大，但说实话，这样的设计对于查询是 ...

比如我是A 对方是B ， B删除了我， 我的客户端是显示了B还是我的好友，但是客户端没有办法验证对方是否删除了我，我发条信息给B， 在服务器拦截的时候，如果不是好友直接 返回 不是好友的标记了， 这样一方面我的客户端展示了 它不是我的好友，二：在服务器拦截可以减少了不必要的消息转发（节约流量），发现很多即时聊天软件都有这个“拒收消息/不是好友” 等功能， 是不是也要这样做呢？

引用：ayuan9900 发表于 2021-11-25 21:55
比如我是A 对方是B ， B删除了我， 我的客户端是显示了B还是我的好友，但是客户端没有办法验证对方是否删 ...

一、从产品的角度来说，你没必要纠结这个，你没办法知道对方删除没关系，你大胆发就好了，反正对方在收到时会判断你不在好友列表里，要么扔掉，要么可以做为陌生人显示。你可能会说，要是一直发怎么办，这个问题太愚蠢了，要是一直发，对方不回应，你不可能像个神精一样不停的嘛，聊天就是说话，别人不应，你不可能不闭嘴的对吧。

而且，一旦你这边断线重连或得新登陆时，就能刷新到最新好友列表数据，下次就不会这样了呀。

二、跟你服务务端严格检查需要损去的性能和架构复杂性来说，多传和少传这几条消息根本没什么损失，何况Im服务端最擅长的就是高吞吐高并发。

做im的时候，不能死盯着技术，有时候要站在产品的角度考虑问题，否则真要纠结起来，那真没什么是好做的事了。何况，im里本来就有“万有一失”这个设计原则，聊天不是金融数据，偶尔出点小差错，是能容忍的。

引用：JackJiang 发表于 2021-11-26 11:19
一、从产品的角度来说，你没必要纠结这个，你没办法知道对方删除没关系，你大胆发就好了，反正对方在收到 ...

还有一个问题， 好友相互关系问题表设计，  A---B    B---A  ， 这两条数据都存在同一个表吗？

引用：ayuan9900 发表于 2021-11-26 15:05
还有一个问题， 好友相互关系问题表设计，  A---B    B---A  ， 这两条数据都存在同一个表吗？

对的，怎么方便怎么来，别想那么多

一般来说都是 MySQL + Redis，Redis 存最热的前N个好友关系做cache；大型IM必不可免需要拆库拆表；

但是对于我司来说，我们有图数据库呀，既能满足持久化存储，又能快速高效查找二元关系，简直不要太香哦

引用：wangjil_BI85P 发表于 2021-12-01 09:01
一般来说都是 MySQL + Redis，Redis 存最热的前N个好友关系做cache；大型IM必不可免需要拆库拆表；

但是 ...

“图数据库”？有具体的方案吗，我学习一下

引用：JackJiang 发表于 2021-12-01 11:08
“图数据库”？有具体的方案吗，我学习一下

开源的有 neo4j ，其他大厂基本上都有自造的轮子

引用：wangjil_BI85P 发表于 2021-12-01 12:32
开源的有 neo4j ，其他大厂基本上都有自造的轮子

也是nosql吗