1. 项目背景与整体思路接到这个需求的第一反应我心里其实是有底的。团队之前跑过不少采集程序但基本都是单机脚本加关系型数据库的模式规模一大就全乱套任务重复执行、节点闲置、数据存完就躺在表里没人去用。这次任务很明确搭一套能够支撑1000节点爬虫集群的分布式采集系统用Redis队列做任务调度用Neo4j做最终的图存储目标是让沉淀下来的数据产生真正的关联价值。这里说的爬虫集群我默认先框定一个边界只采集公开、授权、合规的数据遵守目标站点的访问规则。这也是后面所有架构设计能够成立的前提。如果你采集的是非授权数据那这套架构的天花板再高也救不了你方向错了再好的技术都是白搭。这个项目适合谁参考两种人。一种是想把采集任务从“单机脚本”升级成“分布式任务系统”的工程师可以重点看第二、四章另一种是数据已经攒得不少但发现“关联分析”根本跑不动的团队可以重点看第三章。我会把方案背后的取舍逻辑也讲清楚而不只是贴一堆配置。1.1 这个项目的本质不是写爬虫是设计一套数据流1000个节点听起来很吓人但冷静下来会发现真正的难点根本不在“每个节点怎么抓页面”上。单机爬虫的逻辑大家都会写难的是1000个任务同时运行谁来分配任务谁保证同一件事不重复做中间某个节点挂了任务会不会丢数据从Redis出来之后以什么格式进入Neo4j这些才决定集群能不能跑起来、跑得稳不稳。我习惯用一个比喻单机爬虫像是自己在家做饭锅碗瓢盆都在手边想怎么做怎么做。分布式爬虫集群更像开中央厨房1000个厨师分布在不同的位置上你得先解决“菜单怎么派发”“食材怎么配给”“菜品怎么装盒”的问题至于炒菜本身反而是最简单的环节。所以整个项目的核心架构本质上是围绕“任务分发”和“数据写入”这两个环节展开的。1.2 为什么选Redis队列 Neo4j存储先解决任务分发的问题。采集任务的天然特点是量大、单个任务执行时间短、对顺序不敏感、需要快速周转。这种场景简直是队列的教科书案例。在队列选型上我曾经对比过RabbitMQ、Kafka和Redis选型吞吐能力运维复杂度与现有技术栈契合度结论RabbitMQ高中需要单独维护Exchange、RoutingKey等概念一般功能重分布式爬虫用不到这么多特性Kafka极高重需要管理分区、副本集群维护成本高一般适合大数据流场景对任务分发来说属于大材小用Redis足够用极低单机即可起步自带持久化高应用层本来就是Redis生态最终选择Redis的LIST结构在百万级任务量下LPUSH和BRPOP的吞吐已经能稳定跑在每秒几万条以上配合主从复制可靠性也够用。因为我们需要的不是一个通用消息中间件而是一个轻量、快、好维护的“任务池”Redis是性价比最高的选择。存储侧我们面临的问题更为尖锐数据一多关联分析就废了。之前用MySQL存了上千万条实体数据做一次“通过商品找出其关联店铺里的所有品牌”这种多层级查询SQL要写几个JOIN跑一次要几分钟业务侧根本没法用。图数据库天然把实体和关系作为一等公民查这类问题就像查字典一样自然。Neo4j是图数据库里生态最成熟、上手门槛最低的社区版免费文档和社区资源都丰富我们最终选了它。后面的内容我会按一条主线展开先讲Redis队列怎么设计再讲数据怎么进Neo4j接着讲1000个节点怎么调度起来最后把压测和生产环境里踩过的坑整理出来。2. Redis队列任务调度的心脏开始之前先交代一下环境Redis用6.x以上版本Neo4j用Community 5.x。安装步骤不展开了官方文档写得很清楚Linux下一条包管理器命令的事Windows上我更推荐用WSL跑比直接跑Windows版本少踩很多路径、权限的坑。在Redis里“队列”这个词其实包含很多种数据结构不同阶段的任务状态应该用不同的结构去承载。刚开始做的时候很容易犯一个错误把所有任务一股脑塞进一个LIST里结果调试时根本分不清哪些任务在处理、哪些失败、哪些已经完成。后来我把任务状态拆成了五类待调度、待抓取、抓取中、抓取成功、抓取失败。具体来说待调度任务放ZSET延迟队列待抓取的放LIST主队列抓取中的放processing备份队列成功和失败的消息写入独立Hash并定期归档。每一类任务都用不同的Redis结构去管理排查问题的时候一眼就能看出卡在哪一环。2.1 用LIST还是Stream我最终怎么选的任务队列最直观的实现就是LIST。生产者用LPUSH往队列头部塞任务消费者用BRPOP从队列尾部阻塞弹出两者组合起来就是一个天然的生产者消费者模型。# 生产者把一个任务写入队列 def push_task(redis_client, task: dict): redis_client.lpush(crawl:queue, json.dumps(task)) # 消费者阻塞获取任务 def pop_task(redis_client): # BRPOP会阻塞等待直到队列里有数据或者超时 task_json redis_client.brpop(crawl:queue, timeout30) if task_json: _, task task_json return json.loads(task) return None这套方案好在哪里一是API足够简单几乎没有学习成本二是BRPOP自带阻塞语义消费者在队列为空时不会空转消耗CPU这在1000个节点的规模下很重要因为空轮询会白白吃掉大量CPU。第三是Redis本身支持持久化即使节点重启队列里的任务也能通过RDB或AOF恢复。后来我也测试过Redis 5.0以后推出的Stream类型它有消费者组、消息ACK这些更接近专业消息队列的能力。但实测下来对于爬虫任务的场景Stream的提升没那么明显反而让代码变得更复杂。采集任务的“至少处理一次但允许偶尔重复”的需求LIST完全满足我最终选择继续维护LIST方案。如果你需要精准的消息确认、并发消费同一个队列的多个分组再去考虑Stream。2.2 去重、优先级、延迟任务三个必须处理的细节任务去重是第一个坑。采集任务经常是滚动式更新同一个详情页可能今天抓一遍、明天又抓一遍但同一轮任务里同一个URL绝对不能进队两次。我是用一个SET配合去重来实现的def add_task_if_absent(redis_client, task: dict): task_id task[url] # SADD返回1表示添加成功0表示已经存在 if redis_client.sadd(crawl:url_set, task_id): redis_client.lpush(crawl:queue, json.dumps(task)) return True return FalseSADD的时间复杂度是O(1)去重判断量级在千万级以下都扛得住。当然SET会占用内存所以这里要注意只在“当前轮次”保持去重轮次结束后清空SET否则内存顶不住。如果URL量级真的上亿了建议换成布隆过滤器用位数组或者RedisBloom模块实现。第二个坑是优先级。有的页面更新频率高比如商品价格页有的页面更新频率低比如店铺详情页。如果全部一个队列低优任务会被高优任务不断挤到后面永远得不到执行。我用ZSET来实现延迟和优先级将需要延迟执行的任务放到ZSET里score设为执行时间戳后台起一个扫描进程到了时间的任务再转入LIST。def schedule_task(redis_client, task: dict, delay_seconds: int 0): task_id task[url] # score 执行时间戳 redis_client.zadd(crawl:delay_queue, {task_id: time.time() delay_seconds}) redis_client.hset(crawl:task_detail, task_id, json.dumps(task)) # 后台扫描进程将到期任务转回主队列 def promote_due_tasks(redis_client): now time.time() due_tasks redis_client.zrangebyscore(crawl:delay_queue, 0, now) for task_id in due_tasks: task_json redis_client.hget(crawl:task_detail, task_id) if task_json: redis_client.lpush(crawl:queue, task_json) redis_client.hdel(crawl:task_detail, task_id) redis_client.zrem(crawl:delay_queue, task_id)这个设计把“定时抓取”和“普通抓取”在同一个系统里统一了不用再单独起定时任务框架。第三个坑是“幂等性”。采集任务天然允许重复执行但写库、发通知这种下游操作必须做成幂等的。我的原则是把任务ID设计成URL的哈希值让下游可以根据任务ID天然去重而不是依赖队列本身保证精确一次。分布式系统里追求精确一次成本极高业务上能容忍重复就先不要为了这个目标把系统搞复杂。2.3 消费者确认防丢任务的关键机制单机爬虫挂了就挂了重跑一遍就行。分布式集群里一个节点把任务取走之后如果它宕机了任务就丢了。我的方案是RPOPLPUSH把“弹出”和“存入备份队列”合并成一个原子操作def safe_pop_task(redis_client): # 原子操作从主队列弹出同时推入备份队列 task_json redis_client.rpoplpush(crawl:queue, crawl:processing) if task_json: return json.loads(task_json) return None def finish_task(redis_client, task_id): # 任务成功后从备份队列移除 redis_client.lrem(crawl:processing, 1, task_id)节点执行完任务后必须调用finish_task将任务从“处理中”队列移除。如果节点中途宕机任务会一直留在crawl:processing里。重启后扫描crawl:processing中的滞留任务把它们重新放回主队列即可实现任务的不丢失。这套机制非常简单但我在生产上跑了大半年可靠性出乎意料地好。核心原因在于采集任务的执行时间通常很短几十毫秒到几秒就能跑完任务停留在processing队列的时间极短天然不需要复杂的租约机制。如果你需要处理长时间运行的任务可以在任务Hash里记录开始处理的时间戳扫描时把超过租约时长的任务回收。3. Neo4j图存储数据关联价值的底座Redis队列解决的是“数据怎么跑起来”的问题Neo4j解决的是“数据存下来之后怎么增值”的问题。很多团队把采集的数据直接丢进MySQL或者MongoDB存了上千万条查询却越跑越慢业务方想看数据之间的关系基本只能靠工程师手工查表。图数据库就是为了解决这类问题出现的。这一节我详细讲一下数据是怎么建模、怎么批量写进去、价值又是怎么体现的。3.1 图模型怎么设计先说实体再说关系我们采集的核心场景是商品聚合分析涉及到的实体大概有这几类商品Product、店铺Shop、品牌Brand、类目Category、关键词Keyword。如果用MySQL这些实体至少五张表实体之间的关联要用五六张中间表来表达要查询一段复杂关系时SQL的JOIN简直能写到怀疑人生。图数据库的思路完全不同实体是节点关系是边模型本身就和业务思维一致。图模型设计时的原则我总结了一条节点越少越稳定关系别怕多。节点是数据的骨骼每个商品、店铺只对应一个节点对象关系是数据的肌肉任何两个节点之间只要你之后可能想查询的关联都要建上关系。比如一个用户浏览了某个商品这个行为可以在User节点和Product节点之间建立一条“BROWSED”关系带上时间戳属性。这样一来后续分析就可以直接从这个关系出发做路径计算而不需要像关系型数据库那样通过行为日志表去JOIN。还有一个关键点是节点的唯一约束。在Neo4j里MERGE语句的语义高度依赖约束如果不用约束MERGE会重复创建节点导致图里出现大量“幽灵节点”。建约束的语法很简单但效果非常关键CREATE CONSTRAINT product_id IF NOT EXISTS FOR (p