路演报名投票小程序系统搭建：并发防刷与榜单实时统计实战

很多人对“路演系统”的第一反应是：这不就是个报名工具吗？可真上手做的时候才发现，报名只是开胃菜，投票模块才是最容易让人翻车的重头戏。我自己带过的项目里，凡是“演出报名投票”类的需求，最后十有八九都卡在同一个地方——人一多就慢、票一多就乱、一上线就被刷。这篇文章就把我从零搭建一套路演演出报名投票小程序系统的完整过程拆开讲，包括数据库设计、并发扣名额、防刷投票、榜单实时统计这些核心环节的踩坑记录和最终方案，给正在做课设、毕设或者真实活动运营的朋友一个可以直接抄作业的参考。

1. 项目定位与整体设计思路

1.1 先想清楚系统到底要解决什么问题

很多人的思路是“先做个报名功能，再试试投票”，然后做着做着就发现两边都在迁就，最后哪个都没做好。我建议一开始就摆正定位：这套系统的本质是一场演出赛事的流量管理工具，报名解决的是“谁能来、能来多少人”，投票解决的是“谁表现好、谁该被看见”，这俩是完全不同的业务逻辑。

报名业务的特征是高频写、低并发但怕超卖。几十个名额一瞬间被抢完是常态；投票业务的特征是读多写少、怕作弊，几百上千人盯着同一个榜单刷，访问热点非常集中。把这两个特征想清楚，后面的表结构、缓存策略、接口设计就都有了依据。我当时给自己定了三条业务规则，简化成一句话就是：报名靠“锁”，投票靠“频”，榜单靠“缓”。

1.2 技术选型：为什么最终选了小程序加 Spring Boot

技术选型上我纠结过好几轮。第一版考虑过纯H5，但发现两个痛点：一是演出场景下用户需要快速操作，H5要先扫码再等加载，体验上天然弱于小程序；二是微信生态的原生能力，比如订阅消息通知、openid 唯一标识，H5 很难直接拿到。最终定下微信小程序 + Spring Boot + MySQL + Redis 的组合，这也是目前校园和中小型活动系统比较稳妥的搭配。

这套组合的理由很直接：

• 小程序端天然带微信登录体系，不需要自己做注册登录，同时打开即用、不占内存，用户心理门槛非常低。
• Spring Boot做后端管理逻辑、对接微信接口都比较成熟，社区资料多，遇到问题不容易卡死。
• Redis负责扛高并发的读请求和频率限制，同时用它的有序集合做实时榜单，性能远高于直接查数据库。
• MySQL存最终数据，保证报名记录、投票明细这些核心数据不会丢。

1.3 整体模块划分与核心流程

这套系统我从一开始就拆成了四个一级模块：用户端小程序、管理端后台、后端服务接口、数据库与缓存层。用户端面向报名者和投票者，管理端面向活动主办方，后端服务统一暴露接口，数据库与缓存层承载所有数据读写。

核心业务流有三条：报名流程（浏览活动→微信授权登录→填写报名表单→提交锁定名额→收到报名成功通知）、投票流程（查看节目列表→点击投票→后端校验资格→Redis计数→异步落库）、管理端数据流（查看报名列表→导出名单→查看实时榜单→触发数据刷新）。三条流程互相独立但共用同一套用户体系和活动配置数据，后面所有技术实现都是围绕这三条流程展开的。

2. 报名模块的设计与实现：并发扣名额、防重复、表单设计

2.1 报名信息字段怎么定才能不返工

报名表单的字段设计看似简单，实际上是最容易来回改的东西。我的经验是：能被系统自动获取的字段绝不让人填，能复用的字段绝不单独存。第一版我贪多求全，一股脑放了姓名、学号、学院、手机号、微信号、年级、参赛组别、节目名称，结果用户一提交就懵了，前后端联调也麻烦。

后来我重新梳理，将其分为三类：

