开源免费Java舆情监控系统：从采集到告警的完整工程实践

简介这是一套面向企业IT运维、品牌公关及数据分析人员的开源免费舆情监测与网络监控系统基于Java开发支持本地化一键部署可高效采集、交叉分析和深度挖掘全网舆情数据助力企业提升品牌价值与风险防控能力。资源包共2000个文件大小99.11MB涵盖1723个JavaScript前端交互脚本、128个CSS样式文件含bootstrap、jsgrid等主流UI框架主题、84个HTML页面模板、26个XML配置与元数据文件、17个JSON接口定义及少量Vue组件、Shell部署脚本与PDF说明文档结构完整、模块清晰便于二次开发与定制集成。已有1091人学习下载适用于需快速构建自有舆情中台的技术团队或高校相关课程实践项目。读者可直接获取可运行的全栈源码、标准化前后端分离架构、成熟可视化图表集成方案如css-chart、jsgrid-theme以及适配多终端的响应式界面资源。1. 项目背景市面方案的三宗罪与自研动机这个开源项目的出发点源于我给几个品牌客户做口碑监测时积累的怨气。市面上的舆情监测系统报价从一年几万到几十万不等而且大部分是SaaS订阅制——你付费买的是“使用权”数据源、采集规则、分析算法全都捂在厂商手里。客户想看一个自定义数据源提的需求排期能拖三个月最后回复“不在规划内”。还有一类开源方案常年不维护核心逻辑里硬编码了某个平台的反爬参数平台一改版整条采集链路直接瘫痪。我当时的处境很典型Java技术栈团队的成员占多数领导指定要用Java落地上线项目周期紧不能从零造轮子后期要能横向扩展不能一上来就绑死在某个重型商业产品上。综合这几条约束我决定基于Java生态做一套开源免费的舆情监测网络监控系统把“数据采集—内容清洗—智能分析—可视化监控—告警通知”这条链路完整打通并把核心代码完全开放出来。标题里两个关键词值得展开说第一是“开源免费”这意味着你不欠任何厂商的人情数据源配置、分词词典、情感判断规则全部可审计、可修改第二是“系统设计”它强调的不是一个爬虫脚本而是一套能应对真实生产环境的完整工程——有调度、有队列、有存储、有检索、有告警缺一环都不算“系统”。如果你是想快速做一个人工监测工具那用现成的RSS加表格就能应付但如果你需要的是7x24小时自动采集、自动去重、自动归类、自动告警的网络监控系统这个项目的设计思路和源码结构值得你完整看一遍。做毕业设计选题“基于SpringBoot的舆情分析系统”的同学这套源码也可以直接作为系统设计蓝本。2. 系统总体设计从采集到展示的一整条链路2.1 数据流向与模块边界整个系统的核心链路可以概括为六个环节配置中心下发采集任务 → 调度器触发采集 → 采集器抓取页面内容 → 管道清洗与结构化 → 分析引擎研判 → 存储与可视化展示。这六个环节并不是线性堆叠的中间有两条关键的“缓冲带”一条是消息队列一条是搜索引擎索引缓冲区。我在设计时刻意把采集和入库做成了异步解耦。采集器只负责把原始HTML抓回来丢给消息队列就完事后端的清洗和分析模块从队列里消费消息再写入搜索引擎。为什么非要绕这么一圈因为舆情监测有个典型特征——数据洪峰不可预测。某个突发事件出现时目标站点响应变慢采集速度骤降事件消退后站点恢复积压的任务又会瞬间涌回来采集器瞬间产出一大批原始数据。如果没有队列削峰数据库会被突发的写入请求打爆。用消息队列把“生产”和“消费”隔离开采集再快也不会压垮存储层。以下是系统的核心模块清单模块职责核心组件配置中心管理监测主题、数据源、采集频率Spring Boot MySQL调度中心下发定时采集任务、失败重试Quartz 集群模式采集器抓取目标页面解析HTMLWebMagic 深度二次开发清洗管道去噪、正文抽取、编码修正jsoup 自研管道链分析引擎分词、情感判断、热点聚合HanLP 自定义词典存储检索舆情数据索引、关键词检索、聚合统计Elasticsearch 8.x可视化端大屏展示、趋势图、告警中心Vue 3 ECharts通知模块邮件、钉钉/企业微信机器人推送Spring Mail HTTP SDK2.2 技术选型的三个关键取舍整套系统的技术栈看起来很大路货但每个选型背后都有明确的考量。第一Java 17 Spring Boot 3。用Java做采集端在很多人看来有些“重”但考虑到系统要长期运行在服务器上Java的稳定性、内存管理和线程调度能力比脚本语言更可靠。Spring Boot 3的GraalVM原生镜像支持还能在后续做冷启动优化对部署环境不那么敏感。第二MySQL Elasticsearch双存储。很多舆情系统只用MySQL数据过百万后模糊查询慢得没法用。我用MySQL存配置数据和告警记录用Elasticsearch存采集到的舆情正文。ES的分词检索、聚合统计能力在舆情分析场景里优势太明显——按时间聚合、按来源聚合、按情感倾向聚合这些操作在MySQL里写SQL能绕半天在ES里一个聚合查询就出来了。第三HanLP而不是纯第三方API。情感分析和关键词抽取如果全量调云端API数据要出网不说单条成本虽然低量大了也是笔持续支出。我最初想过接大厂的自然语言API后来意识到舆情文本里大量是口语化短句通用API的效果未必比精心调校的开源模型好。HanLP在GitHub上社区活跃词典可定制我可以持续往里面补充行业词库长期下来准确率是往上走的。提示如果你对检索性能没有硬性要求ES版本建议选8.11以上内置的JDK、安全配置和自动映射机制更省心。选7.x虽然资料多但集群配置和维护成本明显偏高。3. 核心模块的实现细节采集、分析与存储的工程化落地3.1 数据采集层WebMagic的二次开发实践采集层没有从零写HTTP请求工具而是在WebMagic框架上做了大量改造。WebMagic的优势是四组件模型Downloader、PageProcessor、Scheduler、Pipeline非常清晰但它默认的爬取策略偏“轻”——没有内置轮询代理、没有分布式去重、对JavaScript渲染页面无能为力。我针对舆情场景做了三处核心改造。第一处改造是去重策略。默认的Scheduler用HashSet做内存去重单机跑还行采集任务一多就超额占用内存。我换成了基于Redis的布隆过滤器去重。布隆过滤器的原理是用多个哈希函数映射位数组判断“某个URL是否已经采集过”存在一定误判率我配置了0.01%的容忍度但内存占用极低——1亿条URL去重内存消耗不超过200MB。具体实现上我封装了一个RedisBloomScheduler重写push和poll方法先走布隆过滤器判断URL是否重复再进入待抓取队列。public class RedisBloomScheduler extends DuplicateRemovedScheduler { private final RedisTemplateString, Object redisTemplate; private final BloomFilterString bloomFilter; public RedisBloomScheduler(RedisTemplateString, Object redisTemplate) { this.redisTemplate redisTemplate; this.bloomFilter BloomFilter.create(Funnels.stringFunnel(StandardCharsets.UTF_8), 100_000_000, 0.0001); } Override public void push(Request request, Task task) { String url request.getUrl(); if (bloomFilter.mightContain(url)) { logger.info(重复URL跳过: {}, url); return; } bloomFilter.put(url); super.push(request, task); } }第二处改造是代理IP的轮换机制。做舆情采集最怕的就是IP被封尤其是采集新闻门户和社区站点时频率一高立刻被限流。我在Downloader层加了一个代理池组件从配置中心读取代理列表每个请求按权重挑选一个代理IP同时每隔一段时间自动检测代理可用性。这个模块我独立成了一个ProxyManager通过接口注入你如果用不到代理能力直接替换成直连实现即可。第三处改造是页面渲染策略。不少舆论发酵的场景发生在Vue或React渲染的单页应用里普通HTTPClient拿到的HTML是空壳正文内容靠异步接口加载。我接入了Playwright作为无头浏览器方案专门处理这种情况。但无头浏览器资源开销大不能所有请求都走它。我设计了一个“先轻后重”的策略先用普通HTTP请求抓一遍如果解析出的正文字数少于50字判定为动态渲染页面再用Playwright补抓。这个策略帮助系统大幅节省了服务器资源。3.2 内容清洗管道正文抽取与编码纠错采集链路第二个容易翻车的环节是内容清洗。原始页面里除了正文还有导航栏、侧边栏广告、相关推荐、页脚版权信息这些噪声如果不处理干净后续分词和情感分析的准确率会大打折扣还会白白占用ES存储空间。清洗管道我用的是责任链模式每一级管道只负责一件事编码修正部分老旧站点返回的Header没声明charset或者声明错误正文一进内存就是乱码。这一步通过分析HTML里的meta标签和字节流特征做编码探测默认按UTF-8处理探测失败就回退到GBK。HTML标签去噪去掉script、style、noscript标签内容提取正文纯文本。正文抽取基于标签密度算法判断正文区域。核心思路是遍历DOM树计算每个节点的文本密度文本字符数/标签数密度最高的节点块大概率是正文区。这个算法比粗暴地取p标签内容要准得多。段落合并与清洗合并被分页插件拆断的段落过滤掉“相关阅读”“点击查看全文”这类导航文本。这里有一个反复踩过的坑部分新闻站点的正文里会插入“免责声明”块而且这个块在DOM层级上跟正文同级、密度也高很容易被正文抽取算法误判。处理方案是在清洗管道末尾加一个关键字黑名单过滤器命中“免责声明”“版权声明”“本网将追究法律责任”等模式就整块剔除。编码问题也是新手高频翻车点。我举个例子很多国内老站用的是GB2312但页面里嵌了UTF-8的统计代码HTML的meta声明的又是UTF-8实际放在数据库里的字节却完全是GBK编码。这种情况用jsoup直接doc.text()必然拿到乱码。正确做法是先按字节流尝试解码再解析DOM不能上来就用字符串构造Document。我在管道链上专门加了CharsetDetector用ICU4J的检测库处理这类情况。3.3 舆情分析引擎分词、情感判断与热点发现清洗干净的文本进入分析引擎后要回答三个核心问题这段舆情在说什么说的是好事还是坏事这个事件值不值得关注分词与关键词提取。底层用的HanLP的标准分词模式同时维护了一份自定义行业词典——把客户所在领域的产品名、竞品名、行业术语全部加进去。词典的作用在分词阶段就能体现出来没有行业词典时“价格倒挂”会被拆成“价格/倒挂”加了词典后作为整体词保留关键词权重计算的结果完全不同。自定义词典用CustomDictionary动态加载支持界面后台在线维护不需要重启服务。情感判断。采用“情感词典程度副词否定词”的规则方案同时用一个小型朴素贝叶斯模型做兜底修正。规则部分的核心逻辑对文本分词逐个匹配情感词典正向词表、负向词表各约一万词。检查情感词前是否存在程度副词“非常”“极其”“略微”按权重调整情感分值。检查情感词前是否存在否定词“不”“没”“毫无”如果否定词出现在情感词前两个词以内翻转情感极性。汇总全文情感分值超过正阈值判定为正面低于负阈值判定为负面中间判为中性。这套方案在短文本上的准确率大约能到85%到90%。它不完美但胜在完全可控、离线可跑、特征可解释。生产环境里如果发现某条明显负面的内容被判成正面的直接查词典里缺了哪个词补上就行。热点发现。热点的本质是“短时间多来源围绕同一主题密集发声”。我实现了一个基于滑动窗口的聚类算法每5分钟一个窗口窗口内对采集到的文章做关键词集合抽取用Jaccard相似度计算文章间的重叠度重叠度超过阈值的分到同一个簇当一个簇在多个连续窗口内持续膨胀且涉及不同来源站点就判定为热点事件并生成事件聚合页。这个算法的计算瓶颈在关键词集合的对比我优化成了先倒排索引再对比处理每秒上百条的流入量没有压力。3.4 数据存储Elasticsearch索引模型与查询设计ES的索引模型设计对后面的查询性能影响极大。我的索引设计遵循“宽表”思路每条舆情记录扁平化存储{ id: 20251201_092315_001238, title: 某品牌旗舰手机批量到货渠道价出现松动, content: 正文全文……, source: 某数码社区, sourceType: BBS, author: 匿名用户, publishTime: 2025-12-01T09:23:1508:00, collectTime: 2025-12-01T09:23:1708:00, emotion: NEUTRAL, emotionScore: 0.23, keywords: [旗舰手机, 渠道价, 到货], url: http://example.com/article/12345, siteDomain: example.com, region: 华南 }索引配置里最关键的几个点标题和正文用ik_max_word分词器允许做最细粒度拆分keywords字段用ik_smart分词保证聚合结果可读性更好。publishTime和collectTime设置成date类型format里明确写明yyyy-MM-dd HH:mm:ss||yyyy-MM-ddTHH:mm:ss.SSSZ||strict_date_optional_time||epoch_millis避免不同数据源时间格式不一致导致解析失败。需要聚合的字段source、emotion、sourceType设置成keyword类型不要设置成text否则聚合时会非常慢。动态映射开启但给某些已知字段预定义mapping防止标准分词器把标题拆得没法看。ES查询端最常用的三个场景按关键词全文检索、按时间聚合统计情感趋势、按来源和情感做多维下钻。其中“趋势图”本质是一个date_histogram聚合配合情感字段的子聚合能一次性把“正面/中性/负面各时段分布”算出来。这块如果直接遍历结果自己在内存里分组数据量上来了肯定慢。提示ES的refresh_interval我调成了10秒而不是默认的1秒。舆情场景对近实时性要求没那么极端10秒刷新一次能将写入吞吐提升一个量级。滚动更新的索引生命周期策略也不要落下按天数索引后自动清理避免磁盘被历史数据占满。3.5 可视化监控大屏与告警通知可视化层的骨架是Vue 3 ECharts WebSocket。数据接口由后端按时间范围和监测主题返回聚合结果前端渲染成折线趋势图、情感占比饼图、来源分布柱状图、热点事件列表和最新舆情流。这块在技术层面不复杂真正难的是把“信息密度”和“可读性”平衡好——一张大屏上堆几十个图表没有任何意义。我的建议是大屏只展示决策者关心的三个核心指标——总量趋势、负面占比、热点事件Top 10其他指标全部放在二级查询页面。负面占比超过阈值时数字变成红色并闪烁配合告警消息推送。视觉上多用深色底、高对比高亮的配色会议室投屏和监控大厅的大屏上看都不费劲。告警通知我实现了三级联动系统检测到负面舆情文字命中“严重”级别词典立刻推送给值班人员命中“紧急”级别的通过HTTP回调发送给企业微信群机器人并电话通知值班手机普通级别的负面舆情进入每日汇总不单独打扰。分级策略要写在配置文件里每一个级别都能单独开关否则正式运行时告警轰炸会让你关掉整个通知模块。4. 部署实战、性能调优与踩坑排错4.1 环境准备与编排化部署整套系统的依赖包括JDK 17、MySQL 8.0、Redis 6.2、Elasticsearch 8.11、消息队列容器。因为组件较多我提供了完整的Docker Compose编排文件一条命令拉起全部依赖。生产服务器建议至少8核16G其中ES至少分配4G内存JVM堆和系统内存的比例按官方推荐控制在1:2以内。部署时最容易忽略的是ES的启动参数。ES 8.x默认开启安全认证如果你不想用自带的HTTPS和账号密码体系部署到内网时需要在elasticsearch.yml里显式关闭安全特性并在所有客户端工具的ES配置里保持一致否则采集模块启动时一直报连接认证失败。4.2 JVM参数调优G1和堆内存之争采集器和分析引擎分别跑在独立的应用进程里JVM参数配置完全不同。采集器是高频IO型任务堆内存不需要太大但需要足够大的直接内存Direct Memory供Netty和Playwright用分析引擎偏CPU密集型堆内存要足G1的区域划分要留给大对象足够的空间。我最终采用的JVM参数组合# 采集器IO密集 java -Xms2g -Xmx2g -XX:UseG1GC -XX:MaxDirectMemorySize1g -jar collector.jar # 分析引擎CPU密集 java -Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis100 -XX:ParallelRefProcEnabled -jar analyzer.jar这里特别要提醒的是堆内存不要盲目调大。我有一次把采集器的Xmx调到6G结果GC时停顿反而更频繁了——对象存活时间短、大量小对象飞速晋升老年代G1的混合回收跟不上。后来通过GC日志分析把堆压回2G配合批量聚合插入停顿反而降下来了。4.3 Elasticsearch索引调优ES调优这块踩过的坑主要集中在分片设置和写入速度上。最初我给舆情索引设置了10个分片结果单日数据量只有百万级10个分片的写入和查询都要做额外的分片协调性能一点没占到便宜。后面改成“按天滚动索引 单索引3主分片1副本”查询时通过别名覆盖最近30天索引速度和资源占用都好看很多。写入性能的另一个关键点是批量提交。千万不能一条一条地执行insert我用BulkProcessor攒批根据请求体积和条数两个维度触发flush攒够1000条或5MB才批量提交给ES。实测从单条写入到批量提交吞吐量能提升8到10倍。4.4 一次生产环境OOM的完整排查过程这套系统上线后遇到最严重的一次事故是采集模块在运行三天后直接OOM退出。当时没有第一时间看日志先看了监控面板——内存曲线呈锯齿状稳步抬升每次GC之后内存能降下来一部分但整体是单调递增的典型的“内存泄漏”表象。排查链路我按三步走第一步确认是不是JVM堆内存溢出。看hs_err_pid日志确认抛出的是java.lang.OutOfMemoryError: Java heap space问题出在堆内。第二步dump堆快照。我在JVM参数里早就加上了-XX:HeapDumpOnOutOfMemoryError所以OOM时自动生成了hprof文件。把文件导入MAT发现一个名为LinkHashMap结构占了80%的内存里面全是URL字符串。第三步定位到具体代码。MAT显示的持有者指向WebMagic的HashSetDuplicateRemover——我之前虽然把调度器去重切到了Redis布隆过滤器但不知哪个版本的配置没生效默认的内存去重器还在运行采集三个月以来的全部URL都堆积在内存里最终堆被撑爆。修复方案是在配置中心显式指定调度器实现同时在线程启动时打印实际生效的调度器类名彻底杜绝“以为用上了Redis去重实际还在内存去重”的隐患。修复后系统平稳运行至今再未发生同类问题。4.5 高频踩坑问题速查表现象根因解决方案采集到的中文全部乱码页面字符集声明错误用ICU4J按字节流探测编码不要直接构造字符串ES查询关键词不命中索引mapping用了标准分词器重建索引改用ik_max_word关键词搜索能搜到但聚合结果异常字段类型是text将聚合字段改为keyword类型告警推送重复轰炸同一事件多次触发通知在Redis里加时间窗口去重同一事件10分钟内只推一次动态渲染页面抓不到内容普通HTTP请求拿不到渲染后的HTML接入Playwright无头浏览器进行二次抓取采集速度快但入库有明显延迟消费端批量逻辑不合理改造BulkProcessor按条数和体积双阈值触发写入5. 实测效果与开源项目的下一步走向5.1 一个月的试运行数据我把这套系统接入了两个真实的品牌口碑监测场景跑了近一个月的试运行。采集端维护了约30个数据源包括新闻门户、垂直行业社区、问答平台和主流社交平台的公开信息页面日均采集有效舆情数据约2.8万条去重率约35%。正负面判断的抽样准确率在87%左右热点事件检测能够提前约2小时捕捉到客户在渠道侧的价格讨论浪潮——这个时效性对品牌方来说非常有价值。系统资源占用方面8核16G的单机部署足够应对当前数据规模ES磁盘占用每日约1.2GB考虑到索引生命周期策略会自动清理过期数据长期运行不需要频繁扩磁盘。全链路从数据产生到分析师看到大屏更新延迟基本控制在30秒以内。5.2 开源项目的可扩展方向这套系统作为开源项目我规划了三条明确的演进路线。第一条路是接入大模型做深度研判。目前的情感分析和热点聚类还是基于词典和规则能解决大部分常规场景但对“反讽”“隐喻”“长文本多观点混杂”这些复杂情况还是力不从心。下一步计划在分析引擎里加入LLM接口调用的能力先对负面判定置信度较低的内容做二次复核用大模型生成摘要和研判结论用私有化部署的轻量模型来解决数据出网问题。第二条路是插件化数据源架构。目前每个数据源的适配逻辑都在主代码里新增一个数据源要改代码、发版本、重启。后续想设计成类似Logstash的input-plugin机制每个数据源一个独立插件包通过配置中心热加载让非开发人员也能自助接入新站点。第三条路是多租户隔离。现在这套系统服务的是单一品牌方如果做成SaaS形式对外开放需要引入租户隔离机制不同租户的数据采集范围、索引生命周期、告警规则都要互相独立。ES本身支持多租户索引规划这块改动主要在业务配置层。最后分享一个小技巧舆情监测系统跑得再精准也只是决策辅助工具不能完全替代人的判断。我现在的运营习惯是每天上午十点和下午四点各花15分钟人工过一遍系统推送的负面告警和热点事件处理掉明显误报剩下的进入正式研判流程。系统负责“快”人负责“准”——把这两者结合起来舆情监测这件事才算真正闭环。本文还有配套的精品资源点击获取