单机与分布式：社交媒体热点采集的实践经验

做过舆情监控或数据分析的人大多会遇到类似需求：

• 想定时抓取 微博热榜，观察哪些话题在升温；
• 或者需要监控 小红书的热门笔记，看看某个关键词下大家都在讨论什么。

一开始很多人用单机脚本就能跑通，但随着监控范围扩大，话题数和评论量成倍增加，往往就得考虑分布式架构。

常见做法：单机采集微博热榜

最简单的尝试就是写一个多线程脚本，把微博热搜前几十个话题抓下来：

import requests
from concurrent.futures import ThreadPoolExecutor

urls = [f"https://s.weibo.com/top/summary?cate=realtimehot&page={i}" for i in range(1, 6)]

def fetch(url):
    resp = requests.get(url, timeout=5)
    return resp.text

with ThreadPoolExecutor(max_workers=20) as executor:
    results = list(executor.map(fetch, urls))

print("采集结果:", len(results))

这种方式在测试阶段没问题，能快速验证数据可用性。但问题也很明显：

• 请求量集中在一个出口，很容易被风控。
• 单机性能有限，一旦扩展到更大的话题池，效率会很低。

更优做法：分布式处理小红书热门话题

如果把目标换成小红书上的某个热门话题，比如“旅游攻略”，情况就不一样了：

• 这里不仅要抓列表页，还要跟进帖子详情、评论、点赞数。
• 数据变化快，如果延迟太大，抓到的结果参考价值有限。

更合适的做法是分布式队列：不同节点并发消费任务，搭配爬虫代理IP，抗风险能力和处理速度都能上一个台阶。

import requests
import redis
import random

# ===== 代理IP配置（示例：亿牛云 www.16yun.cn） =====
PROXY_HOST = "proxy.16yun.cn"
PROXY_PORT = "3100"
PROXY_USER = "16YUN"
PROXY_PASS = "16IP"

proxy_url = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"

# ===== Redis 队列 =====
r = redis.StrictRedis(host="localhost", port=6379, db=0)

# ===== UA池 =====
user_agents = [
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...",
    "Mozilla/5.0 (X11; Linux x86_64)..."
]

def fetch(url):
    headers = {"User-Agent": random.choice(user_agents)}
    proxies = {"http": proxy_url, "https": proxy_url}
    try:
        resp = requests.get(url, headers=headers, proxies=proxies, timeout=8)
        if resp.status_code == 200:
            print(f"[成功] {url}")
            return resp.text
        else:
            print(f"[失败] {url}, 状态码 {resp.status_code}")
    except Exception as e:
        print(f"[异常] {url}, {e}")
    return None

def worker():
    while True:
        url = r.lpop("task_queue")
        if not url:
            break
        url = url.decode("utf-8")
        html = fetch(url)
        if html:
            # TODO: 在这里解析帖子和评论
            pass

if __name__ == "__main__":
    for i in range(1, 11):
        r.rpush("task_queue", f"https://www.xiaohongshu.com/explore?topic=旅游攻略&page={i}")
    worker()

为什么要这样做？

• 微博热榜：数据量小、页面有限，单机完全可以跑。
• 小红书话题：涉及几千上万条内容，还要跟踪互动情况，如果不用分布式，很难保证覆盖率和实时性。

简单来说：数据规模和时效性决定了架构选择。

可能遇到的坑

• 代理不稳定：热点追踪请求频繁，代理质量差会直接拖垮任务。
• 重复采集：分布式抓取容易出现重复数据，需要去重机制。
• 平台改版：社交类网站改版频繁，解析逻辑要留有调整余地。
• 监控报警：热点数据延迟过久就失去价值，失败要及时发现。

一些经验之谈

• 如果只是想每天看下微博热搜，单机脚本就足够。
• 想做类似“小红书话题监控”的项目，最好从一开始就用分布式。
• 长远来看，接入消息队列、实时数据库、监控系统，才是能支撑业务的做法。

换句话说，可以先从简单方案入手，但要给架构留好扩展的空间。