实现长连接负载均衡策略

登录成功返回登陆的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

1. UUID（Universally Unique Identifier）：UUID 是一种由网络上的唯一标识符组成的标准化规范，它可以在分布式系统中生成唯一的标识符。然而，UUID 的缺点是它的长度较长（128 位），在存储和索引上占用的空间较大，不适合作为数据库索引或 URL 参数。此外，基于随机数生成的 UUID 在高并发环境下可能会导致性能问题。
2. 自增 ID：自增 ID 是指在数据库中使用自增字段（如 MySQL 中的自增主键）生成唯一标识符。这种方式简单高效，但在分布式系统中存在一些问题。首先，自增 ID 需要依赖数据库自身的自增机制，如果使用多个数据库实例或分库分表，可能会导致 ID 生成的冲突。其次，自增 ID 不适合用于公开的标识符，因为它们可能泄露有关数据库的敏感信息。
3. 雪花算法（Snowflake Algorithm）：雪花算法是一种常用的分布式 ID 生成算法，它可以根据时间戳、机器 ID 和序列号生成唯一的 ID。然而，雪花算法的缺点是它对时钟的依赖性较强，如果系统时钟回拨或不同机器的时钟不同步，可能会导致生成的 ID 不唯一。此外，雪花算法的机器 ID 需要在分布式环境中进行分配和管理，可能需要引入额外的复杂性。