第3章连接管理

连接管理：长连接与短连接选择、连接池实现、心跳机制与自动重连

说到交易接口的连接管理，我脑子里第一个蹦出来的场景就是：刚入行那年，我写了一个高频策略，结果因为频繁创建和销毁TCP连接，直接把交易所的网关打出了告警。嗯，那会儿我才真正意识到——连接管理不是小事，它直接决定了你的系统能不能稳定跑下去。

这一节，咱们就聊聊连接管理里的三个核心问题：长连接还是短连接？连接池怎么搞？心跳和重连怎么设计？ 说白了，就是让你的交易系统跟交易所之间的“电话线”永远畅通，而且不浪费资源。

1. 长连接 vs 短连接：怎么选？

先问个问题：你每次下单，都要重新建立一次TCP连接吗？

短连接的逻辑很简单——每次请求都新建连接，用完就关。好处是资源释放彻底，坏处嘛……你想想看，一次TCP握手就要1个RTT（往返时间），再加上TLS握手，光建立连接就几十毫秒。对于高频交易来说，这几十毫秒足够行情翻几个来回了。

我个人习惯，交易接口几乎只用长连接。为什么？

延迟低：连接建立好后，后续请求直接走已有通道，省去握手时间。
资源省：频繁创建和销毁socket，对操作系统是负担，尤其是文件描述符。
状态保持：很多交易协议（如FIX）需要会话状态，短连接根本没法做。

核心原则：如果你的交易系统每秒请求超过10次，或者对延迟敏感，请直接上长连接。短连接只适合偶尔查询账户信息这种低频操作。

我在项目中遇到过一家期货公司，他们的API文档写着“建议每次查询都新建连接”。结果我们压测时发现，每秒100次查询，系统直接报“Too many open files”。后来我们改成连接池复用，问题瞬间解决。你看，文档不一定对，你得自己判断。

2. 连接池实现：别让连接“裸奔”

长连接虽好，但你不能只用一个连接。万一这个连接断了，整个系统就瘫痪了。所以我们需要连接池——说白了，就是维护一组长连接，按需分配，用完归还。

连接池的核心参数有哪些？我列个表给你看：

参数	说明	建议值
最小连接数	池中保持的最少连接数	2~4
最大连接数	池中允许的最大连接数	8~16（视交易所限制而定）
空闲超时	连接空闲多久后关闭	60秒
获取超时	从池中获取连接的最大等待时间	500ms

下面是一个简单的连接池实现思路（伪代码）：

class ConnectionPool:
    def __init__(self, min_size, max_size):
        self.min_size = min_size
        self.max_size = max_size
        self.connections = []  # 存放可用连接
        self.in_use = set()    # 正在使用的连接
        self.lock = threading.Lock()
        
        # 初始化最小连接数
        for _ in range(min_size):
            conn = self._create_connection()
            self.connections.append(conn)
    
    def acquire(self, timeout=0.5):
        """获取一个连接"""
        start = time.time()
        while time.time() - start < timeout:
            with self.lock:
                if self.connections:
                    conn = self.connections.pop()
                    self.in_use.add(conn)
                    return conn
                # 如果池不够用，且未达上限，创建新连接
                if len(self.in_use) < self.max_size:
                    conn = self._create_connection()
                    self.in_use.add(conn)
                    return conn
            time.sleep(0.01)
        raise TimeoutError("获取连接超时")
    
    def release(self, conn):
        """归还连接"""
        with self.lock:
            self.in_use.discard(conn)
            # 检查连接是否健康
            if self._is_healthy(conn):
                self.connections.append(conn)
            else:
                conn.close()
                # 补充一个新连接
                self.connections.append(self._create_connection())

避坑指南：我曾经犯过一个错误——连接池里的连接从来不检查健康状态。结果某个连接已经断开了，但池子还把它当成可用连接。策略拿到这个“死连接”后，下单直接超时。所以，每次归还连接时，一定要做一次健康检查（比如发一个ping消息）。

3. 心跳机制：让连接“活着”

长连接最怕什么？怕“假死”。

什么叫假死？就是连接在操作系统层面看起来还开着，但实际上对端已经挂了，或者中间网络设备把连接给掐了。你发数据过去，对方没反应，你只能等超时。这个超时时间，TCP默认可能长达几分钟。

对于交易系统来说，几分钟的等待？那黄花菜都凉了。