• 自动填充字段：用户唯一ID（openid 映射）、微信昵称、头像。这些在用户授权后接口直接返回，不做成表单项。
• 必填业务字段：姓名、手机号、参赛组别、节目名称。这些是主办方真实要用的信息，缺一不可。
• 选填扩展字段：节目简介、指导教师、备注。这部分字段控制 UI 展示为可选项，不校验必填。

核心体验逻辑是：报名表必须“短平快”，三步以内完成。参赛者不是来填问卷的，表单越长流失率越高。我当时实测过，超过 5 个必填项后，报名成功率明显下降。写完字段后我还做了一次校验规则梳理——手机号用正则校验座机和手机两种格式，组别用下拉选择避免脏数据。

2.2 并发抢名额的核心实现：Redis 预扣减加数据库锁兜底

演出类活动最怕“万人同时抢 30 个名额”，这种场景下直接操作数据库判断“剩余名额 > 0”再执行插入，百分百会超卖。我第一版就吃了这个亏：压测时 500 个并发请求进来，名额 50 个，结果成功报名了 63 人。后来改成 Redis 预扣减加数据库锁兜底，问题才彻底解决。

核心逻辑分三步走：

1. Redis 预热：活动创建时把名额总数写入 Redis，key 为activity:quota:{activityId}，值为剩余人数。
2. 预扣减：用户提交报名时先执行DECR命令，如果返回值小于 0，说明名额已满，直接返回“已报满”并执行INCR回补。
3. 数据库落库：预扣减成功后才执行数据库插入，插入时加唯一索引防重复，并用SELECT ... FOR UPDATE锁住活动行做最终校验。

这里有一个非常关键的心得：Redis 预扣减不能用GET判断完再SET，必须用DECR这种原子操作，否则多线程环境下依然会有并发漏洞。Redis 单线程执行命令的特性天然保证了原子性，扣名额这种操作交给它是最省心的。数据库锁兜底是因为 Redis 万一被清空或者重启，库存数据会不准确，所以每次报名还要在 MySQL 里做一次真实剩余名额校验。

2.3 防重复报名：唯一索引与幂等设计

普通做法是在代码里先查报名表再判断“这用户是不是报过了”，但这种方式在并发下完全不靠谱——同一用户同时点了两次提交，两个请求都查到“未报名”，然后两条记录都插进去了。我的解决方案非常直白：在数据库层面加唯一索引。

我设计的报名表registration里，把user_id + activity_id建成唯一索引，这样不管同时来多少个请求，数据库最多只能插入一条。代码里的查重只是用户体验层面的优化，提前提示“您已报名”，真正的防线是索引。

同时接口层加了一层幂等机制：前端提交时生成请求唯一流水号request_id，后端先查 Redis 里有没有处理过这个request_id，没有才执行业务逻辑，处理完把request_id写入 Redis 并设置过期时间。这样即使用户断网重试、手滑连点，也不会产生重复报名数据。

这套组合拳实测下来很稳，压测时 1000 并发请求同一用户的重复提交，最终报名表里只有一条记录，Redis 侧也没有出现负数名额。

2.4 报名模块的异常处理：用户看到友好提示，系统留足排查线索

报名的异常处理我吃了不少亏，第一版是“系统错误”“服务器异常”一类模糊提示，结果用户卡在页面不知所措，我这边也不知道到底发生了什么。后来我专门设计了异常体系：

• 业务异常（名额不足、重复报名、活动未开始）：向前端返回业务码和友好提示，日志里打印业务码。
• 系统异常（数据库挂了、Redis 超时）：统一返回“报名火爆，请稍后重试”，日志里记录完整异常栈，同时发送告警到管理端。
• 降级策略：Redis 不可用时，报名功能自动降级为“数据库直连 + 行锁”模式，保证服务不宕但不保证绝对不超卖。

这里特别要强调降级逻辑的取舍。我当时纠结了一下：Redis 挂了到底要不要继续接报名？最终决定是“降级但是不熔断”，因为演出报名通常是短时高峰，宁可偶尔允许超卖一两个名额让主办方手动调整，也不能让整场活动变成无人能报名。主办方看到超卖也能理解，用户全被挡在门外才是事故。

3. 投票模块的设计与实现：防刷策略、实时榜单、高并发读

3.1 投票规则定义：一开始就把边界条件写死

投票是这套系统里最容易出幺蛾子的地方，业务规则的模糊会给开发埋无数坑。我第一版只有一个简单的规则“每人可投 3 票”，结果上线后各种问题：一个人可以投同一个节目三票吗？投票结束后允许改票吗？半夜被人刷票怎么办？

后来我把规则做了严格定义，直接写进后端配置中心，前后端共用同一套配置：

• 投票资格：只有完成微信授权登录的用户才能投票，游客不可投。
• 投票次数：每场活动限定每人投 3 票，可投给同一节目或不同节目（这里按业务需求设置）。
• 投票窗口期：只有活动处于“投票中”状态才开放投票接口，开始前或结束后一律拒绝。
• 不可撤票：投票成功后不可撤销、不可修改，避免反复变更给统计带来脏数据。

规则写清楚后，后端逻辑就变成了纯校验加计数的流程，不用每个接口都猜“这样改会不会影响其他逻辑”。我最深的一个体会是：投票规则代码本身很简单，难的是规则理解一致。管理端号称“每人每天一次”，用户端理解成“每人整个活动一次”，这种不一致在后端是会炸的。

3.2 防刷票的落地：请求频率、唯一性、异常模型三重防护

防刷是投票模块的重头戏，做好它需要层层递进。我采用的是三层防护模型，每一层拦截不同类型的攻击：

第一层：请求频率控制。单个用户投票接口的调用频率限制在每 5 秒最多 1 次，超出就直接拒绝。实现上用 Redis 记录用户最后一次投票时间戳，配合滑动窗口或令牌桶算法做限流。这一层主要挡的是“脚本连点”这种最原始的攻击。

第二层：用户维度 + IP 维度的行为分析。单账号一天内投票次数超过 50 次直接封禁投票权限；同一 IP 下超过 20 个不同 openid 投票，自动拉入观察名单。这一层挡的是通过批量注册小号刷票的行为。

第三层：异常模型识别。对投票记录做聚合分析，算法层面统计每分钟投票总数，超过历史均值三倍以上触发熔断。比如往日每分钟投票量在 100 上下，突然飙到 1000，系统自动进入“验证模式”，要求投票者先完成滑块验证才能继续投。这个设计在实际运营中很管用——真人用户被拦一下加个验证就过了，刷票机器则很难模拟滑块的轨迹特征。

3.3 实时榜单：为什么不直接查数据库

演出类场景有个特点，评委和观众都盯着实时榜单看，每隔几秒刷新一次。如果每次都去 MySQL 做GROUP BY聚合统计，几千人的活动就可能把数据库打崩。这里就要用到 Redis 的ZSet（有序集合）。

我的实现思路是：

• 每个节目创建一个 key，格式为vote:ranking:{activityId}。
• 用户成功投票后，执行ZINCRBY vote:ranking:{activityId} 1 {programId}。
• 前端榜单接口直接读取ZREVRANGE WITHSCORES，拿到降序排列的前 20 名，毫秒级返回。
• 同时每 10 分钟将 ZSet 的快照同步到 MySQL 的program_vote_count表，用于历史归档和最终结算。

这里一定要提醒：Redis 的 ZSet 是最终一致性方案，万一 Redis 重启且没来得及持久化，榜单数据可能丢失一部分，所以必须配合定期同步。我的方案是每 10 分钟同步一次，活动结束时强制触发一次同步并锁定榜单，保证最终的最终结果与数据库一致。

3.4 投票结果的统计口径与数据校验

投票结束后主办方第一件事就是要最终结果。这里的坑是：线上页面显示的和导出 Excel 里的可能对不上——因为用户投票后 Redis 已经计数了，但数据库异步落库还没完成，两边数据不一致。

我后来加了一套对账机制：

