-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
问题请教 #147
Comments
我理解是用workerpool是防止因为req瞬时过多导致goroutine无限增大导致内存溢出了,至于你说的保证一个connection中req的顺序确实这样也是可以做到的,因为它负载的时候一个conn都给了一个消息队列,但是我觉得他设计的初衷还是前面那个原因 |
我的理解是对于保序这方面zinx并没有提供类似TCP的序列号的机制. |
项目里实现的貌似也不是轮询的方式,是根据ConnectionID % WorkerPoolSize 来确定给哪个Worker,那么相当于同一个ConnID的消息必定会给同一个worker的消息队列,这里他消息队列也是按照管道的结构来组织的是先进先出的,就相当于保证了一个Connection的消息按照发送的顺序来处理。 |
确实,这样同一个连接的所有消息由同一个worker来处理,并且放入worker对应的channel时候,是按序的,所以处理也是按序的。 |
请教个问题,如果不使用workpool每次req都重会开启一个goroutine,这样话连续几个req是无法保证顺序的,使用workpool就不会存在这样的问题,因为所有的req都会被路由到同一个routine当中,对吗?
The text was updated successfully, but these errors were encountered: