1. 评审现场还原：这是个什么系统，为什么要评审
前阵子团队内部做了一次高并发采集系统的架构设计评审，我作为负责核心链路的开发者，把整轮评审过程完整复盘一遍。这次评审不是在会议室里轮流念PPT，而是把设计稿、压测数据、流量预估摊开在桌面上，逐条过质疑。这种方式的收获是文档里学不到的。
先说业务背景。系统要支撑的业务方在做一个多源信息聚合项目，需要从互联网公开渠道持续采集商品信息、资讯内容、公开价格数据等，数据量级不是几千条，而是每天数千万条增量。采集源覆盖数百个不同的数据站点，每个站点的接口形态、频率限制、返回结构各不相同。业务方给的目标很朴素：稳定跑，别崩，数据别丢，上游峰值来了扛得住。
最初团队的演进路径是：脚本定时抓取 -> 单机多线程采集 -> 分布式任务拆分+消息队列缓冲。这次评审的标的，就是第三阶段的设计方案。但真正推进时，我意识到高并发采集系统和其他后端系统的最大差异在于：它不只是一套请求处理框架，而是一个集调度、抓取、解析、清洗、存储、监控于一体的数据管道。
为什么要专门做评审？因为踩过太多次坑。上一版单机方案在流量高峰期出现过任务积压、数据库连接被占满、目标站点超时重试形成恶性循环。这些教训告诉我们，设计稿阶段多花三天讨论，比上线后花三周救火划算得多。
评审的讨论范围我提前框定在五条核心主线上：
- 任务调度层：数千万URL如何拆分、分配、重试
- 抓取执行层：并发模型怎么选，连接怎么复用
- 消息缓冲与削峰：引入中间件到底解决什么问题
- 数据链路完整性：如何保证不重、不漏、不阻塞
- 监控与快速定位手段：出问题时怎么快速找到病灶
下面按评审当天的讨论顺序逐块复盘，包括现场提出的问题、我们给出的理由、以及哪些设计后来走了弯路。
2. 需求拆解与流量预估：先算清楚一小时要扛多少
评审的第一个环节不是画架构图，而是重新核算需求数字。很多设计失败，根源在于连自己要处理多大流量都没算对。这个环节我坚持让团队所有人动手算一遍，不允许只看别人给出的结论。
2.1 从日增量反推峰值QPS
业务方给的目标很粗：日新增目标数据量是2000万条左右。但采集任务不等于数据条数，一个页面可能包含几十条数据，一次详情页请求只能拿到一条商品信息。所以实际的任务量需要先放大若干倍。
我要求把链路拆为三层分别估算：
- 列表页/索引页请求：用于发现新链接，假设每日需要遍历50万个列表页
- 详情页请求：假设每日需要抓取800万个详情页（考虑增量去重后）
- 特殊接口调用：比如搜索接口、翻页接口，每日约200万次
三层相加，日请求总量约1050万次。一天按10小时有效抓取时间计算（需要预留低峰时段给数据源喘息），平均QPS大约是300。但采集系统最怕的不是平均，而是峰值。评审现场我直接抛出一个问题：如果上游数据源集中放量，或者业务方临时加急任务，瞬时QPS到多少会压垮现有设计？
我们根据历史数据波动规律，取平均值的5倍作为设计目标，也就是峰值QPS按1500来定。这个数字不算激进，但已经足够暴露很多设计问题——比如单机线程池模型在这个量级下必然会出现线程频繁切换和超时堆积。
2.2 带宽与存储成本也要算进架构里
详情页平均大小按300KB估算，800万详情页一天就是2.4TB原始下载量。如果全部落盘保留，一个月就是72TB。这个量级直接否掉了单机加本地磁盘的方案，也让“先存原始HTML再慢慢解析”的策略显得不再理所当然——你不可能无限存下去。
所以评审中大家达成的共识是：原始响应不长期保留，只保留结构化字段和必要的元信息，原始页面的本地缓存设置过期时间（保留7天后自动清理）。带宽方面，按峰值1500 QPS、平均300KB响应计算，瞬时带宽需求约为432MB/s。这是一个很现实的上限约束：即时应用层能扛住，带宽也可能成为瓶颈。所以设计上加了一层gzip压缩传输和字段裁剪接口，目的就是省流量。
2.3 需求拆解后浮现的三个关键问题
数字摆出来后，设计稿中的问题立刻暴露出来。
第一，原设计想对所有数据源用同一套抓取参数，完全不现实。有的源允许每秒5个请求，有的源每秒0.5个请求都危险。必须按数据源维度做隔离和差异化配置。
第二，日增量2000万条写入数据库，单表直接写是撑不住的。设计稿里没有说明分库分表方案或写路径优化，评审中补上了按来源和日期双维度分表的结构设计。
第三，原设计用固定频率轮询所有URL，忽略了“数据源更新时间规律不同”这件事。有的源每小时更新一次，有的每日凌晨更新，统一轮询会浪费大量请求配额。后来在调度层加入了按源分类的更新周期配置，这项改动带来的请求量下降接近30%。
3. 任务调度与抓取执行：并发不是越高越好
评审讨论最久的就是调度层和执行层的设计。这也是采集系统架构里最容易出问题的地方，我见过不少系统把调度做成简单的“一堆线程去拉URL”，拉完就扔下一条，毫无状态管理可言。
3.1 分布式调度：把URL变成可跟踪的任务
我们的任务来源大致有三类：初始导入的历史URL、新发现页面的URL、定时重抓的旧URL。如果设计稿里只写“从数据库取URL分配给worker”，评审一定不会通过。因为这样的方案完全无法回答几个问题:哪些URL抓过了？哪些失败了？哪些在重试队列里？哪些源在限流中？
评审确定的最终方案是引入任务状态机，每个URL请求封装为采集任务，状态流转为：待调度 -> 已分配 -> 抓取中 -> 成功/失败/重试待定。任务状态保存在缓存中，加上数据库持久化，调度器每轮扫描待调度任务并批量分发。
任务拆分粒度上，我们不按URL一条条分，而是按“批次”分：每个批次包含同一数据源下的一组URL，批次内串行，批次间并发。这个设计的理由很简单：同一数据源需要受同一个限流器的控制，如果把URL散到不同worker上，无法做精确的源级限流。批次大小按源的平均响应速度和单次请求耗时配置，快的源批次放大到100条，慢的源批次缩到10条。
3.2 抓取执行层的并发模型选择
评审现场对并发模型做了两轮激烈讨论。第一版设计是用线程池，每worker固定开200个线程，线程里跑阻塞式HTTP请求。这个方案在平均QPS 300时问题不大，但到了1500峰值就会出现明显的线程颠簸：大量线程阻塞在等待响应，CPU没跑满但线程数爆了，切换开销巨大。
第二版设计是用异步非阻塞模型，基于事件循环和连接池复用。对比测试的数据是：同样单机配置，线程池方案稳定支撑约200 QPS，异步方案可以支撑800 QPS以上，且CPU占用更低。最终评审选择的方案是异步非阻塞为主体，对少数不支持长连接的源保留线程池兼容。
我在这里想提醒一点。选异步模型不等于代码更复杂就一定是好事，采集系统的耗时大头在网络IO和解析，不是CPU计算。所以异步改造的收益高，但前提是必须引入带超时控制的连接池，否则一个连接卡死会把事件循环拖垮。
3.3 抓取执行层的八项注意清单
评审过程中我们整理了一份执行层的设计检查清单，这里完整分享给要做类似系统的读者：
- 每个数据源一个独立的限流计数器，不允许全局共享限流
- HTTP客户端必须配置连接超时、读取超时、总超时三项，缺一不可
- 连接池大小不能超过源允许的并发上限，否则池形同虚设
- 重试逻辑必须退避，禁止失败后立即重试，防止重试风暴
- 响应内容必须做大小上限限制，防止异常大响应拖垮内存
- 请求头尽量伪装成正常浏览器形态，动态生成User-Agent
- 同一数据源的请求间隔必须恒定，随机抖动取正负20%
- 每次请求必须带上业务追踪ID，便于回调日志排查
第6条是经验之谈。很多新手设计的采集系统，一眼就被数据源识别为机器流量，因为所有请求的User-Agent一模一样，甚至还有明显的Python默认头。虽然不是做恶意对抗，但基本的风控意识还是要有的。
3.4 任务分配策略的坑：什么是“有状态调度”
评审中最容易被忽视的一个点是调度器本身的状态。如果调度器是无状态的，任务就无法感知worker的实时负载，分配出去的请求可能会集中打在已经过载的worker上。
我们最终采用了带权重的一致性分配策略：每个worker在启动时注册自身信息，定时上报当前队列深度和延迟指标，调度器根据这些指标动态调整分配权重。这个设计避免了早期版本中“任务都堆在一个worker上，其他worker空转”的尴尬局面。
另一个偷懒不得的地方是任务的优先级。业务方偶尔会提交加急采集任务，这类任务的URL必须比定时任务优先处理。调度器需要额外支持优先级标签，调度时优先扫描高优先级队列。这个功能虽然简单，但评审前没有设计进去，差点漏掉。
4. 消息缓冲与削峰：什么时候真正需要队列
评审初期设计稿里就写了要引入消息队列，理由是“高并发必须用队列”。我当场否了这个理由——不能因为大家都在用队列，就机械地把队列塞进系统里。先必须明确：这里用队列到底要解决什么问题。
4.1 削峰填谷还是解耦，得先说清楚
采集系统的核心链路是：调度器发任务 -> worker抓取 -> 解析 -> 写入存储。如果目标源返回速度平稳，完全可以不用队列，worker直连写入即可。但现实是数据源响应时间波动很大，有的源高峰期会突然变慢，下游写入如果跟着波动就会打满数据库连接。
队列在这里的核心作用有两个。第一，把解析后的数据结构化消息暂存，下游消费者按自己的节奏入库，避免数据库被瞬时写流量冲垮。第二，把抓取和解析解耦，抓取层不需要等解析完成才能继续抓下一个任务，两者并行推进，整体吞吐量能提升40%以上。
评审结论是：队列必须用在解析后到入库之间的链路，而不是用在抓取前。把任务先放进队列再取出调度，多此一举，还会增加链路延迟和出错概率。
4.2 队列选型：到底选Kafka还是别的
队列选型也讨论了很久。我们的场景特点是：消息量日均千万级，吞吐要求高；但每个消费者只处理本数据源的消息；不需要复杂的按业务字段路由，按数据源分Topic即可；消费延迟允许秒级。
对比下来，Kafka是最合适的。它吞吐量高，分区机制天然支持不同数据源独立消费进度，而且重放消息方便，出了问题可以从最后消费位点拉回重处理。团队内部也有人提出可以用内存队列或Redis列表来当缓冲，但考虑到消息落盘、持久化和消费位点管理，最终没有采纳。
这里有一个成本权衡要说清楚：Kafka带来的运维复杂度高于Redis列表，但它能保证消息不丢，而采集系统最怕的就是数据静默丢失。数据丢了业务方发现时已经晚了，相比起多维护一套中间件，数据可靠性显然重要得多。
4.3 消息格式与后续扩展性
消息体不直接存原始响应，而是存“已经结构化”的JSON数据，附带数据源标识、采集时间、原始URL等元信息。这么设计的好处是消费者只依赖数据格式，不依赖具体抓取逻辑。后续即使要加新的数据源，只需要在解析层输出同一套消息结构，下游不用改动。
消息里还额外带了一个 “数据指纹”字段。对采集到的内容做哈希，消费者入库前比对指纹，如果重复就直接跳过。这个字段是评审时后加的，但正是它保证了整个系统的幂等性——重放消息、重复发送都不会导致脏数据。
5. 存储设计与数据完整性：不重不漏是底线
数据完整性是评审的底线话题。采集系统的价值归根结底是数据，如果数据丢了、重复了、错乱了，前面的高并发设计再漂亮也没意义。
5.1 写入路径的分层设计
存储层我们设计了写入缓冲区 + 批量入库 + 异步补偿三条路径。抓取解析后的结构化消息先写入本地缓冲队列，攒够大小或超时后批量提交数据库。批量写比单条写的吞吐量高一个量级，这是数据库写入性能差距最明显的一个操作。
数据库采用分库分表策略。按数据源ID做水平分表，每个表再按日期分区。查询侧主要按数据源和时间范围进行，这样分表后能保证绝大多数查询只命中一个分区，不需要跨库扫描。某源的数据急增也不会挤占其他源的空间和性能。
上线前我们做过一次压测，批量入库的TPS可以稳定到每秒3000以上（单表），而逐条插入只有每秒300多，差距接近十倍。这个数据说明设计方向是对的。
5.2 重试与补偿：失败任务的保险丝
采集任务失败不可避免，网络抖动、目标站点临时升级、响应格式改版都会碰到。所以重试机制必须放进架构里，而不是靠人为干预。
我们设计了三级重试。第一级是应用层重试，仅针对连接超时和响应超时，最多重试两次，每次退避1秒和3秒。第二级是任务调度层重试，如果一个批次内失败率高于50%，视为任务异常，转入延迟队列，15分钟后重新调度。第三级是离线补偿，每天凌晨扫描“长时间未完成”的任务清单，重新生成调度任务。
三级策略制定时讨论最多的不是技术选型，而是“什么情况不该重试”。最终定下的规则是：HTTP 4xx状态码不重试（目标明确拒绝）、数据源返回内容格式异常不重试（重试也会一样）、被限流明确提示不重试（等待下轮调度即可）。只有5xx和超时类错误才进入重试逻辑。
这条规则避免了一次大面积故障。某目标站点升级了页面结构，所有请求都返回200但HTML结构变了，解析层全部报错。还好当时格式异常被定义为不重试，否则整个队列都会被重试消息占满，殃及其他数据源的正常任务。
5.3 数据校验与质量监控
数据入库后不代表完事了，完整性校验必须配套。我们做了三类校验任务：
- 数量校验：每天统计每个数据源计划采集量与实际入库量，偏差超过5%触发告警
- 时效校验：记录每个数据源最后一次成功采集的时间，超过设定阈值即刻标记异常
- 字段完整性校验：抽样检查入库数据的必需字段是否都有值，缺失率超过2%即告警
这三类校验虽然会给系统增加一些额外开销，但带来的收益是决定性的——所有数据问题都能在1小时之内被发现，而不是等业务方反馈后才知道数据断了。
6. 监控告警与故障排查：最后一道防线
高并发系统没有监控就等于蒙眼开车。这次评审花了整整一个章节讨论监控指标和告警阈值，因为采集系统有个特点：多数故障不是瞬间崩溃，而是性能劣化逐步逼近临界点。
6.1 必须盯住的七类指标
评审确定的核心监控指标分为七类，这是从故障教训里提炼出来的：
- 调度滞后数：等待中任务数量持续上涨，说明上游生产速度高于消费速度
- 抓取成功率：低于98%立即告警，低于90%属于严重故障
- 平均响应时间：基线值上涨30%就要关注，翻倍必须介入
- 队列积压量：消息积压超过阈值且持续增长，说明下游在告警
- 入库TPS：与抓取TPS趋势对比，偏差变大说明链路某个环节断裂
- 重试比例：超过5%意味着目标源或网络出现异常
- 任务完成延迟：从任务生成到数据入库的耗时，能直观反映管道健康状况
监控不只是看看图表。我还给团队定了告警分级规则：P0级（数据完全中断）、P1级（链路部分失效）、P2级（性能劣化）、P3级（潜在风险）。告警阈值宁可误报也不漏报，误报顶多费几分钟查看，漏报可能造成数小时数据空洞。
6.2 典型故障排查路径
评审阶段我们头脑风暴了四个最可能发生的故障场景，提前写好排查路径。
场景一：抓取成功率突然掉到80%以下。排查顺序是先看目标源出口状态，再看本地连接池和DNS解析，然后是限流配置是否误改。很多次出问题时发现是某个数据源临时封了IP段，而不是整个系统故障。
场景二：队列积压快速上涨但抓取TPS正常。这种情况通常是入库链路卡住，第一时间看数据库慢查询和连接数，其次看消费者是否被某条坏消息阻塞。曾经遇到过一次：一条超大字段数据导致消费者解析卡死，整个消费组进度停滞。
场景三：部分worker频繁超时重启。第一反应不是看应用日志，而是看宿主机负载和带宽占用。采集系统是带宽敏感型应用，经常出现带宽被打满导致所有worker请求超时的情况。
场景四：数据入库量比预期少但无告警。这是最难排查的一类，最后发现是某个数据源结构改动，解析不到数据但HTTP状态码正常（都返回200）。这也再次印证了前面说的“格式异常不重试 + 时效校验”的必要性。
6.3 线上问题排查实用工具和技巧
除了监控系统本身，我再分享几个排查中用着顺手的实用技巧。
日志必须带上下文。每个请求日志要包含：数据源ID、任务ID、批次号、URL哈希、耗时、状态码、错误详情。没有上下文关联的日志在排查时价值很低，看不出调用链关系。
加一个“链路追踪中间页”。我们给每个数据源都维护了一个最近N次请求的状态记录页，直接在管理后台能看到每个worker最近处理的100条请求的状态分布。这个页面看起来简单，但排查问题时效率极高——不用再翻海量日志找特定时间点。
保留“现场快照”机制。当系统检测到异常波动时，自动捕获当前活跃任务、连接池状态、队列长度、最近100条错误日志，存入独立存储。事后复盘直接看快照就行，不用猜测故障发生时刻的状态。
6.4 巡检脚本与日常检查清单
监控告警是出了问题才知道，巡检是防患于未然。团队每周跑一次巡检脚本，检查项包括：
- 各数据源近7天抓取成功率变化
- 任务队列积压是否有周期性上涨
- 数据库表增长速率和磁盘空间预估
- 各worker的负载均衡程度，确认没有热点
- 重试次数分布，是否有个别数据源反复触发重试
其中第五项特别重要。某个源反复触发重试往往意味着该源在悄悄改版或者风控收紧，等到完全抓不动再处理就晚了。
7. 评审会上的分歧与最终决策记录
评审过程中不是所有问题都顺利达成一致，记录几个有代表性的分歧点，这些也是架构设计中最容易反复的地方。
7.1 高并发执行框架：自研还是基于成熟组件
有成员提出直接用成熟的采集框架来省时间，理由是社区生态完善、上手快。我们评估后否决了这个方案。核心原因是：通用采集框架很难做到“按数据源精细化限流”和“动态优先级调度”，强行改造框架的成本远高于在自有轻量框架上补充功能。而且团队对这个框架不熟，出了问题排查成本极高。
最终选择是自研一个精简执行内核，只保留调度、执行、重试三块基础能力，外部对接已有的监控和配置体系。自研带来的额外负担是必须自己维护和压测，但换来的是对整个链路每个细节都心里有数。这个取舍我认为值得。
7.2 采集到的数据先清洗还是先入库
常规思维是先清洗再入库，保证入库数据质量。但我们反了过来：原始数据先入临时表，异步清洗后再入正式表。理由是解析和清洗环节可能失败，如果清洗永远不通过，原始数据就没了。按我们先入临时表的方式，即使清洗任务挂掉，原始数据还在，可以随时重新清洗。
这个方案带来了一点小代价：多一张临时表，需要定期清理过期数据。但换来的数据安全性提升是值得的——至少没有遇到过“解析挂了数据跟着没了”的事故。
7.3 是否需要专门建一套采集任务管理平台
设计稿里本来只有任务配置和worker状态的基础管理功能。评审时业务方提出需要一套独立的任务管理平台，让非技术人员能自助提交加急任务、查看任务执行进度、导出采集结果。
这个需求也不是伪需求，单独提出来是因为它关系到系统的对外能力。最后我们做了一套轻量的管理界面，按角色控制权限，技术人员能操作全部功能，业务人员只能提交加急任务和查看进度。跑了一段时间后发现这个平台的使用频率远超预期，业务方自己就能处理很多以前需要找开发的事。
8. 实测压测数据与评审后的改进项
评审结束后团队按结论改造了原设计，随后做了一轮完整的压测验证。压测目标就是验证之前设计的目标峰值1500 QPS下系统的稳定性和资源消耗。
8.1 压测方案与关键数据
压测环境没有直接连真实数据源，而是搭了一套模拟目标服务，按真实响应分布返回数据。三个worker节点，每节点分配约500 QPS的任务量，持续运行30分钟。
压测结果：系统稳定支撑峰值1500 QPS，抓取成功率99.2%，平均响应耗时1.8秒，p99响应耗时3.5秒。任务积压数维持在极低水平，队列消费与生产保持平衡。数据入库端无积压，批量写入TPS稳定在4000以上。
期间观察到一个小问题是：某一瞬间某worker的内存占用飙到高位，定位发现是某个大响应页面（超过5MB）导致的缓冲占用。之后在抓取执行层加大响应大小上限控制，问题未再出现。这类边界情况只在压测中能暴露，纯靠代码审查很难发现。
8.2 评审结论中仍然保留下来的风险项
没有完美的架构。评审结束后我们保留了三个已知风险项，没有在本次迭代中解决，而是记录在案：
第一，单机房部署，如果机房发生整体故障，系统不可用。多活改造在下个季度规划，目前靠手工切流兜底。
第二，数据完整性校验的时效性不够，目前是小时级发现数据异常。理论上可以做到分钟级，但会显著增加校验任务的开销，性价比不高。
第三，部分边界数据源（每天请求量极小的低频源）在系统里占用了将近三分之一的配置项和维护精力，但产出只占很小比例，长期看需要做一次清理和合并。
这三个风险项在评审记录中明确标注了负责人和时间节点，避免风险项躺在文档里不了了之。
8.3 评审中最值得借鉴的五条经验
评审完整跑下来，我整理了五条对任何类似系统都有参考价值的经验：
先算账再画图。把日增量、峰值QPS、带宽、存储算清楚，比先画架构图重要得多，没有数字支撑的架构设计都是空中楼阁。
限流必须是源级细粒度，全局限流等于没有限流。不同数据源的容忍度差异太大，必须隔离。
队列只放在真正需要缓冲的地方，不要为了用队列而用队列。多一层队列就多一层延迟和故障点。
幂等设计要融入数据源头，而不是靠下游去重。靠下游兜底的结果往往是下游被拖垮。
监控指标要在设计阶段就定义好，而不是上线后再补。没有监控的高并发系统就像没有仪表盘的飞机。
9. 落地上线后的一些补充感悟
系统上线运行三个月后，回头再看这次评审，有些判断被验证正确，有些地方则有了新的理解。
调度层按源配置更新周期这条改动，实际效果比预估还好。不仅请求量下降了30%，抓取成功率也提升了3个百分点，因为低频源的访问频率降下来以后被风控的概率也随之下降。
任务优先级功能本来以为使用频率不高，结果业务方大量使用。每逢上游有重要活动需要及时采集数据时，加急任务就从队列里插到最前面。这个功能如果在评审时被忽略，后面要补就会牵涉不少调度逻辑改动。
批量入库策略上线初期遇到一个问题：写入缓冲区设置的阈值和超时时间不合理，导致低峰期数据迟迟不入库。后来改为“每满1000条或间隔5秒批量提交一次”的双条件触发，问题就解决了。这类参数调优就是单纯的经验活，压测数据只能给出一个初始值，最终还是要通过线上观察来微调。
监控告警分级收到过一些“狼来了”的体验。初期P1级别的告警误报率比较高，团队慢慢习惯了告警就变得麻木。后来把误报率高的几条规则重新校准了阈值，并且对告警加上了“持续时间超过3分钟才真正触发”的延时逻辑，误报率大幅下降。这让我重新认识到：告警设计不是越灵敏越好，在灵敏和准确之间找平衡点才是关键。
最后把数据完整性校验单独再强调一遍。采集系统里数据不丢，比单次抓得快要重要得多。宁可整体速度稍微慢一点，也要保证每条数据都有唯一的轨迹可追踪、可对账。如果你也在设计类似系统，这句话值得贴在最显眼的地方提醒自己。
