问题请教

[wakeupzhao]

请教个问题,如果不使用workpool每次req都重会开启一个goroutine,这样话连续几个req是无法保证顺序的,使用workpool就不会存在这样的问题,因为所有的req都会被路由到同一个routine当中，对吗？

[chenz1hao]

我理解是用workerpool是防止因为req瞬时过多导致goroutine无限增大导致内存溢出了，至于你说的保证一个connection中req的顺序确实这样也是可以做到的，因为它负载的时候一个conn都给了一个消息队列，但是我觉得他设计的初衷还是前面那个原因

[AlespRless]

我的理解是对于保序这方面zinx并没有提供类似TCP的序列号的机制. 而开启了工作池以后,采取的是轮询的方式,而每个worker是独立的goroutine,因此处理顺序实际上也不是按照req发送的顺序来的.
所以无论是开不开启工作池,处理req的顺序都不固定.

[chenz1hao]

我的理解是对于保序这方面zinx并没有提供类似TCP的序列号的机制. 而开启了工作池以后,采取的是轮询的方式,而每个worker是独立的goroutine,因此处理顺序实际上也不是按照req发送的顺序来的. 所以无论是开不开启工作池,处理req的顺序都不固定.

项目里实现的貌似也不是轮询的方式，是根据ConnectionID % WorkerPoolSize 来确定给哪个Worker，那么相当于同一个ConnID的消息必定会给同一个worker的消息队列，这里他消息队列也是按照管道的结构来组织的是先进先出的，就相当于保证了一个Connection的消息按照发送的顺序来处理。

[lim-yoona]

我的理解是对于保序这方面zinx并没有提供类似TCP的序列号的机制. 而开启了工作池以后,采取的是轮询的方式,而每个worker是独立的goroutine,因此处理顺序实际上也不是按照req发送的顺序来的. 所以无论是开不开启工作池,处理req的顺序都不固定.

项目里实现的貌似也不是轮询的方式，是根据ConnectionID % WorkerPoolSize 来确定给哪个Worker，那么相当于同一个ConnID的消息必定会给同一个worker的消息队列，这里他消息队列也是按照管道的结构来组织的是先进先出的，就相当于保证了一个Connection的消息按照发送的顺序来处理。

确实，这样同一个连接的所有消息由同一个worker来处理，并且放入worker对应的channel时候，是按序的，所以处理也是按序的。