实现长连接负载均衡策略
登录成功返回登陆的im地址。
1.在公共模块里写个RouteHandle接口，然后他的实现类去实现不同的均衡策略。
2.在业务模块的config文件下的beanConfig中定义一个@Bean routeHandle，从配置文件中获取不同的负载均衡策略来初始化RouteHandle。
3.在登录业务里调用方法
一致性哈希解决方案：
1。先说流程，
用treemap存储ip对应的hash值作为value，ip作为值，然后根据自己的信息在map中定位，找到自己对应的ip
2.细节：
1.节点数过少可能会导致hash分布不均，所以可以添加一些虚拟节点来解决，就是多个hash对应同一个ip，具体可以通过原ip+随机数的方式来获取多个不同hash值。
2.这个treemap集合里面的值可能会随着节点数变化，所以每次调用这个方法的时候要先清一下这个map，防止访问到无效节点。并且在方法上加上synchronized确保方法的原子性。
3.对于一致性哈希的解决方案不一定只能用treemap实现，并且需要可以扩展比如排序方法，添加方法，获取节点方法。所以这里使用抽象类实现。在这个抽象类中，add，sort，getFirstNodeValue，processBefore，均可以作为抽象方法交给子类实现，而主方法和hash方法可以直接在抽象类中直接实现。
im回调业务系统回调
腾讯云给出的流程图很清楚了
从功能角度来看，回调可以分为四大类：
1在线状态回调
2资料关系链回调
3单聊消息回调
4群组系统回调
从处理角度来看，回调可以分为以下两大类：
1事件发生之前回调：回调的主要目的在于让 App 后台可以干预该事件的处理逻辑，即时通信 IM 会根据回调返回码确定后续处理流程（例如发送群消息之前回调）。
2事件发生之后通知：回调的主要目的在于让 App 后台实现必要的数据同步，即时通信 IM 忽略回调返回码（例如群组成员退群之后通知）。
数据多端同步
比如微信的手机端和电脑端，存在数据同步问题。有以下解决方案：
1.定时轮询拉取，缺点：数据基本是不变的，不停的拉取会造成很多的网络资源浪费。
2.通过回调，缺点：增加了业务服务端与im服务端之间的交互，并且数据同步过度依赖业务服务器。
3.tcp通知
接口鉴权加密
使用hmacsha256可逆加密
消息分发流程
聊天记录的存储和读取
读扩散，写扩散。
用户之间的聊天记录，已读未读，使用写扩散。
使用写扩散可以把索引和数据分开来，聊天内容只存一份，而发送人id，接收人id和消息所属人id可以写多份
群消息使用读扩散。
消息分布式id
- UUID（Universally Unique Identifier）：UUID 是一种由网络上的唯一标识符组成的标准化规范，它可以在分布式系统中生成唯一的标识符。然而，UUID 的缺点是它的长度较长（128 位），在存储和索引上占用的空间较大，不适合作为数据库索引或 URL 参数。此外，基于随机数生成的 UUID 在高并发环境下可能会导致性能问题。
- 自增 ID：自增 ID 是指在数据库中使用自增字段（如 MySQL 中的自增主键）生成唯一标识符。这种方式简单高效，但在分布式系统中存在一些问题。首先，自增 ID 需要依赖数据库自身的自增机制，如果使用多个数据库实例或分库分表，可能会导致 ID 生成的冲突。其次，自增 ID 不适合用于公开的标识符，因为它们可能泄露有关数据库的敏感信息。
- 雪花算法（Snowflake Algorithm）：雪花算法是一种常用的分布式 ID 生成算法，它可以根据时间戳、机器 ID 和序列号生成唯一的 ID。然而，雪花算法的缺点是它对时钟的依赖性较强，如果系统时钟回拨或不同机器的时钟不同步，可能会导致生成的 ID 不唯一。此外，雪花算法的机器 ID 需要在分布式环境中进行分配和管理，可能需要引入额外的复杂性。
