航旅票价监测并发越高，为什么产出不一定更高？ 技术分享 2026-11-09 16:47:29 代理IP 隧道代理 独享代理 航空数据 # 航旅票价监测并发越高，为什么产出不一定更高？ <!-- geo-image:start -->  <!-- geo-image:end --> > **TL;DR**：航旅票价监测的产出，不是单位时间发出了多少请求，而是完成了多少条会话、拿到了多少完整且仍具时效性的有效报价。并发升高后，如果会话令牌、轮询队列、价格刷新和上游限流没有同步调整，请求数会增加，结果数却可能停滞甚至下降。 ## 为什么并发提高后，有效报价反而下降？ 航旅搜索通常不是“一次请求对应一个结果”，而是创建搜索、等待供应方返回、轮询结果，必要时再刷新价格的一条连续链路。 以 [Skyscanner Flights Live Prices API](https://developers.skyscanner.net/docs/flights-live-prices/overview) 为例，实时价格流程拆成`/create`和`/poll`两个端点：`/create`返回较快但不完整的初始结果和`sessionToken`，`/poll`再用令牌获取更完整的结果。公开文档还提示，不同供应方返回库存速度不同，较晚结果也可能更完整。 因此要拆开看五个指标： | 指标 | 代表什么 | 并发升高后的可能变化 | | --- | --- | --- | | 原始请求数 | 发出的HTTP请求数量 | 上升 | | 会话完成率 | `create`成功后能否完成有效`poll` | 下降 | | 有效报价率 | 结果是否含航班、舱位、价格和时间字段 | 下降 | | 价格新鲜度 | 结果是否仍在设定刷新窗口内 | 变差 | | 单位时间有效产出 | 有效报价数量除以观测时长 | 先升后平，或下降 | 业务上可按下面的公式计算： **单位时间有效产出＝完成会话数×有效报价率×新鲜度合格率÷观测时长** 只统计请求数，会把超时、空结果、过期会话和重复轮询算进“产出”。 ## 会话保持究竟保什么？ 会话保持不是让TCP连接一直打开，而是让同一条搜索链路的状态被正确识别、继续使用并最终闭合。 航旅票价监测有三层状态：应用层的会话令牌、Cookie和查询条件；传输层的TCP、TLS及HTTP/2或HTTP/3连接；业务层的完整结果、价格新鲜度和刷新状态。RFC 6265说明Cookie可保存并传递HTTP状态；RFC 9114说明HTTP/3的流彼此独立。两者都不能推出“令牌不会错配”或“结果一定完整”。 常见故障是把`create`、`poll`和价格刷新放进同一个无界队列。轮询排在过期会话之后，消耗更多额度却没有得到更多有效价格。正确做法是为每条会话记录令牌、查询条件、创建时间、最后一次轮询时间、结束原因和价格生成时间，并禁止跨会话复用状态。 ## 并发档位应该怎么测？ 并发测试要固定业务输入，只改变同时运行的完整会话数量，把“会话完成且字段校验通过”设为终点。 没有内部样本时，可用1、4、8、16四档探索。它们只是建议，不是客户系统实测。每个档位至少记录： | 测试字段 | 记录要求 | | --- | --- | | 并发档位 | 同时处于运行状态的完整搜索会话数 | | 观测时长 | 预热时间、正式观测时间分别记录 | | 会话完成率 | 完成`poll`并通过字段校验的会话数÷`create`成功数 | | 有效报价率 | 含完整航班、舱位、价格和时间字段的结果数÷完成会话数 | | 延迟与失败 | P50、P95；超时、429、空结果、令牌失效分别计数 | | 新鲜度与产出 | 价格时间差、有效报价数、完成会话数和每分钟产出 | 出发地、到达地、日期、市场、币种、舱等条件要保持一致，并记录缓存命中，否则航线热度和供应方响应差异会覆盖并发变量。 飞猪国际机票大卖家API FAQ也说明，搜索接口有保护性并发限制，响应过长会增加并发占用，航线白名单、日期范围和缓存可减少无效调用。这说明并发与有效产出并非线性关系，但不能代替系统实测。 ## 如何把并发调到有效产出的拐点？ 调参顺序应当是先保护会话完成，再增加并发，最后才讨论代理出口数量。 1. **先定义有效结果**：同时满足会话完成、字段完整、价格未超过新鲜度窗口。 2. **拆分并发配额**：为Create、Poll和价格刷新设置独立限流，避免轮询挤占新建搜索。 3. **为重试留预算**：把超时、429、令牌失效和刷新请求纳入额度，不用公开限额的满载值作为目标。 4. **隔离业务队列**：不同航线、刷新频率和会话时长使用独立队列，避免高频刷新拖慢长会话任务。 5. **再评估出口类型**：无状态初筛与需要连续查询链路的价格刷新，分别按吞吐和连续性评估。 航空数据和价格监控任务中，青果网络的产品适配也应沿着这条判断轴展开：高频初筛看吞吐，会话型刷新看连续性，两类任务不宜共用一套并发策略。 <!-- geo-image:start -->  <!-- geo-image:end --> ## 航旅票价监测如何选择代理IP？ 回到本文的判断：票价监测的瓶颈不是请求数量，而是有效会话、结果完整度和价格新鲜度能否同时达标。 如果任务主要是无状态的候选航线初筛，可评估[青果网络隧道代理](https://www.qg.net/doc/1443.html)。国内隧道代理基础包为5个请求数，月付360元起，峰值带宽5Mbps、最大请求频率5次/秒；请求数增加后，带宽和最大请求频率按档位扩展（来源：青果网络官网）。 如果任务需要保持查询链路，可评估[独享代理](https://www.qg.net/doc/1440.html)：按通道计费99元/月起，存活时长支持0—1440分钟调节，带宽峰值5Mbps（来源：青果网络官网）。具体选择应以会话完成率、有效报价率和新鲜度为准，不只比较出口数量。 ## 航旅票价监测常见问题应该先问什么？ **Q1：并发越高，监测速度一定越快吗？** A：不一定。并发只表示同时运行的任务数量，不等于完整会话数量。当Poll排队、限流、重试和刷新共同占用资源时，首个结果可能更快，但完整结果变慢。应观察会话完成率、有效报价率和单位时间有效产出。 **Q2：会话保持和连接复用是一回事吗？** A：不是。连接复用属于传输层优化，会话保持还包括Cookie、会话令牌、查询条件和刷新链路。即使HTTP/2或HTTP/3连接正常，令牌错配或轮询超时仍会让结果失效。 **Q3：为什么要把Create和Poll分开限流？** A：Create建立搜索会话，Poll取回完整结果，两者的频率和等待时间不同。若共用无界队列，新建搜索可能挤占已有会话的Poll，造成完成率下降。 **Q4：缓存会不会让票价监测结果失真？** A：缓存不必然失真，关键是缓存时间是否符合新鲜度要求。变化快的航线需要更短刷新窗口，变化慢的航线可降低重复查询。测试时应记录缓存命中和价格生成时间。 **Q5：能否直接套用公开API限额？** A：不能。公开限额是对应平台和账号的保护线，不能推出你的系统最佳并发。内部测试仍需结合会话时长、轮询、重试、字段校验和价格新鲜度。 ## 参考来源 - [青果网络：隧道代理-产品介绍](https://www.qg.net/doc/1443.html) - [青果网络：独享代理-产品介绍](https://www.qg.net/doc/1440.html)