所以我们需要心跳机制——定期发送一个轻量级的探测包，确认对方还活着。

心跳的设计要点：

频率：一般3~10秒一次。太快浪费带宽，太慢检测不及时。
内容：尽量轻量。比如FIX协议里的TestRequest消息，或者自定义的一个单字节ping。
超时判定：连续N次心跳无响应，就认为连接已断开。

我习惯的做法是：客户端主动发心跳，服务端回复pong。如果连续3次没有收到pong，就触发重连。

class HeartbeatManager:
    def __init__(self, connection, interval=5, max_retries=3):
        self.conn = connection
        self.interval = interval  # 心跳间隔，单位秒
        self.max_retries = max_retries
        self.fail_count = 0
        self.running = False
    
    def start(self):
        self.running = True
        threading.Thread(target=self._loop, daemon=True).start()
    
    def _loop(self):
        while self.running:
            time.sleep(self.interval)
            try:
                self.conn.send_ping()
                # 等待pong，超时设为2秒
                if not self.conn.wait_pong(timeout=2):
                    self.fail_count += 1
                else:
                    self.fail_count = 0
            except Exception:
                self.fail_count += 1
            
            if self.fail_count >= self.max_retries:
                self._on_heartbeat_failed()
    
    def _on_heartbeat_failed(self):
        """心跳失败，触发重连"""
        print("心跳连续失败，触发重连")
        self.conn.reconnect()

注意：心跳不要和业务请求混在一起。我曾经见过有人用下单请求来充当心跳——结果行情清淡时，心跳间隔拉长到几分钟，连接断了都不知道。心跳应该是独立的、固定频率的探测机制。

4. 自动重连：断了别慌，自己接上

连接断了不可怕，可怕的是断了之后没人管。

自动重连的核心逻辑其实很简单：检测到断开 → 等待一段时间 → 尝试重连 → 成功则恢复，失败则继续等待。

但这里有个坑：重连频率。如果每秒重连一次，交易所那边可能把你的IP拉黑。所以我们需要退避策略。

我常用的退避策略是这样的：

第一次重连：等待1秒
第二次重连：等待2秒
第三次重连：等待4秒
……指数增长，直到最大间隔（比如60秒）
重连成功后，重置退避计数器

下面是一个带退避的重连实现：

class ReconnectManager:
    def __init__(self, connection_factory):
        self.factory = connection_factory
        self.conn = None
        self.backoff = 1  # 初始退避时间
        self.max_backoff = 60
        self.running = True
    
    def start(self):
        self.conn = self.factory.create()
        threading.Thread(target=self._monitor, daemon=True).start()
    
    def _monitor(self):
        while self.running:
            if not self.conn.is_alive():
                print(f"连接断开，{self.backoff}秒后重连...")
                time.sleep(self.backoff)
                try:
                    self.conn = self.factory.create()
                    self.backoff = 1  # 重置退避
                    print("重连成功")
                except Exception as e:
                    print(f"重连失败: {e}")
                    self.backoff = min(self.backoff * 2, self.max_backoff)
            time.sleep(1)  # 每秒检查一次连接状态

个人经验：我曾经在重连逻辑里忘记重置退避计数器，结果系统断连后，重连间隔越来越大，最后变成每60秒才尝试一次。那天的交易记录简直惨不忍睹。所以，重连成功后，一定要把退避时间重置回初始值。

5. 整体架构：一张图看懂

说了这么多，咱们用一张图把连接管理的整体逻辑串起来：

这张图展示了三个模块的协作关系：连接池负责维护一组健康的连接，心跳管理定期检查连接是否存活，自动重连在连接断开后按退避策略尝试恢复。三者形成一个闭环，确保交易系统与交易所之间的通道始终可用。

总结一下

连接管理这件事，说白了就是三个字：稳、快、省。

稳：心跳+重连，保证连接不掉线。
快：长连接+连接池，减少握手延迟。
省：合理配置连接数，不浪费系统资源。

嗯，这一节的内容就到这里。记住，连接管理是交易系统的“地基”，地基不稳，上面的策略再牛也白搭。

📚 课程目录

连接管理：长连接与短连接选择、连接池实现、心跳机制与自动重连

1. 长连接 vs 短连接：怎么选？

2. 连接池实现：别让连接“裸奔”

3. 心跳机制：让连接“活着”

4. 自动重连：断了别慌，自己接上

5. 整体架构：一张图看懂

总结一下