如何维持SMPP 3.4连接活跃 避免批量短信发送超时

你遇到的发数百条就触发超时断连的核心原因是SMPP滑动窗口占满导致心跳无法正常收发，叠加配置余量不足、发送无流控导致的，可按以下步骤逐一落地调整：

核心配置修正 #

你当前的心跳配置冗余量严重不足，批量发送场景下很容易误判断连，同时必须显式配置滑动窗口大小，参考初始化配置：

conn, err := smpp.Dial(ctx, smpp.Addr(esmeAddr),
    // 滑动窗口大小：和运营商确认在途消息上限，无文档先设为100，压测后逐步调优
    smpp.WindowSize(100),
    // 心跳间隔调整为60s，超时留10s余量，不要卡2s的临界值
    smpp.EnquireLink(60*time.Second),
    smpp.EnquireLinkTimeout(10*time.Second),
    // 单条提交请求超时设为30s，避免偶发网络抖动直接触发全局超时
    smpp.SubmitTimeout(30*time.Second),
)

发送流程改造 #

• 严格做发送流控：不要用无间隔循环直接调用Submit接口提交全量消息，用令牌桶算法控制发送QPS，普通短信通道先按100QPS设置，根据运营商返回的限速错误码动态调整，避免瞬间流量打满连接缓冲区。
• 不要让在途消息数超过窗口值：用带缓冲的channel做发送队列，每收到一条SubmitResp成功响应，再从队列取下一条消息提交，保证任意时刻未收到响应的在途消息数不超过WindowSize设置值——旧版本go-smpp的心跳请求不会抢占发送优先级，窗口被业务消息占满后心跳包根本发不出去，直接触发你设置的EnquireLinkTimeout断连。
• 回调逻辑非阻塞：所有SubmitResp、DeliverSM的回调函数里不能放同步写库、调用第三方接口这类耗时操作，耗时逻辑必须丢到独立的异步goroutine处理，否则会阻塞连接的接收协程，导致所有响应无法被读取，直接触发超时。

可靠性兜底逻辑 #

• 做消息状态持久化：所有待发短信提前入库，标记待发送、发送中、发送成功、发送失败四个状态，消息提交后标记为发送中，收到成功响应标记为成功，超时未收到响应标记为待发送重试。
• 自动重连续传：监听连接的断开事件，一旦连接异常关闭自动触发重连，重连成功后从数据库捞取所有待发送、发送中超时的消息继续发送，不要依赖单条连接跑完整个批量任务。

按以上配置调整后，先跑1000条量级的压测，观察心跳响应时延、在途消息数、错误率，稳定后再放大到5000条及以上的批量任务，不会再出现发送数百条就中断的问题。

内容的提问来源于stack exchange，提问作者jucan