1.线程池多线程,把消息同步给其他端和对方用户,其中数据持久化往往是最浪费时间的操作,可以使用mq异步存储,因为其他业务不需要拿着整条数据,只需要这条数据的id进行操作。
2。消息校验前置,放在tcp层(netty服务中)
tcp协议只能保证数据在传输过程中不丢失,但不能保证到某一端不会丢失,比如传输过程中接收方断网,数据就无法发送到接收方 。
可靠性可以通过消息重发来保证消息一定送到了对方手中。可以通过双重ack确认机制来实现:
A向im服务端发送数据,服务端收到就返回一个ack,A收到这个ack就停止重发,否则就再次尝试重发。当然重发需要设计上限次数的。
然后服务端接到A的数据,再发送给B,B接到之后告诉服务端,返回一个接受到的ack。服务端把收到的再传回给A,此时A确定了此次传输是成功的。中间任何环节出问题,A就执行重发就ok了。
如果B不在线,服务端是可以感知到的,服务端可以代替B向A回复停止重发指令。
因为我们使用多线程保证了消息的实时性,那么就会导致消息有乱序的风险。
解决方案:
使用redis的incr命令实现原子性的递增序列号,但是过度依赖redis可能会因为redis的崩溃而造成系统失效
再im服务端存储每次发过来的消息id(设置过期时间),重复发送的消息id将不再进行持久化但仍会给另一个客户端发送消息。这样就会导致另一个客户端由于网络问题如果没有及时返回ack确认,那么他确实会收到2条相同的消息,但是在去重是完全可以处理的。
qq发消息失败会有红色感叹号,当再次点击重发时是把它当作一条新的消息id发送的,而不是之前的消息id。
在写扩散中,每个人对自己的每条消息都可以直接获取,已读只不过是个字段罢了。
在读扩散中,以群聊为例,可以在群成员表中加入一个字段,该字段表示改成员读到的最后一条消息序列(保证有序性的那个递增序列),在这条消息之前的就表示读过了
IM(即时通讯)系统中的离线消息是指在目标用户不在线或者不可达时,发送方发送的消息无法直接传递给目标用户,而是被服务器暂时存储起来,等到目标用户上线或者可达时再进行投递。
离线消息的存在是为了保证消息的可靠性和完整性。当发送方发送消息时,如果目标用户在线,消息可以直接传递给目标用户;但如果目标用户不在线,服务器会将该消息存储在消息队列或者数据库中,等到目标用户上线后,服务器会将离线消息投递给目标用户。
离线消息通常具有以下特点:
这里的存储使用redis,每人只存1000条,超过就淘汰最早的,使用zset存储,使用消息的递增序列号作为排序标准,zset支持查询范围内指定数量的元素(SMEMBERS命令)。
即使你错过了离线消息的通知和消息盒子,你仍然可以通过滚动查看聊天记录,找到之前的离线消息。
不可能说每次登录都把所有记录都删了重新拉取一遍的,所以这里采用增量拉取。
需要拉取的东西有会话,好友列表,好友申请,为每个需要拉取的数据记录下他的递增序列号,每次只拉取大于记录里最大的序列号。
客户端可以用数据库sqllite
正常情况下,你的上线和下线等状态应该通知给你的所有好友,和你在的所有群里的所有成员,这将是非常恐怖的数据量。
改进1:只推给在线用户
改进2:
计数限制:为每个用户设置一个计数器,记录他们发送给陌生人的消息数量。当陌生人发送消息时,系统会检查计数器的值。如果计数器小于等于三,允许发送消息并将计数器加一;如果计数器大于三,拒绝发送消息。
时间限制:除了计数限制,可以设置一个时间限制,例如每小时或每天只允许陌生人发送三条消息。系统会记录陌生人发送消息的时间,并在规定的时间段内检查发送数量。如果超过限制,拒绝发送消息。