Muduo 网络编程示例之六：限制服务器的最大并发连接数

偏执的太偏执、 2022-09-30 06:26 201阅读 0赞

陈硕 (giantchen\_AT\_gmail)

Blog.csdn.net/Solstice [t.sina.com.cn/giantchen][t.sina.com.cn_giantchen]

这是《[Muduo 网络编程示例][Muduo]》系列的第六篇文章。

Muduo 全系列文章列表： [http://blog.csdn.net/Solstice/category/779646.aspx][http_blog.csdn.net_Solstice_category_779646.aspx]

本文已以大家都熟悉的 EchoServer 介绍如何限制服务器的并发连接数。

本文的代码见 [http://code.google.com/p/muduo/source/browse/trunk/examples/maxconnection/  
][http_code.google.com_p_muduo_source_browse_trunk_examples_maxconnection_]

《Muduo 网络编程示例 系列》计划中的第六篇文章原本是“用于测试两台机器的带宽的 pingpong 程序”，pingpong 协议的程序已经在《[muduo 与 boost asio 吞吐量对比][muduo _ boost asio]》和《[muduo 与 libevent2 吞吐量对比][muduo _ libevent2]》两篇文章中介绍过了，所以我改为写另外一个有点意思的主题。

这篇文章中的“并发连接数”是指一个 server program 能同时支持的客户端连接数，连接系由客户端主动发起，服务端被动接受(accept)连接。（如果要限制应用程序主动发起的连接，则问题要简单得多，毕竟主动权和决定权都在程序本身。）

# 为什么要限制并发连接数？ #

一方面，我们不希望服务程序超载，另一方面，更因为 file descriptor 是稀缺资源，如果出现 file descriptor 耗尽，很棘手（跟 “malloc 失败/new() 抛出 std::bad\_alloc”差不多同样棘手）。

我在《[分布式系统的工程化开发方法][Link 1]》一文中曾谈到 libev 作者建议的一种[应对“accept()ing 时 file descriptor 耗尽”][accept_ing _ file descriptor]的办法。

![幻灯片35][35]

![幻灯片36][36]

Muduo 的 acceptor 正是这么实现的，但是，这个做法在多线程下不能保证正确，会有 race condition。（思考题：是什么 race condition？）

其实有另外一种比较简单的办法：file descriptor 是 hard limit，我们可以自己设一个稍低一点的 soft limit，如果超过 soft limit 就主动关闭新连接，这样就避免触及“file descriptor 耗尽”这种边界条件。比方说当前进程的 max file descriptor 是 1024，那么我们可以在连接数达到 1000 的时候进入“拒绝新连接”状态，这样留给我们足够的腾挪空间。

# Muduo 中限制并发连接数 #

Muduo 中限制并发连接数的做法简单得出奇。以在《[Muduo 网络编程示例之零：前言][Muduo]》中出场过的 EchoServer 为例，只需要为它增加一个 int 成员，表示当前的活动连接数。（如果是多线程程序，应该用 muduo::AtomicInt32。）

class EchoServer
    {
     public:
      EchoServer(muduo::net::EventLoop* loop,
                 const muduo::net::InetAddress& listenAddr,
                 int maxConnections);
    
      void start();
    
     private:
      void onConnection(const muduo::net::TcpConnectionPtr& conn);
    
      void onMessage(const muduo::net::TcpConnectionPtr& conn,
                     muduo::net::Buffer* buf,
                     muduo::Timestamp time);
    
      muduo::net::EventLoop* loop_;
      muduo::net::TcpServer server_;
      int numConnected_; // should be atomic_int
      const int kMaxConnections;
    };

然后，在 EchoServer::onConnection() 中判断当前活动连接数，如果超过最大允许数，则踢掉连接。

void EchoServer::onConnection(const TcpConnectionPtr& conn)
    {
      LOG_INFO << "EchoServer - " << conn->peerAddress().toHostPort() << " -> "
        << conn->localAddress().toHostPort() << " is "
        << (conn->connected() ? "UP" : "DOWN");
    
      if (conn->connected())
      {
        ++numConnected_;
        if (numConnected_ > kMaxConnections)
        {
          conn->shutdown();
        }
      }
      else
      {
        --numConnected_;
      }
      LOG_INFO << "numConnected = " << numConnected_;
    }

这种做法可以积极地防止耗尽 file descriptor。

另外，如果是有业务逻辑的服务，可以在 shutdown() 之前发送一个简单的响应，表明本服务程序的负载能力已经饱和，提示客户端尝试下一个可用的 server（当然，下一个可用的 server 地址不一定要在这个响应里给出，客户端可以自己去 name service 查询），这样方便客户端快速 failover。

后文将介绍如何处理空闲连接的超时：如果一个连接长时间（若干秒）没有输入数据，则踢掉此连接。办法有很多种，我用 Time Wheel 解决。

[t.sina.com.cn_giantchen]: http://t.sina.com.cn/giantchen
[Muduo]: http://blog.csdn.net/Solstice/archive/2011/02/02/6171831.aspx
[http_blog.csdn.net_Solstice_category_779646.aspx]: http://blog.csdn.net/Solstice/category/779646.aspx
[http_code.google.com_p_muduo_source_browse_trunk_examples_maxconnection_]: http://code.google.com/p/muduo/source/browse/trunk/examples/maxconnection/
[muduo _ boost asio]: http://blog.csdn.net/Solstice/archive/2010/09/04/5863411.aspx
[muduo _ libevent2]: http://blog.csdn.net/Solstice/archive/2010/09/05/5864889.aspx
[Link 1]: http://blog.csdn.net/Solstice/archive/2010/10/19/5950190.aspx
[accept_ing _ file descriptor]: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#The_special_problem_of_accept_ing_wh
[35]: /images/20220708/e1de78ab0517456f9a0c95593e2af870.png
[36]: /images/20220708/e3cf7b6a5eb1424ab717391627ebe737.png