假设使用4个subreacrtor，来了1000个连接，每个subreactor有250个连接，其中3个reactor上的连接都被关闭了，此时需要考虑均衡的问题吗？如果需要的话，该怎么均衡呢？

[CHENCHAO0526]

GitHub issues are for tracking bugs, not for general discussing like a forum.

If you have a general question to ask, send it to mailing list:

muduo-library@googlegroups.com

Or visit: https://groups.google.com/forum/#!forum/muduo-library

When file an issue muduo, please provide a SSCCE: Short, Self Contained, Correct (Compilable), Example.

If you can't compile muduo, make sure you install cmake and boost from the official package repository, e.g. apt or yum, before opening a bug. Don't open a bug if you installed boost from a third-party source or downloaded it by yourself, and couldn't compile muduo, thank you.

Also specify the exact environment where the issue occurs:

Linux distro and version? x86 or ARM? 32-bit or 64-bit?

Branch (cpp98/cpp11/cpp17) and version of muduo?

Version of cmake, gcc and boost? (If not from distro.)

[chenshuo]

首先，这是一个非常好的问题。

我在设计 Muduo 的时候思考过这个问题，得出的结论是无论是长连接服务还是短连接服务都不必特意去处理这种极端情况。

首先，如果这 1000 个连接来自 1000 个独立的客户端，那么要造成这种极端不平衡的情况需要精确控制（同步）这 1000 个客户端的行为顺序。在实际条件下，如果不是刻意为之，这种情况很难发生，就好比 hash table 的 keys 都落在同一个 bucket 那么少见。

对于短连接的服务，即便发生了 250 个连接全都碰巧落入同一个 subreactor 的情况，那么随着新的连接的到来和旧的250个连接的断开，这种失衡的情况也不会持续太久。假设每秒钟有 10 个新连接到来，每个连接平均生命期是 100 秒，这样服务端平均有 1000 个并发连接。大约 2 分钟（100 多秒）以后，现有的连接就会全部断开，新的连接会重新平均分布在 4 个 reactor 上。

对于长连接的服务，一开始来了 1000 个连接，每个 subreactor 分配了 250 个，服务器能够正常处理请求，说明 250 个连接不会造成一个 subreactor 过载。那即便另外 3 个 subreactor 都空闲下来，这一个活跃的 subreactor 也能正常应付其承载的 250 个连接，那重新把连接分配到另外 3 个空闲的 subreactor 上似乎也没有多大的必要。

如果要重新把 250 个连接分配到 4 个 subreactor 上，会破坏 Muduo 的一个根本假设：每个连接上的 IO 操作（回调）从始至终只会发生在某个固定的 IO 线程。一旦这个假设被打破，那么程序写起来要考虑问题就多多了，得不偿失。