c++如何应付系统起来时的瞬时并发

客户端指数退避

客户端断开连接后随机一个时间再重连.

@whileFalse 客户端目前无法修改

@lbmjsls1 服务端只有一台？多台可以轮流重启。

客户端无法修改就直接拒绝掉，使用令牌桶

逐渐发出 100 200 300 到 2000 的令牌，抢到令牌的客户端处理，其他拒绝让它重试去

但是最好的架构是客户端收到拒绝后自己 delay 重连

怎么找不到 append 了，我再说一下，客户端目前无法修改，就一台服务器

解决瞬时毛刺的方法就一个套路，排队，也叫 buffer 。
至于这个排队是怎么表现的，就会有各种方法了。
可以专门拉一个进程出来负责连接管理。

@lbmjsls1 队列吧，开个进程专门往队列里喂。然后服务进程一个个地消费这个队列。

如果服务器本身顶得住 2k 的 inbound 连接，那你只需要加个前置处理（代理）批量放行就好了，到处理上限了就 deny，反正客户端会自己再重连。

如果服务器本身扛不住 2k 的 inbound 连接直接就没响应了，那说什么都白搭。

此处服务器代指包括网络规格等等在内的各种 infra 。

可以把 2000 个 TCP 连接接下来，但应用层排队处理，只要不在应用层分配缓冲区、线程什么的，维持 2000 个 TCP 连接应该是没问题的。

=服务器前面挂一个反向代理, 反向代理里限制一下并发数就好了.

服务器设置个最大连接数限制
服务器接受新链接时检查，超过限制则拒绝连接

服务器启动时，慢慢的增加这个值。

考虑应用层做下性能优化吧 ,

iocp 使用到位就已经从架构上最优了，承载几万链接很轻松。
此刻你想问的显然不是同时连接数的问题，而是服务器重启瞬间的，每秒新建连接数问题，你应当换个角度考虑，首先服务器不应当是经常重启的，因此不必太在意刚重启动那一会的故障。
你只是想解决并发创建连接比较慢的问题，这个问题确实是有，但是不是程序要做的，而是你需要通过负载均衡等设备，使用多个服务端来对外表现成无故障
我经历过几万链接单机重启时候恢复慢的场景，重启一次服务器，cpu 爆满，半个小时才能降低下来，最终实现的集群，尽可能逐步后台切换新程序，而不是一下子关闭老程序。当然，方式也有不兼容升级的时候，这时候不得不停机，忍受半个小时的不正常

在用户少的时候重启维护就行了

线程池 /连接池之类，池子满了就等待咯