CASE 05協作開發

社群輿情
監控與自動推播

輿情要 24 小時關注 → 非同步爬取、去重、資料彙整。

asyncioRedis 去重即時推播

我的角色｜協作開發：非同步爬蟲、反偵測策略、去重機制與多管道通知整合。

SCROLL

THE PROBLEM ／問題與情境

等到有人回報時，討論通常已擴散好幾個小時。

24 小時

輿情不分時段發生，人工盯場效率不佳，半夜的討論常常隔天才看到。

重複

同一則內容會被轉載、轉貼，全部推播只會洗版，重要的反而被覆蓋。

查不回

看過即遺忘，事後想追某個議題什麼時候開始發酵，沒有紀錄可查。

THE SOLUTION ／解決方案

全抓進來不難，難的是只推該推的那幾則。

01 排程

非同步輪詢

多來源併發抓取，單一來源異常不拖累查詢。

02 反偵測

降低被擋機率

隨機 UA、間隔抖動與失敗退避，避免被判定為機器人。

03 關鍵

指紋去重

對正規化後的內文取指紋，重複內容只推一次。

04 推播

分級通知

依關鍵字優先級處理不同管道推播，同時寫入記錄可回查。

ARCHITECTURE ／系統架構

一輪掃描怎麼從幾十筆，收斂成幾則通知。

來源層

社群平台 A

社群平台 B

網站 C

›

抓取層

背景排程
來源清單・定時掃描

asyncio 爬蟲池
併發控制・反偵測

›

去重層・收斂關鍵

正規化

指紋

時窗

Redis 去重

內容指紋比對・時窗內判重
轉載改標題視為同一則

›

判定與輸出

關鍵字與優先級
決定推不推・推哪個管道

Elasticsearch／全文
全部寫入・可回查

Telegram／即時推播
只推命中的

━ 粉色＝把噪音收斂成通知的關鍵路徑┄ 虛線＝三個步驟合起來才是一次判重全部寫入 Elasticsearch，只有命中關鍵字的才推播去識別化示意，來源名稱非實際平台

INTERACTIVE DEMO ／互動演示

可互動

選一個監控任務，看幾十筆怎麼收斂成一張卡。

STEP 1

啟動監控

排程觸發，讀取本輪要掃的來源與關鍵字

STEP 2

抓取貼文

asyncio 併發抓取，帶反偵測與逾時控制

STEP 3

Redis 去重

內文正規化後取指紋，時窗內比對是否已見過

STEP 4

命中關鍵字

對去重後的內容比對關鍵字與優先級規則

STEP 5

推播

依優先級送往對應管道，並寫入歷史

監控任務／合成資料

本輪掃描結果

待機中

從左邊選一個監控任務，五個步驟會依序點亮，最後產出推播卡片。

抓取 27 筆去重後 9 筆命中 5 筆

被判重複的一筆

來源 C ・ 21:33 截圖轉貼

內文與來源 A 的 21:31 貼文相同，貼文 ID 不同但指紋命中時窗內既有紀錄

推播卡片預覽

Telegram ・值班群（高優先）優先級：高多則回報無法連線，集中在 21:30 後「一直卡在登入畫面，重開也一樣，朋友也連不進去…」命中 5 筆・ 5 分鐘內・來源 A／B／C

本頁為去識別化整理，不含前雇主原始碼或資料；來源名稱、貼文內容與數量皆為前端合成資料。

TECHNOLOGY & DESIGN DECISIONS ／技術選型與設計決策

每個技術都對應一個要解的問題。

Python爬蟲、排程與通知流程的主體

Selenium需要 JS 渲染才拿得到內容的頁面

asyncio多來源併發抓取與逾時控制

Redis內容指紋去重，以及各來源的抓取節流

Elasticsearch全文儲存與歷史輿情查詢

Telegram Bot API即時推播與人員的互動指令

ALTERNATIVE CONSIDERED

為何用內容指紋去重，而不是比對貼文 ID？

貼文 ID 只能擋掉「同一則被抓了兩次」，但實際造成洗版的是同一段內容以轉載、改標題等形式出現在不同來源。改為對正規化後的內文取指紋，代價是要維護正規化規則，但相對於通知洗版導致值班人員直接忽略，這個取捨是划算的。

CHALLENGES & RESULTS ／挑戰與成果

抓得到只是起點，抓得久才是難的。

挑戰 01

長時間運行被判定為機器人

以隨機 UA、間隔抖動與失敗退避降低特徵；單一來源被擋時隔離該來源，其餘照常運作。

挑戰 02

轉載造成的重複通知

改用正規化內文指紋搭配時窗比對，轉載轉貼視為同一則，只推播一次。

全天候

排程不間斷運行，半夜的討論也不會漏掉。

不洗版

去重後只推該推的，通知才有人看。

可回查

全部寫入 Elasticsearch，事後能追議題發酵時間。