1. 从 MySQL 投票明细表做真正意义上的完整统计（每个节目的准确票数）。
2. 与 Redis ZSet 的当前分数做对比，差额超过 5% 触发告警。
3. 触发告警后自动补偿任务会查询投票明细表重新计算得分，写入 ZSet 中，以保证页面展示的数据修正。

说白了，Redis 扛住了实时展示的高性能需求，但最终的权威数据永远以数据库为准——凡是涉及钱、奖、名额的，绝不能只看 Redis。

4. 后端服务与数据库设计：表结构、接口清单与微信登录

4.1 数据库表结构的关键设计

这套系统我最终落地了 6 张核心表，这里只挑最有代表性的几张讲设计思路：

用户表 user

主键用户 ID，关联微信 openid。注意 openid 必须建唯一索引，同一个微信号在小程序里 openid 是固定不变的，这是整套系统识别用户身份的基石。另外建议单独存一份 unionid 字段备用，如果同一个主体下有多个小程序，unionid 才能打通不同小程序的用户体系。

活动表 activity

存活动基本信息和状态。核心字段包括活动名称、报名开始/结束时间、投票开始/结束时间、总名额、已用名额、活动状态（未开始/报名中/投票中/已结束）。活动状态是驱动整个业务流转的关键，后端接口每次都会校验当前时间与状态的一致性。

报名表 registration

唯一索引设为(user_id, activity_id)，加上唯一的request_id做幂等控制。业务字段包括组别、节目名称、手机号、备注。

投票记录表 vote_record

每一条投票记录都是明细数据，核心字段为投票人 ID、节目 ID、活动 ID、投票时间。建联合索引(activity_id, program_id, user_id)，方便统计某个节目的投票人数，同时防止同一个人给同一节目投多次。

节目表 program

挂载在活动下，存节目名称、表演者、所属组别、封面图等。这里注意节目表和活动表是一对多关系，不要只依赖前端传节目名称，一定要有 program_id 做关联，否则后续统计全部乱套。

4.2 后端接口清单与实现逻辑

接口设计遵从“能用 5 个接口解决的事绝不拆成 8 个”的原则。以下是最终版的接口清单：

• GET /api/activity/{id}：获取活动详情和当前状态
• POST /api/registration：提交报名（幂等校验→Redis 预扣名额→落库）
• GET /api/program/list?activityId=：获取节目列表和实时票数
• POST /api/vote：投票（身份校验→频率校验→Redis 计数→异步落库）
• GET /api/ranking?activityId=：获取实时榜单
• GET /api/admin/registration/list：管理端导出报名名单

每个接口都要做三层校验：参数校验、身份校验（token 中的用户 ID），业务状态校验（活动时间窗口）。校验顺序有讲究——一定要先做身份校验再做业务校验，否则未登录用户请求一次接口就触发一次业务逻辑，容易被刷。

拿投票接口举例，它的最终实现顺序是：

1. 从请求头拿到 token，解析用户 ID。
2. 检查活动状态是否为“投票中”。
3. 检查用户今天已投次数，达到上限直接返回“投票次数已用完”。
4. 校验目标节目是否属于该活动。
5. 执行 RedisZINCRBY增加票数。
6. 放入 MQ 异步队列，最终写入 MySQL 投票明细表。

前四步都是天折回路，第 5 步才是真正的写入，第 6 步异步化解决高并发场景下数据库写压力过大的问题。

4.3 微信登录：code2session 换 openid 的全流程

小程序端调用wx.login()拿到临时code，传给后端，后端再调用微信接口code2session拿到用户的 openid 和 session_key，然后把 openid 与自家用户表匹配，生成自定义 token 返回给前端。后续所有接口请求都带着 token，后端解析 token 拿到用户 ID。

这里有几个关键细节：

• code只能用一次，且 5 分钟内有效，后端必须做防重放校验，同一个 code 被使用两次直接拒绝。
• session_key永远不要返回给前端，它是用于解密敏感信息的，留在后端即可。
• 生成的 token 建议放在 Redis 里并设置过期时间（我设的是 7 天），前端在请求拦截器里统一捕获 401 状态码，自动重新调用wx.login()刷新 token。

