为提升消保投诉风险的提前识别和处置效率,系统需要建设投诉预警能力。我负责投诉预警模块的后端方案设计与编码实现,包括预警规则配置、定时扫描触发、预警记录生成、邮件通知、预警查看以及数据权限隔离。
技术栈:
Spring Boot 2.7.10、MyBatis-Plus 3.3.2、Redis 6.2、MySQL 8.0.32、Spring Scheduled 定时任务、Redis 分布式锁
核心功能:
预警配置
支持预警规则的增删改查和启停。规则通过数据库配置,包含适用业务、触发条件、预警级别、接收用户或接收角色等信息。触发条件采用数据库配置 + 条件判断的方式实现,避免硬编码,便于后续调整。
预警触发
通过 Spring 自带的 @Scheduled 定时任务,按配置周期扫描投诉数据,匹配已启用的预警规则。命中规则后,根据配置的接收人生成预警记录:接收人如果是用户,直接给该用户生成记录;接收人如果是角色,则给该角色下的所有用户批量生成记录。同时向配置的用户发送邮件通知。应用采用多实例部署,通过 Redis 分布式锁保证同一时刻只有一个实例的任务执行,避免重复触发。
预警查看
提供预警记录列表和详情接口。列表支持分页和按时间、预警级别、处理状态等条件筛选。由于预警记录数据量很大,列表分页采用基于雪花算法 ID 的游标分页方式,通过定位上一页最后一条记录的 ID 来查询下一页,避免 limit 大偏移量带来的性能问题。
数据权限隔离
预警配置侧:预警配置岗角色只能查看和操作自己配置的规则,系统管理员可查看所有人配置。预警查看侧:普通用户只能看自己收到的预警记录,系统管理员可看所有记录。数据权限在查询层统一处理,保证越权不可见。
技术难点与解决:
规则动态化:预警条件不写死在代码里,而是存到数据库,由后端读取配置后执行条件判断,新增或调整规则不需要改代码发版。
多实例定时任务重复触发:应用多实例部署,@Scheduled 会在每个实例上执行。通过 Redis 分布式锁保证同一时刻只有一个实例能获取锁并执行任务,避免同一规则被重复触发、预警记录和邮件重复发送。
角色批量生成预警记录:接收人为角色时,需要给角色下所有用户生成记录。通过先查角色用户列表再批量插入的方式实现,避免逐条插入带来的性能问题。
预警记录数据量大:通过添加合适的数据库索引优化查询条件;列表分页采用基于雪花 ID 的游标分页,利用雪花算法生成的 ID 有序递增特性,直接按 ID 定位下一页数据,显著提升深分页查询速度。
已稳定上线,支撑日常消保投诉预警工作