简介一份基于Java的地震信息监测报警系统完整项目包面向Java学习者与地球物理或应急管理方向的技术人员可用于理解多源数据接入、实时监测、异常检测与报警触发的落地实现。压缩包共301个文件约4.36MB包含75个Java源码文件核心业务逻辑与算法、59个XML配置框架与数据映射、38个JSP页面后台管理界面、36个JS与36个CSS前端交互与样式另有SQL数据库脚本、日志及字体图标等资源目录结构清晰便于按模块研读。系统覆盖数据采集、清洗、异常检测及分级报警等环节并设计了基于JavaFX/Swing的可视化界面可支撑教学实训或毕业设计二次开发。目前已吸引154人学习下载适合想以完整项目快速上手JavaWeb 数据可视化开发的读者。1. 为什么地震报警系统要做成多维度深夜值班最怕的不是地震而是误报。单一阈值的震动检测器一旦捕捉到货车经过、爆破施工或强风引起的低频震动就会立刻触发报警把所有人从睡梦中叫醒等确认后才发现是虚惊一场。这类问题恰恰说明地震信息监测不能只看“有没有震”而要把震源深度、震中距、P波/S波到时差、烈度衰减、台站信噪比等多个维度放在一起综合判断。多维度的地震信息监测报警系统解决的就是这件事它在数据采集端接入不同来源的信号在分析端用多条件规则过滤干扰再根据综合评分分级报警把误报率和漏报率同时压下去。对已经有 Java 后端基础、想独立搭建监控报警平台的工程师来说这是一个很适合用来打磨并发处理和规则引擎能力的落地场景。2. “多维度”到底指哪些维度以及如何用 Java 建模2.1 从地震学科和工程两个视角定义维度我一般会把维度分成两类。第一类是地震学意义上的物理维度P波与S波的到时差这是判定震中距最硬的数据震动加速度峰值(PGA)和速度峰值(PGV)用来估算烈度震级、震源深度、发震时刻则决定破坏力。第二类是工程意义上的可信度维度台站设备状态是否在线、信号是否饱和、背景噪声是否偏高、同一区域是否有多个台站同时触发。这两类维度缺一不可前者负责“该不该报警”后者负责“这次报警可不可信”。把这套理解落到表结构上大概长这样维度名称类型单位采集来源报警用途p_s_diffdouble秒波形识别模块估算震中距pgadoublegal加速度计判断地面运动强度magnitudedouble级震级估算模块定级参考depthdoublekm震源定位模块判定破坏范围station_countint个台站状态管理器判定多台站一致性snrdoubledB信噪比分析排除低质量信号注意这里没有把“是否超过阈值”作为维度因为阈值是规则层的产物不是原始观测值。建模阶段只保存事实不做判定这样后面调整规则时不用回刷历史数据。2.2 用 Java record 定义不可变观测数据在 Java 17 及以上版本我用 record 来承载这类原始观测值。record 自带 equals、hashCode 和 toString适合作为队列消息和数据流中的不可变对象。下面是核心数据结构public record SeismicObservation( String stationId, // 台站ID Instant occurredAt, // 事件发生时间 UTC double pga, // 峰值加速度单位 gal double pgv, // 峰值速度单位 cm/s Double psDiff, // P波S波到时差单位秒可能为空 Double magnitude, // 估算震级可能为空 double depth, // 震源深度单位 km double snr, // 信噪比单位 dB int stationCount // 当前接入且上报该事件的台站数 ) {}创建观测对象时我只用工厂方法不做任何业务判断保证这个类纯粹是一个传输载体。实际项目中record 的字段名最好和前端 JSON 字段保持驼峰一致否则序列化时还要做字段映射。2.3 维度优先级与可信度策略不同维度的响应速度不一样。P波到达后的一两秒内只能拿到初始振动数据此时没有任何后期修正的震级信息。系统必须设计成“先按快维度预判再按慢维度修正”。我常用的做法是给每个维度配一个 ready 标记紧急维度pga、snr、psDiff数据一到就可以参与判定校核维度magnitude、depth、stationCount可能有延迟用于在首次报警后 5 秒内做升级或降级。规则引擎每收到一条有效记录就重新计算一次综合分。分数超过报警线但校核维度还没准备好时先发“预报警”等到校核维度齐了再决定是升级为正式报警还是取消。这套“先快后准”的策略在真实地震预警中使用得非常普遍也是本系统多维度价值最集中的体现。3. 基于线程池与队列的多源数据接入层3.1 为什么不能每个台站一个线程最简单的实现是每个台站建一个线程循环读取数据。但台站数量一旦超过几百线程上下文切换开销会立刻吃掉可用 CPU而且大量 socket 连接阻塞在等待 I/O 上资源利用很低。常见做法是用固定大小的线程池加有界阻塞队列把“数据接入”和“业务处理”彻底拆开。接入层我一般分三层Collector负责从各台站的 TCP/UDP 端口、Kafka topic 或 MQTT 主题读取原始数据Dispatcher把不同来源的数据按照 stationId 一致性哈希分发到处理线程Analyzer真正做报警规则计算的模块。3.2 用 ExecutorService 和 BlockingQueue 搭建生产消费模型int cores Runtime.getRuntime().availableProcessors(); BlockingQueueSeismicObservation queue new ArrayBlockingQueue(CORES * 1000); ExecutorService collectorPool Executors.newFixedThreadPool(4, r - { Thread t new Thread(r, seismic-collector- r.hashCode()); t.setDaemon(true); return t; }); ExecutorService analyzerPool Executors.newFixedThreadPool(MAX(2, cores - 1), r - { Thread t new Thread(r, seismic-analyzer- r.hashCode()); t.setDaemon(true); return t; }); // 采集端模拟 collectorPool.submit(() - { while (!Thread.currentThread().isInterrupted()) { SeismicObservation obs readFromStation(); queue.offer(obs, 100, TimeUnit.MILLISECONDS); } }); // 分析端消费 for (int i 0; i MAX(2, cores - 1); i) { analyzerPool.submit(() - { while (!Thread.currentThread().isInterrupted()) { SeismicObservation obs queue.poll(1, TimeUnit.SECONDS); if (obs ! null) { alertEngine.evaluate(obs); } } }); }这段代码里有两个参数值得单独说明。一个是queue.offer(obs, 100, TimeUnit.MILLISECONDS)阻塞队列满时只等 100 毫秒超时返回 false这样采集线程不会无限期卡死在写队列上可以把丢弃事件计数后继续工作。另一个是cores - 1分析任务是 CPU 密集型给核心数减一是为了留出一个线程给 GC 和采集端避免 CPU 满载时整个 JVM 卡顿。3.3 多源数据对齐等所有台站都到齐再判断同一个地震事件会有多个台站上报。如果每个台站到一条就立刻算综合分就会出现先到的台站权重过高的问题。更稳的方案是给每个事件设置一个时间窗口窗口内等待所有台站数据到达再统一计算。用 CompletableFuture 可以非常简洁地实现批量等待ListCompletableFutureVoid futures stationIds.stream() .map(id - CompletableFuture.runAsync(() - collectData(id), collectorPool)) .toList(); CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])) .orTimeout(3, TimeUnit.SECONDS) .exceptionally(ex - null) .join();orTimeout是 Java 9 引入的到 3 秒还没收齐就直接放弃不让报警判定无限期阻塞。exceptionally把超时异常吞掉然后靠后续的空值判断来降级处理。对于真的需要等全的场景也可以用CountDownLatch但 CompletableFuture 可以天然结合线程池代码更紧凑。3.4 用 Redis 做每台站计数和时间窗去重收到同一台站同一时间的重复报文很常见网络重传或台站重复上送都会导致。我用 RedisTemplate 的 increment 对台站上报次数做计数String key seismic:station: obs.stationId() : toMinute(obs.occurredAt()); Long count redisTemplate.opsForValue().increment(key, 1); if (count ! null count 1) { redisTemplate.expire(key, 65, TimeUnit.SECONDS); } if (count 3) { log.warn(station {} duplicate report, ignored, obs.stationId()); return; }这里increment(key, 1)的返回结果是该 key 自增后的值等于 1 说明是这一分钟内第一条此时才设置 65 秒过期时间。过期时间比窗口多 5 秒是为了避免窗口边界处 key 提前消失。把“去重计数”放进 Redis 而不是 JVM 本地好处是多个应用实例共享同一份计数不会因为负载均衡把同一个台站的请求分散到不同节点后各自计数、各放过三次。4. 报警判定规则引擎与多渠道报警落地4.1 权重综合评分每个维度都有加权分纯靠一两个阈值判断会把多维度设计浪费掉。我习惯把每个维度的观测值映射为 0 到 100 的分值再乘以权重得到综合分。映射函数要在规则引擎里可以热更新方便地震台网调整参数。public class DimensionScorer { private final MapString, Double weights Map.of( pga, 0.35, psDiff, 0.25, snr, 0.20, stationCount, 0.20 ); public double score(SeismicObservation obs) { double pgaScore normalize(obs.pga(), 80, 400); double psScore normalize(obs.psDiff() null ? 0 : obs.psDiff(), 2, 8); double snrScore normalize(obs.snr(), 10, 30); double stationScore Math.min(100, obs.stationCount() * 20); return weights.get(pga) * pgaScore weights.get(psDiff) * psScore weights.get(snr) * snrScore weights.get(stationCount) * stationScore; } private double normalize(double value, double low, double high) { if (value low) return 0; if (value high) return 100; return (value - low) / (high - low) * 100; } }这段逻辑的要点在于权重本身也是维度。站点多但信号弱综合分会偏低信号强但只有孤台分也上不去。实际调参时可以先跑一周历史数据把误报和漏报样本分别画分箱图找到两类样本在当前权重下的分界点再决定阈值。4.2 分级报警与通知策略综合分出来后按区间映射成四级报警不同级别走不同通知渠道。报警等级判定要写在独立类里方便单元测试。综合分区间报警等级通知渠道触发行为0-39无不通知只记录日志40-59蓝色邮件邮件通知值班组60-79黄色短信邮件电话值班群同步推送80-100红色电话短信邮件启动应急电话流程通知渠道我建议用策略模式做不要去写一堆 if-else。每个渠道实现一个AlertNotifier接口再用 Spring 的Component注入进AlertDispatcher。公众号、企业微信、钉钉机器人的 webhook 本质上都是 HTTP POST差别只在消息格式写一个通用HttpNotifier再各自实现buildPayload方法即可。4.3 报警抑制避免同一事件刷屏如果规则引擎每秒收到一条新高分观测就会每秒发一条报警值班手机会被打爆。必须做报警抑制。两个手段同时用第一同类报警合并。以stationId 震中区域 等级为 key在 Redis 中记录最近一次发送时间如果距上次不足 5 分钟则只更新事件计数不重复发送。String alertKey seismic:alert: region : level; Boolean first redisTemplate.opsForValue() .setIfAbsent(alertKey, String.valueOf(System.currentTimeMillis()), 5, TimeUnit.MINUTES); if (Boolean.TRUE.equals(first)) { alertDispatcher.dispatch(level, payload); }setIfAbsent是原子的只会有一个线程拿到 true其他线程拿到 false 后直接静默。这里的 key 过期时间同时也是抑制窗口窗口内重复事件不做二次通知但可以把这个 key 对应的 value 当计数器用 increment 记录累计次数方便事后复盘。第二等级降级。如果红色报警刚发过一次5 分钟内的后续事件的综合分只在相邻等级内波动就把第二次报警降一级发送。这个比简单丢弃更稳值班人能感知“还有后续活动”又不会因为重复红色报警而麻痹。5. 报警延迟压测与参数调优技巧5.1 模拟并发台站上报测量端到端延迟系统上线前我会做一个简单的并发压测用 JMeter 或直接写 Java 并发程序模拟 200 个台站同时上报同一地震事件记录从 first report 到红色报警发出的间隔。压制后的关注指标有两个一个是 p99 延迟也就是 99% 的报警在多少毫秒内触发另一个是边界值每隔 5 分钟窗口边缘是否出现丢失。java -jar stress-client.jar \ --threads 200 \ --interval 50 \ --events 1000 \ --target http://localhost:8080/seismic/ingest--events 1000表示模拟 1000 条观测记录--interval 50表示每 50 毫秒发一条。压测时观察线程池活跃度如果活跃线程长期占满cores - 1说明消费速度跟不上生产速度优先调整队列容量而不是加大线程数。5.2 Redis 线程池与连接池参数联动很多系统报警延迟源头不在计算逻辑而在连接池等待。Jedis 默认 maxTotal 过小时高并发上报会排队等连接单次报警延迟直接翻几倍。我一般把连接池 maxTotal 配成analyzerPool 线程数 × 2minIdle 配成线程数的一半避免突发流量时 Redis 连接动态创建带来的毛刺。压测时还要留意业务线程和 Redis 连接是否互相争抢 CPU。如果分析线程把 CPU 全部占完GC 停顿会拉长报警延迟随即出现长尾。JVM 参数加-XX:ActiveProcessorCount4可以强制让 ForkJoinPool 和 GC 都按 4 核计算防止容器配额和 CPU 实际可见核数不一致导致的线程数膨胀。5.3 用时间窗切片代替全局计数规避热点 keyRedis 计数 key 如果只用一个固定 key比如seismic:alert:regionA所有台站的抑制判断都打在这个 key 上单 key 的访问量会变成分布式系统的热点。我建议把计数 key 按分钟切片seismic:alert:regionA:202606101430每个 key 只承担一分钟内的判定量。过期时间设为 5 分钟加expire在创建时顺手设置不影响正常使用。配合前面说的setIfAbsent每台机器每次判断只产生一次网络往返Redis 也完全没有评估压力。5.4 规则参数热更新的工程技巧报警规则参数别硬编码在 Java 类里放到配置中心或数据库配置表里改权重不用重启服务。我用的是 Spring 的ConfigurationProperties配合配置中心推送规则引擎每次评分前从本地缓存读取权重副本。更新时先用线上一半流量验证新权重确认误报率不升再全量生效。权重变了之后历史报警记录里综合分会和当时的实际判断不一致所以每条报警要把当时的维度原始值和所用权重序列化进报警记录事后查问题才说得清。边界值验证上我通常会构造两组模拟数据一组 P 波弱但台站密集另一组 P 波极强但只有孤台。这两组数据如果按学科直觉应当都触发黄色报警那么当前权重和阈值就不需要回调如果一组触发蓝色、一组触发红色说明权重要往失衡方向修正。把这几组验证数据写成 JUnit 参数化测试每次改参数后自动跑一遍比上线后靠值班反馈发现误报要省事得多。本文还有配套的精品资源点击获取 Java多维度地震监测报警系统：从数据采集到规则引擎的工程实践
简介一份基于Java的地震信息监测报警系统完整项目包面向Java学习者与地球物理或应急管理方向的技术人员可用于理解多源数据接入、实时监测、异常检测与报警触发的落地实现。压缩包共301个文件约4.36MB包含75个Java源码文件核心业务逻辑与算法、59个XML配置框架与数据映射、38个JSP页面后台管理界面、36个JS与36个CSS前端交互与样式另有SQL数据库脚本、日志及字体图标等资源目录结构清晰便于按模块研读。系统覆盖数据采集、清洗、异常检测及分级报警等环节并设计了基于JavaFX/Swing的可视化界面可支撑教学实训或毕业设计二次开发。目前已吸引154人学习下载适合想以完整项目快速上手JavaWeb 数据可视化开发的读者。1. 为什么地震报警系统要做成多维度深夜值班最怕的不是地震而是误报。单一阈值的震动检测器一旦捕捉到货车经过、爆破施工或强风引起的低频震动就会立刻触发报警把所有人从睡梦中叫醒等确认后才发现是虚惊一场。这类问题恰恰说明地震信息监测不能只看“有没有震”而要把震源深度、震中距、P波/S波到时差、烈度衰减、台站信噪比等多个维度放在一起综合判断。多维度的地震信息监测报警系统解决的就是这件事它在数据采集端接入不同来源的信号在分析端用多条件规则过滤干扰再根据综合评分分级报警把误报率和漏报率同时压下去。对已经有 Java 后端基础、想独立搭建监控报警平台的工程师来说这是一个很适合用来打磨并发处理和规则引擎能力的落地场景。2. “多维度”到底指哪些维度以及如何用 Java 建模2.1 从地震学科和工程两个视角定义维度我一般会把维度分成两类。第一类是地震学意义上的物理维度P波与S波的到时差这是判定震中距最硬的数据震动加速度峰值(PGA)和速度峰值(PGV)用来估算烈度震级、震源深度、发震时刻则决定破坏力。第二类是工程意义上的可信度维度台站设备状态是否在线、信号是否饱和、背景噪声是否偏高、同一区域是否有多个台站同时触发。这两类维度缺一不可前者负责“该不该报警”后者负责“这次报警可不可信”。把这套理解落到表结构上大概长这样维度名称类型单位采集来源报警用途p_s_diffdouble秒波形识别模块估算震中距pgadoublegal加速度计判断地面运动强度magnitudedouble级震级估算模块定级参考depthdoublekm震源定位模块判定破坏范围station_countint个台站状态管理器判定多台站一致性snrdoubledB信噪比分析排除低质量信号注意这里没有把“是否超过阈值”作为维度因为阈值是规则层的产物不是原始观测值。建模阶段只保存事实不做判定这样后面调整规则时不用回刷历史数据。2.2 用 Java record 定义不可变观测数据在 Java 17 及以上版本我用 record 来承载这类原始观测值。record 自带 equals、hashCode 和 toString适合作为队列消息和数据流中的不可变对象。下面是核心数据结构public record SeismicObservation( String stationId, // 台站ID Instant occurredAt, // 事件发生时间 UTC double pga, // 峰值加速度单位 gal double pgv, // 峰值速度单位 cm/s Double psDiff, // P波S波到时差单位秒可能为空 Double magnitude, // 估算震级可能为空 double depth, // 震源深度单位 km double snr, // 信噪比单位 dB int stationCount // 当前接入且上报该事件的台站数 ) {}创建观测对象时我只用工厂方法不做任何业务判断保证这个类纯粹是一个传输载体。实际项目中record 的字段名最好和前端 JSON 字段保持驼峰一致否则序列化时还要做字段映射。2.3 维度优先级与可信度策略不同维度的响应速度不一样。P波到达后的一两秒内只能拿到初始振动数据此时没有任何后期修正的震级信息。系统必须设计成“先按快维度预判再按慢维度修正”。我常用的做法是给每个维度配一个 ready 标记紧急维度pga、snr、psDiff数据一到就可以参与判定校核维度magnitude、depth、stationCount可能有延迟用于在首次报警后 5 秒内做升级或降级。规则引擎每收到一条有效记录就重新计算一次综合分。分数超过报警线但校核维度还没准备好时先发“预报警”等到校核维度齐了再决定是升级为正式报警还是取消。这套“先快后准”的策略在真实地震预警中使用得非常普遍也是本系统多维度价值最集中的体现。3. 基于线程池与队列的多源数据接入层3.1 为什么不能每个台站一个线程最简单的实现是每个台站建一个线程循环读取数据。但台站数量一旦超过几百线程上下文切换开销会立刻吃掉可用 CPU而且大量 socket 连接阻塞在等待 I/O 上资源利用很低。常见做法是用固定大小的线程池加有界阻塞队列把“数据接入”和“业务处理”彻底拆开。接入层我一般分三层Collector负责从各台站的 TCP/UDP 端口、Kafka topic 或 MQTT 主题读取原始数据Dispatcher把不同来源的数据按照 stationId 一致性哈希分发到处理线程Analyzer真正做报警规则计算的模块。3.2 用 ExecutorService 和 BlockingQueue 搭建生产消费模型int cores Runtime.getRuntime().availableProcessors(); BlockingQueueSeismicObservation queue new ArrayBlockingQueue(CORES * 1000); ExecutorService collectorPool Executors.newFixedThreadPool(4, r - { Thread t new Thread(r, seismic-collector- r.hashCode()); t.setDaemon(true); return t; }); ExecutorService analyzerPool Executors.newFixedThreadPool(MAX(2, cores - 1), r - { Thread t new Thread(r, seismic-analyzer- r.hashCode()); t.setDaemon(true); return t; }); // 采集端模拟 collectorPool.submit(() - { while (!Thread.currentThread().isInterrupted()) { SeismicObservation obs readFromStation(); queue.offer(obs, 100, TimeUnit.MILLISECONDS); } }); // 分析端消费 for (int i 0; i MAX(2, cores - 1); i) { analyzerPool.submit(() - { while (!Thread.currentThread().isInterrupted()) { SeismicObservation obs queue.poll(1, TimeUnit.SECONDS); if (obs ! null) { alertEngine.evaluate(obs); } } }); }这段代码里有两个参数值得单独说明。一个是queue.offer(obs, 100, TimeUnit.MILLISECONDS)阻塞队列满时只等 100 毫秒超时返回 false这样采集线程不会无限期卡死在写队列上可以把丢弃事件计数后继续工作。另一个是cores - 1分析任务是 CPU 密集型给核心数减一是为了留出一个线程给 GC 和采集端避免 CPU 满载时整个 JVM 卡顿。3.3 多源数据对齐等所有台站都到齐再判断同一个地震事件会有多个台站上报。如果每个台站到一条就立刻算综合分就会出现先到的台站权重过高的问题。更稳的方案是给每个事件设置一个时间窗口窗口内等待所有台站数据到达再统一计算。用 CompletableFuture 可以非常简洁地实现批量等待ListCompletableFutureVoid futures stationIds.stream() .map(id - CompletableFuture.runAsync(() - collectData(id), collectorPool)) .toList(); CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])) .orTimeout(3, TimeUnit.SECONDS) .exceptionally(ex - null) .join();orTimeout是 Java 9 引入的到 3 秒还没收齐就直接放弃不让报警判定无限期阻塞。exceptionally把超时异常吞掉然后靠后续的空值判断来降级处理。对于真的需要等全的场景也可以用CountDownLatch但 CompletableFuture 可以天然结合线程池代码更紧凑。3.4 用 Redis 做每台站计数和时间窗去重收到同一台站同一时间的重复报文很常见网络重传或台站重复上送都会导致。我用 RedisTemplate 的 increment 对台站上报次数做计数String key seismic:station: obs.stationId() : toMinute(obs.occurredAt()); Long count redisTemplate.opsForValue().increment(key, 1); if (count ! null count 1) { redisTemplate.expire(key, 65, TimeUnit.SECONDS); } if (count 3) { log.warn(station {} duplicate report, ignored, obs.stationId()); return; }这里increment(key, 1)的返回结果是该 key 自增后的值等于 1 说明是这一分钟内第一条此时才设置 65 秒过期时间。过期时间比窗口多 5 秒是为了避免窗口边界处 key 提前消失。把“去重计数”放进 Redis 而不是 JVM 本地好处是多个应用实例共享同一份计数不会因为负载均衡把同一个台站的请求分散到不同节点后各自计数、各放过三次。4. 报警判定规则引擎与多渠道报警落地4.1 权重综合评分每个维度都有加权分纯靠一两个阈值判断会把多维度设计浪费掉。我习惯把每个维度的观测值映射为 0 到 100 的分值再乘以权重得到综合分。映射函数要在规则引擎里可以热更新方便地震台网调整参数。public class DimensionScorer { private final MapString, Double weights Map.of( pga, 0.35, psDiff, 0.25, snr, 0.20, stationCount, 0.20 ); public double score(SeismicObservation obs) { double pgaScore normalize(obs.pga(), 80, 400); double psScore normalize(obs.psDiff() null ? 0 : obs.psDiff(), 2, 8); double snrScore normalize(obs.snr(), 10, 30); double stationScore Math.min(100, obs.stationCount() * 20); return weights.get(pga) * pgaScore weights.get(psDiff) * psScore weights.get(snr) * snrScore weights.get(stationCount) * stationScore; } private double normalize(double value, double low, double high) { if (value low) return 0; if (value high) return 100; return (value - low) / (high - low) * 100; } }这段逻辑的要点在于权重本身也是维度。站点多但信号弱综合分会偏低信号强但只有孤台分也上不去。实际调参时可以先跑一周历史数据把误报和漏报样本分别画分箱图找到两类样本在当前权重下的分界点再决定阈值。4.2 分级报警与通知策略综合分出来后按区间映射成四级报警不同级别走不同通知渠道。报警等级判定要写在独立类里方便单元测试。综合分区间报警等级通知渠道触发行为0-39无不通知只记录日志40-59蓝色邮件邮件通知值班组60-79黄色短信邮件电话值班群同步推送80-100红色电话短信邮件启动应急电话流程通知渠道我建议用策略模式做不要去写一堆 if-else。每个渠道实现一个AlertNotifier接口再用 Spring 的Component注入进AlertDispatcher。公众号、企业微信、钉钉机器人的 webhook 本质上都是 HTTP POST差别只在消息格式写一个通用HttpNotifier再各自实现buildPayload方法即可。4.3 报警抑制避免同一事件刷屏如果规则引擎每秒收到一条新高分观测就会每秒发一条报警值班手机会被打爆。必须做报警抑制。两个手段同时用第一同类报警合并。以stationId 震中区域 等级为 key在 Redis 中记录最近一次发送时间如果距上次不足 5 分钟则只更新事件计数不重复发送。String alertKey seismic:alert: region : level; Boolean first redisTemplate.opsForValue() .setIfAbsent(alertKey, String.valueOf(System.currentTimeMillis()), 5, TimeUnit.MINUTES); if (Boolean.TRUE.equals(first)) { alertDispatcher.dispatch(level, payload); }setIfAbsent是原子的只会有一个线程拿到 true其他线程拿到 false 后直接静默。这里的 key 过期时间同时也是抑制窗口窗口内重复事件不做二次通知但可以把这个 key 对应的 value 当计数器用 increment 记录累计次数方便事后复盘。第二等级降级。如果红色报警刚发过一次5 分钟内的后续事件的综合分只在相邻等级内波动就把第二次报警降一级发送。这个比简单丢弃更稳值班人能感知“还有后续活动”又不会因为重复红色报警而麻痹。5. 报警延迟压测与参数调优技巧5.1 模拟并发台站上报测量端到端延迟系统上线前我会做一个简单的并发压测用 JMeter 或直接写 Java 并发程序模拟 200 个台站同时上报同一地震事件记录从 first report 到红色报警发出的间隔。压制后的关注指标有两个一个是 p99 延迟也就是 99% 的报警在多少毫秒内触发另一个是边界值每隔 5 分钟窗口边缘是否出现丢失。java -jar stress-client.jar \ --threads 200 \ --interval 50 \ --events 1000 \ --target http://localhost:8080/seismic/ingest--events 1000表示模拟 1000 条观测记录--interval 50表示每 50 毫秒发一条。压测时观察线程池活跃度如果活跃线程长期占满cores - 1说明消费速度跟不上生产速度优先调整队列容量而不是加大线程数。5.2 Redis 线程池与连接池参数联动很多系统报警延迟源头不在计算逻辑而在连接池等待。Jedis 默认 maxTotal 过小时高并发上报会排队等连接单次报警延迟直接翻几倍。我一般把连接池 maxTotal 配成analyzerPool 线程数 × 2minIdle 配成线程数的一半避免突发流量时 Redis 连接动态创建带来的毛刺。压测时还要留意业务线程和 Redis 连接是否互相争抢 CPU。如果分析线程把 CPU 全部占完GC 停顿会拉长报警延迟随即出现长尾。JVM 参数加-XX:ActiveProcessorCount4可以强制让 ForkJoinPool 和 GC 都按 4 核计算防止容器配额和 CPU 实际可见核数不一致导致的线程数膨胀。5.3 用时间窗切片代替全局计数规避热点 keyRedis 计数 key 如果只用一个固定 key比如seismic:alert:regionA所有台站的抑制判断都打在这个 key 上单 key 的访问量会变成分布式系统的热点。我建议把计数 key 按分钟切片seismic:alert:regionA:202606101430每个 key 只承担一分钟内的判定量。过期时间设为 5 分钟加expire在创建时顺手设置不影响正常使用。配合前面说的setIfAbsent每台机器每次判断只产生一次网络往返Redis 也完全没有评估压力。5.4 规则参数热更新的工程技巧报警规则参数别硬编码在 Java 类里放到配置中心或数据库配置表里改权重不用重启服务。我用的是 Spring 的ConfigurationProperties配合配置中心推送规则引擎每次评分前从本地缓存读取权重副本。更新时先用线上一半流量验证新权重确认误报率不升再全量生效。权重变了之后历史报警记录里综合分会和当时的实际判断不一致所以每条报警要把当时的维度原始值和所用权重序列化进报警记录事后查问题才说得清。边界值验证上我通常会构造两组模拟数据一组 P 波弱但台站密集另一组 P 波极强但只有孤台。这两组数据如果按学科直觉应当都触发黄色报警那么当前权重和阈值就不需要回调如果一组触发蓝色、一组触发红色说明权重要往失衡方向修正。把这几组验证数据写成 JUnit 参数化测试每次改参数后自动跑一遍比上线后靠值班反馈发现误报要省事得多。本文还有配套的精品资源点击获取