我在实际开发中还加了一个小优化：用户进入小程序后先从前端存 localStorage 里的 userInfo 中判断是否已登录，已登录就直接放行；未登录才走wx.login()流程。这样比起每次启动都重新 code2session，请求量能砍掉一大截。

4.4 引入消息队列：投票异步落库的正确姿势

一开始我的方案是投票后同步写 MySQL，结果压测到 200 并发时 MySQL 的连接池就满了，接口耗时飙升到 8 秒。后来改成消息队列异步落库，数据库写入压力顿时被打散。

推荐消息队列从 RabbitMQ 和 RocketMQ 里选一个。RabbitMQ 生态成熟、社区资料多，中小型项目完全够用；RocketMQ 性能更好、事务消息强，适合后续要扩容的场景。我当时选用了 RabbitMQ 的原因是部署简单，一条命令就能跑起来，开发环境调试也方便。

核心逻辑是：投票接口处理完 Redis 计数后，把{activityId, programId, userId, voteTime}封装成一条消息发送到vote.queue；消费者监听队列，批量消费并批量插入数据库。消费者要注意配置手动 ACK 和重试机制，消息处理失败不能直接丢弃，否则投票数据就凭空消失了。

5. 小程序端实现：登录态管理、页面交互、体验优化

5.1 小程序页面结构：三大核心页面一个都不能少

小程序端我最终设计了四个核心页面：首页（活动列表）、活动详情页（含报名入口）、节目投票页、个人中心页。这四页的比例几乎是所有此类小程序的标配，少一个用户使用时就会觉得功能不完整。

首页做的是活动卡片流，展示活动封面、名称、报名状态和剩余名额。活动详情页是重头戏，上面是活动信息，中间是报名按钮，下面展示活动流程说明。这里要注意报名按钮的状态要跟后端活动状态联动：未开始时置灰“尚未开始”，报名中显示“立即报名”，名额满显示“已报满”，活动中显示“投票入口”。四种状态前端要用接口返回的activityStatus字段控制，千万不要写死。

投票页是整个小程序交互最复杂的部分。我的设计是列表页展示节目卡片，每个卡片上有节目名、表演者、实时票数、投票按钮。用户点击投票后，按钮变灰，票数加一，同时顶部的“剩余票数”同步减一。用户当日票数耗尽后，所有按钮统一置灰并提示“今日票数已用完”。

5.2 登录态的管理与请求封装：别再到处写 wx.request

很多新手写小程序，每个页面里都直接wx.request，然后一遍遍处理 token 过期、错误提示、loading 状态，代码冗余到爆炸。我在这个项目里从一开始就封装了统一的请求模块：

• 所有请求统一走request()方法，自动携带 header 中的 token。
• 全局拦截 401 状态码，自动重新登录后重放请求。
• 全局拦截 500 状态码，统一弹出“服务开小差，请稍后再试”的 toast。
• 封装loading参数，传true时自动弹出 loading，请求完成后自动关闭。

封装完成后，每个页面里的业务代码非常干净，比如提交报名只需写这样一段：

