1 痛点
2 方案选型
2.1 轮询拉取
每个客户端定时轮询服务端，请求好友列表。
缺点
- 对移动端耗电、耗流量
- 对服务端也是较大的资源浪费
因为好友数据其实是不会频繁变化的，导致每次拉去的数据可能都是一样的。
2.2 业务回调
业务服务可以知道谁加了谁的，即可调用 IM 服务通知客户端拉取。
缺点
业务服务端和 IM 服务端需新增交互逻辑。
数据同步强依赖于业务服务端，若回调过程任一节点失败，依旧无法同步通讯录。
而且客户端通过 SDK 去拉取好友，还是全量拉取，若只是为一个好友数变化而全量。
2.3 TCP 通知
在 IM Server 收到加好友请求后且处理成功过后，IM Server 再主动发送特定指令及对应变化的好友信息给到其它设备端。
优点
- 避免空轮询
- 避免了强依赖于业务系统
