基于NIO的消息路由的实现(三)服务端与客户端结构
基于NIO的消息路由的实现(三)服务端与客户端结构
皮鞋铮亮 发表于3年前
基于NIO的消息路由的实现(三)服务端与客户端结构
  • 发表于 3年前
  • 阅读 195
  • 收藏 8
  • 点赞 1
  • 评论 3

【腾讯云】买域名送云解析+SSL证书+建站!>>>   

摘要: NIO 消息路由 技术结构

一、服务器端结构:

如图所示:

  • 指令类和报文类:对下行的指令和上行的报文进行了类的封装,分别实现IOrder和IPacket接口,继承Order,Packet基类;

  • 服务主线程:接受客户端连接,将客户端发送的报文投递到通讯队列中,发送指令给客户端;保存连接对象(GVConnection)

  • 通讯队列CQ:存储客户端发送过来的报文,此报文由通讯主线程放入;

  • 通讯队列消费者:对通讯队列中的报文进行处理,该做什么做什么,如果是短消息,则放入消息队列MQ中单独处理;

  • 消息队列消费者:对MQ中的短消息进行处理;如果转发的目标客户端没有通道(channel),那么就存入redis。(此部分目前尚未实现)

  • 通道清理线程,针对超时的通道,已关闭的通道进行定期清理;此部分应该有更好地实现方式,请大家帮忙想想吧。

二、客户端结构:


  • 指令和报文类同上;

  • 链路维护线程:每隔一定的时间发送给服务端K报文,用于链路检测,如果超过服务端的连续回应次数超过一定的限制(比如,连续三次没有回应),那么,视为已经掉线;

  • 短线重连线程:两种情况会引发重连:1、服务端主动切断通道;这来是可捕获的;2、异常中断(依靠链路维护);


  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 35
博文 12
码字总数 11603
评论 (3)
xtgss007
如果客户端刚好异常中断,此时,服务端还没有侦测到异常,那么消费者继续消费,此时造就了两个问题:
1、如果继续发送就会产生消息丢失的情况
2、如果保存到介质,在客户端下次连上时再发送,很有可能会重发, 或漏发。因为时间点的问题,不知道客户是什么时候产生异常的。
皮鞋铮亮

引用来自“xtgss007”的评论

如果客户端刚好异常中断,此时,服务端还没有侦测到异常,那么消费者继续消费,此时造就了两个问题:
1、如果继续发送就会产生消息丢失的情况
2、如果保存到介质,在客户端下次连上时再发送,很有可能会重发, 或漏发。因为时间点的问题,不知道客户是什么时候产生异常的。
你说的问题确实存在。 目前我不知道如何捕获客户端异常中断的情况,目前我暂时只能做到这里,不知道有没有更好地方法,请您不吝赐教,万分感激。如果是在业务实现上,针对必要的消息那么应该在收到客户端的回应以后,才能视为消息发送成功。
宅男小何
客户端做一个ack确认,如果服务器端在一段时间内未收到ack,就重发。
可以设置重发次数,如果重发10次,还没收到ack,那就主动放弃。
当然这种模式可能有重复发,但是可以最大化保证消息不丢失。
×
皮鞋铮亮
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: