目的
为了保证客户端的请求是顺序发送到服务端的。
实现方法(初版)
ctx.writeAndFlush被包装在用synchronized修饰的send方法中,客户端统一调用sendRequest方法。

有多个线程使用sendRequest方法
1.eventLoop处理channelRead的结果,并调用sendRequest发送到服务端。
2.业务线程(如心跳线程,http请求对应的线程)去调用ctx.writeAndFlush

造成的后果
从客户端看日志是顺序的,但是服务端总是收到非连续的请求。
代码
服务端
检测客户端的请求cmdCnt,如果小于当前服务端的值,那么就认为是过期的命令

客户端
同步的sendRequest方法,保证不同线程都是顺序执行,cmdCnt顺序增长。
除了EventLoop线程,业务线程也会调用到sendRequest

EventLoop线程执行sendRequest

EventLoop处理任务流程

原因
这是EventLoop的一个特性:【非EventLoop线程A】调用ctx.writeAndFlush时,不会直接执行,而是放入taskQueue队列中(等待之后eventLoop线程去执行)。
当【非EventLoop线程A】执行同步的sendRequest并调用ctx.writeAndFlush的同时。 EventLoop线程此时如果正“忙”,也调用到sendRequest,但被synchronized阻塞了。 一旦 A线程将本次发送的内容打包为taskB到taskQueue(EventLoop->SingleThreadEventExecutor里面的taskQueue)。那EventLoop会在A线程offerTask完成,并释放synchronized对应的对象锁后。先执行本次sendRequest从taskQueue取出
代码请求流程
由于EventLoop即处理了channelRead(读) 以及后面的sendRequest(业务操作),
又处理writeAndFlush(写)。


解决方法
全部改为非业务线程去执行同步的sendRequest方法,去执行ctx.writeAndFlush,最终都提交给队列。那么顺序提交到队列,就顺序取出发送到服务端。避免了EventLoop线程直接执行writeAndFlush。
解决问题的代码
注意,内部的sendRequest才是同步方法。

本文探讨了在Netty框架中,多线程环境下客户端如何保证请求顺序发送到服务端的问题。通过分析EventLoop线程特性和sendRequest方法的同步控制,揭示了非连续请求的成因,并提出了解决方案,即将所有业务线程的请求统一提交至队列,确保按序执行。
379

被折叠的 条评论
为什么被折叠?