const submitRegistration = async () => { const data = { activityId: this.data.activityId, name: this.data.form.name, phone: this.data.form.phone, programName: this.data.form.programName, group: this.data.form.group }; const res = await request({ url: '/api/registration', method: 'POST', data, loading: true }); if (res.code === 0) { wx.showToast({ title: '报名成功', icon: 'success' }); // 刷新活动状态 this.refreshActivityStatus(); } };

5.3 页面数据刷新与状态同步：不要每个按钮都去请求一次接口

节目投票页的票数展示，一开始的笨办法是每 3 秒调一次榜单接口，结果流量耗费严重，体验还卡。后来我改成“本地 + 服务端”双轨状态管理：

• 本地状态：用户进入页面时从接口拉一次初始榜单，渲染到列表；用户自己投票后，本地票数先 +1，按钮立即置灰，给用户即时反馈。
• 服务端状态：管理端后台和用户端榜单每 30 秒才刷新一次真实数据，刷新时以 Redis 为主、MySQL 兜底。

这样用户端操作响应是毫秒级的，后端也不需要面临每秒几千次的轮询请求。要提醒的是，本地优化不能覆盖服务端真实数据，必须每隔一段时间把本地数据和接口数据做一次校准，比如用户在投票页停留超过 30 秒后再进入页面时强制重新拉取榜单。

5.4 体验优化细节：点位提醒、骨架屏、分享卡片

小程序体验上的小事容易积少成多，我至少做了三个改进：

• 报名/投票结果即时反馈：报名成功不是单纯弹个 toast，而是跳转一个专门的报名成功页，页面展示报名编号，并明确指引“投票通道将在活动开始后开放”。这样用户知道自己报上了，也清楚下一步要做什么。
• 骨架屏加载：节目列表页用骨架屏替代传统的转圈 loading，视觉上流畅很多，也让用户感觉页面更快。
• 分享卡片定制：小程序默认分享卡片只有标题和缩略图，我定制了分享文案和图片，用户转发时直接带上活动名称、时间和“点击即可报名”的引导语，裂变效果比默认分享好上好几倍。

6. 管理后台与运营支撑：名单导出、实时榜单、活动风控

6.1 管理后台的定位：数据看板优先，操作功能其次

管理后台是做给主办方用的，他们关心的只有三件事：有多少人报了、榜单什么情况、名单怎么导出来。我把管理后台首页做成了看板风格——顶部是总数卡片，左侧是趋势折线图，中间是实时榜单表格。

报名列表页支持条件筛选（按组别、按报名状态、按关键词检索），支持一键导出 Excel。导出功能我特意做了异步化——数据量大时先在后台生成文件，导好后通知用户下载，避免请求超时。

管理端还有一个重要功能是活动状态的切换开关。主办方可手动将活动从“报名中”切为“投票中”或“已结束”，切换逻辑后端要校验时间合法性，比如报名中切投票中时先检查报名人数是否大于零。

6.2 实时榜单的落库与周期归档

前面提过 Redis ZSet 扛实时榜单，但管理后台最终结算时必须读 MySQL 的权威数据。我在管理后台榜单页面做了一个“归档快照”按钮，点击后触发两个动作：

1. 把 Redis 当前 ZSet 分数同步到 MySQL 的program_vote_count表。
2. 将同步结果写入活动日志表，保留现场快照，防止作弊争议。

归档后管理后台的榜单只从 MySQL 读取，不再依赖 Redis。这样即使后续 Redis 数据丢失，最终结果也不会受影响。我在实际运营中还加了一条规则——活动结束后自动触发归档，不用等主办方手动点按钮。

6.3 活动风控的快速介入：一键冻结与拉黑

投票活动中最容易出现集中爆发刷票的情况。管理后台我专门加了一个“风控操作栏”，包含三个功能按钮：冻结单个用户的投票权限、封禁单个节目 30 分钟、全场投票暂停 10 分钟。这三个操作都是秒级生效的，后端对应的逻辑是：

• 冻结用户：Redis 写一个冻结 key，后续该用户投票时直接拒绝。
• 封禁节目：Redis 写节目状态 key，前端列表该节目按钮置灰，后端投票接口判断节目标记并拒绝。
• 全场暂停：Redis 写活动级暂停 key，投票接口第一个校验就是这个 key，存在即拒绝。

为什么要用 Redis 而不是数据库改字段？因为紧急风控要求秒级生效，Redis 写 key 是 O(1) 操作，而修改数据库还要考虑连接池、事务和主从同步延迟。这是我最想强调的一个经验：应急操作设计必须追求最短路径。

7. 常见问题与排查技巧实录

7.1 报名人数超过名额却显示报名成功

这个问题的根因往往是预扣减与落库之间没有强一致校验。排查时先看 Redis 里剩余名额是否为负数，再看registration表是否有比名额多的记录。解决办法是把预扣减逻辑改成“先DECR校验，再在事务里SELECT ... FOR UPDATE活动行做最终确认”，同时核对activity表的已用名额字段是否有被并发写串。

经验教训是逻辑分层越清晰越容易排查。报名链路是“幂等校验 → Redis 预扣 → SQL 锁校验 → 落库”，每一步失败了都能定位到具体环节。

7.2 用户反映票数投不上，页面上却显示已投票

这类问题最常见的是前端本地状态与后端不统一。用户点了投票按钮，前端立刻票数 +1、按钮置灰，但后端接口因为频率限制或票数耗尽拒绝了，前端没有处理失败回滚。解决方法是前端在投票失败时回滚本地票数和按钮状态，同时给出明确错误提示。我还在请求封装层加了一条规则：业务码非零一律走通用的失败弹窗，避免静默失败。

7.3 微信订阅消息发送失败

我踩过的坑是订阅消息一次性订阅的授权限制。wx.requestSubscribeMessage只能让用户订阅一次，后端发送一次后 token 就失效了。如果用户第二场活动也想收到通知，需要再次发起订阅。我的方案是在报名成功页再次拉起订阅授权，保证用户在需要时完成订阅，而不是在报名入口就提前引导订阅。经验是：任何引导订阅请求都要放在用户“即将获得价值”的时刻，转化率远高于在首页硬推。

7.4 小程序审核被拒的常见原因

演出报名投票类小程序在微信审核时最容易踩的雷是类目选择错误。我用的是“工具 > 信息查询”类目，结果被驳回了两次，因为投票属于典型的社区互动。后来归到“社交 > 社区”类目并补了相关资质说明才通过。另外，凡是涉及用户生成内容（UGC）的小程序都要提供内容审核机制，我在投票文案上加了关键敏感词过滤，并在举报入口做了用户举报功能，才算过关。

7.5 数据统计对不上账：“Redis 显示 2000 票，数据库只有 1800 票”

这种不一致几乎都是异步落库丢失导致的。排查分两步：先看 MySQL 投票明细表里有没有对应的投票记录，再看 MQ 消费日志看消息是否被丢弃。第二步是确认消费者是否配置了手动 ACK——如果没有，消息在服务器重启时会丢失。我的最终方案是消费端做了“幂等 + 补偿”双保险：消费前查重、消费失败进死信队列、定时任务扫死信队列重新投递。

8. 后续扩展方向与个人经验总结

这套系统做完后，我在实际运营中又迭代了好几个版本，这里挑几个值得扩展的方向分享给大家。

方向一：票数加权与小组评分。单纯的观众投票很难反映艺术质量，我给系统加了一套“评委票 + 观众票”双轨制，评委账号由主办方后台手动配置，评委票权重是观众票的 5 倍。实现时只需要在投票接口里增加账号维度的权重字段，Redis 计数时按权重加值即可，改动不大但效果显著。

方向二：报名与签到的打通。很多演出活动线下需要核销签到，我给系统加入了报名成功后生成二维码的功能，主办方用另一部手机扫码即可核销。二维码内容是报名记录的加密 ID，扫码后后端判断是否已核销并返回结果，整个过程不需要引入专门的扫码设备。

方向三：弹幕与实时互动。演出直播时观众可以在小程序里发弹幕，这个功能实现上要换成 WebSocket 长连接或小程序wx.connectSocket，复杂度上了一个台阶。但如果活动本身有直播需求，互动功能的留存效果确实比单纯的投票好很多。

最后再分享一点亲身体会：这类“报名 + 投票”系统单看任何一个功能都不算难，难就难在把两端（用户端和管理端）、三态（未开始、进行中、已结束）、三库（Redis、MySQL、MQ）串成一个闭环，还要时刻提防并发和防刷这两个隐形炸弹。我的建议是动手写代码之前先把活动和投票规则用文字列清楚，哪怕多花一晚上把边界条件写详尽，也比后期返工修 bug 省一百倍时间。希望这篇文章能给准备做类似系统的朋友一个相对完整的技术参考，少走几步弯路。