1. 项目缘起一次线上投票活动的幕后思考最近我们团队刚刚结束了一个名为“2022年度‘闪耀材料’十大学生线上投票”的项目。虽然项目标题听起来很常规就是一次校园或行业内的评选活动但真正做下来才发现里面门道不少。从技术架构的选型、防刷票机制的设计到用户体验的打磨、活动数据的复盘每一个环节都值得拿出来细细聊聊。这篇文章我就以一个实际操盘手的身份和大家分享一下这次线上投票项目从零到一再到平稳落地的全过程希望能给未来需要策划类似活动的朋友一些实实在在的参考。这次活动的核心目标很明确在一个特定的群体比如材料科学与工程相关专业的学生、科研爱好者或行业新人中通过公开、公平、公正的线上投票评选出十位年度最具代表性的“闪耀”学生。听起来简单但“线上投票”这四个字背后隐藏着流量预估、并发压力、安全防护、体验流畅度等一系列技术与非技术的挑战。我们不仅要确保活动能顺利跑起来还要让它跑得稳、跑得安全最终能产出可信赖的结果。2. 技术选型与架构设计为什么是这套组合拳接到项目需求后第一个要决定的就是技术栈。这不是一个简单的信息展示页面而是一个带有强交互投票、高实时性票数显示、且对安全性和稳定性要求极高的活动系统。市面上现成的投票SaaS工具很多为什么我们最终选择了自主开发这里面的考量远不止“定制化”那么简单。2.1 核心需求拆解与技术挑战首先我们罗列了核心需求与对应的技术挑战高并发投票与实时计数活动在宣传期后可能会在短时间内如最后几小时迎来投票高峰。系统必须能承受住突发流量并且票数更新要近乎实时地反馈给前端用户延迟不能太高。复杂且严格的防刷票机制这是投票活动的生命线。我们需要防范机器刷票、人工重复刷票、代理IP池攻击等多种作弊手段。规则可能需要在活动期间动态调整。候选人管理与展示需要有一个后台方便运营人员上传、编辑候选人信息照片、简介、成果等前端则需要有美观、清晰的展示页面可能涉及分页、搜索、排序等功能。用户投票资格验证如何界定“学生”身份是通过学号邮箱验证还是关联校内系统验证流程既要保证真实性又不能过于繁琐劝退用户。数据统计与风控后台运营人员需要实时监控投票趋势、地域分布、设备指纹等信息以便及时发现异常并干预。成本与开发效率项目有预算和时间限制需要在有限的资源内达成最好的效果。基于以上挑战直接使用轻量级表单工具或仅靠前端静态页面是远远不够的。我们需要一个完整的前后端分离架构。2.2 我们的技术栈决策经过团队内部的几轮讨论我们确定了以下技术方案前端Vue.js 3 TypeScript Vite。选择Vue 3是因为其组合式API在构建复杂交互组件时更灵活TypeScript能极大提升代码的健壮性和可维护性尤其是在处理投票业务逻辑和接口数据时。Vite作为构建工具提供了极快的热更新和构建速度能提升开发体验。UI框架Element Plus。它基于Vue 3组件丰富设计规范能快速搭建出美观且一致的后台管理系统和前端展示页面节省了大量从零设计组件的时间。后端Node.js (Koa框架) TypeScript。Node.js擅长处理I/O密集型的高并发场景这与投票业务大量的读、写数据库操作非常匹配。Koa框架轻量、优雅中间件机制非常适合用来层层封装投票业务逻辑如参数校验、身份验证、防刷过滤等。数据库PostgreSQL。为什么不是更简单的MySQL或者更快的Redis我们需要关系型数据库来保证事务性如投票日志记录必须同时成功或失败PostgreSQL的JSONB字段类型非常好用可以灵活地存储一些动态的候选人扩展信息或风控元数据。同时我们用Redis作为缓存和计数器。所有候选人的实时票数都存在Redis里利用其INCR命令实现原子性递增确保在高并发下票数绝对准确。数据库只做票数的定时持久化比如每分钟同步一次。部署与运维使用Docker进行容器化通过Nginx做反向代理和负载均衡部署在云服务器上。监控方面接入了简单的日志服务和进程监控。注意这套技术栈并非唯一解。对于更大型的活动可能会考虑用Go或Java做后端用消息队列削峰。但对于我们这次预估峰值在万人级并发的活动Node.js Redis的组合已经完全够用且在开发效率上优势明显。3. 防刷票体系构建一场没有硝烟的攻防战防刷票是本次项目的重中之重也是技术投入最多的部分。我们构建了一个多层次的防御体系而不是依赖单一规则。3.1 基础防御层常规限制策略这一层是所有投票系统都会做的目的是提高普通刷票的成本。IP限制同一个IP地址在24小时内只能对同一候选人投一票。这是最基础的规则但很容易被代理IP绕过。设备指纹前端通过收集用户浏览器、屏幕分辨率、字体、Canvas指纹等信息生成一个简易的设备ID。同一设备在24小时内限投一票。这比单纯依赖IP更进了一步。Cookie验证投票成功后在用户浏览器设置一个带有过期时间的Cookie在有效期内禁止再次投票。验证码在投票动作前增加图形验证码或滑动拼图验证。可以有效拦截初级自动化脚本。我们选择了体验相对较好的滑动验证在检测到可疑行为如短时间内同一IP多次请求投票接口时才会触发。3.2 核心防御层基于业务逻辑的深度规则这一层需要结合我们的业务特点“学生”投票来设计。投票资格验证我们采用了“学号邮箱验证”的方式。用户投票前需输入其所在院校的官方邮箱通常是xxx.edu.cn后缀系统会向该邮箱发送一个一次性验证链接。用户点击链接确认后才获得投票资格并且该邮箱在整个活动期间只能投一次票。这从根本上确保了投票者身份的真实性成本极高。投票行为分析时间频率模型正常用户投票会浏览候选人信息投票间隔是随机的。如果系统检测到来自同一IP或设备指纹的投票请求间隔极其规律如每秒一次则会进入风控观察名单。投票分布模型正常用户通常只会为自己熟悉的几位候选人投票。如果一个邮箱验证后的账号在极短时间内给所有候选人都投了票这种行为极其异常。地域跳跃模型通过IP解析地理位置。如果一个“用户”在几分钟内投票IP从北京跳到广州再跳到上海这显然不是真人行为。关联图谱分析这是更高级的防御。我们将每次投票的元数据IP、设备指纹、邮箱域名、投票时间等关联起来。如果发现大量投票都指向少数几个邮箱域名可能是临时邮箱服务或者大量不同的设备指纹却来自同一个IP段机房IP即使它们单个看起来都绕过了基础限制但关联起来就能发现集群作弊的特征。3.3 实时监控与人工审核后台所有的风控规则都不是百分之百准确的可能存在误伤如共用校园网出口IP的同学。因此一个强大的后台至关重要。我们开发了一个实时监控面板展示实时总票数曲线与投票速率。可疑投票行为警报如频率异常、地域跳跃。按IP段、设备指纹、邮箱域名的投票统计TOP榜。每一张票的详细风控标签如“触发IP限制”、“设备指纹重复”、“验证邮箱域可疑”。运营人员可以在这个后台查看被风控规则拦截的投票并进行人工复核。对于确认为误伤的可以手动放行。对于确认的刷票不仅该票作废其关联的所有投票通过关联图谱发现都可以被批量标记无效。实操心得防刷票是一个动态过程。活动开始前我们预设了规则活动进行中我们通过监控后台发现了新的刷票模式比如利用某些海外云服务器的IP就迅速在后台添加了针对该IP段的规则。所以风控系统一定要留有可动态配置规则的接口。4. 高并发下的性能优化让票数“实时”跳动用户投完票最期待的就是看到票数1。这个“实时”体验对技术有要求。我们的方案是异步写入 内存计数 定时持久化。投票接口处理流程用户前端发起投票请求。后端依次通过防刷票层层校验。校验通过后首先向Redis发送命令INCR candidate:[id]。这个操作是内存操作微秒级完成票数立即更新。然后后端将这条投票记录包含用户匿名ID、候选人ID、时间戳、风控元数据等推入一个消息队列我们用了Redis的List结构模拟简单队列。接口立即返回成功给前端前端随即去查询最新的票数同样从Redis读。有一个独立的数据落库服务从队列中消费投票记录批量插入到PostgreSQL数据库中。同时它也会定期如每分钟将Redis中的最新票数同步到PostgreSQL的候选人主表里。为什么这么做用户体验极致流畅用户感知到的投票成功只经历了Redis的INCR操作速度极快。数据库压力解耦最耗时的数据库写入操作被异步化数据库不会因为投票高峰而被击垮。即使落库服务暂时有延迟也不影响用户投票和查看实时票数。保证数据可靠性投票记录进入队列后即使程序重启数据也不会丢失确保最终一致性。前端优化票数显示防抖在候选人列表页我们并没有做全局的、每秒轮询的实时更新那样对服务器压力太大。我们只在用户完成投票后主动更新相关候选人的票数。在排行榜页面我们设置了每30秒一次的低频轮询。CDN加速静态资源所有前端代码、图片、字体等都托管在CDN上加速全球访问。候选人图片懒加载列表页只加载可视区域内的候选人图片大幅提升首屏速度。5. 运营后台设计与活动复盘一个易用的运营后台能省去开发人员一半的麻烦。我们的后台基于Element Plus开发主要包含以下模块候选人管理CRUD操作支持富文本编辑简介上传图片并自动裁剪压缩。投票监控即前面提到的实时数据面板是运营人员的“作战指挥中心”。用户反馈与申诉处理设立了通道让被误伤的用户可以提交申诉后台能直接关联到其被拦截的投票记录进行处理。活动配置可以动态修改活动开始/结束时间、投票规则说明文案、以及调整部分风控规则的阈值比如临时将同一IP的投票间隔限制从24小时调整为12小时。活动复盘活动结束后我们导出了所有数据进行了多维度分析投票时间分布发现投票高峰集中在晚上8点到10点以及活动截止前最后3小时。这验证了我们的并发预案是必要的。候选人票数来源分析通过分析给每位候选人投票的用户邮箱域名可以粗略看出该候选人的“影响力辐射范围”是否与其实验室、学校相符作为结果可信度的辅助参考。风控效果报告整个活动期间风控系统自动拦截了约占总请求数15%的可疑投票经过人工复核其中约95%被确认为作弊行为。误伤率控制在0.5%以下并通过申诉渠道及时修复。6. 踩坑实录与经验总结没有项目是一帆风顺的这次我们也踩了几个坑坑一验证邮件被当作垃圾邮件最初我们用的发送服务商和邮件模板比较随意导致大量验证邮件进入了用户的垃圾箱。后来我们做了以下改进配置SPF、DKIM、DMARC等DNS记录提升发件人信誉。优化邮件模板减少商业推广用语增加活动官方标识。将发送服务切换至更专业的邮件发送平台如SendGrid或阿里云邮件推送它们有更好的送达率管理。坑二Redis内存告警活动初期我们把每个候选人的详细信息和票数都放在Redis里并且设置了不过期。随着访问量增大内存占用飙升。我们很快调整了策略Redis只存候选人的ID和票数这种简单的键值对。候选人详情信息文字、图片URL由后端从数据库获取并加上一层短期缓存如5分钟。设置Redis最大内存限制和淘汰策略volatile-lru。坑三前端静态资源更新后用户缓存问题活动进行中我们紧急修复了一个前端样式BUG并发布。但部分用户浏览器缓存了旧文件导致问题依旧。我们通过在Vite构建输出的文件名中注入[contenthash]实现了只有当文件内容改变时文件名才会变从而强制浏览器获取新资源。同时在Nginx配置中对静态资源设置合适的缓存控制头。个人体会做线上投票活动技术上的“稳”和“准”只是基础。更重要的是对活动规则的透明化设计以及与参与者的良好沟通。我们提前发布了详细的投票规则和防刷票说明设立了申诉渠道这些“非技术”措施极大地提升了活动的公信力减少了后续的争议。技术是实现目标的工具而活动的成功最终取决于它是否赢得了用户的信任。