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

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

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

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

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

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

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

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

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

但是 ...

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

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

也是nosql吗