尧图网页设计 
简介一套基于B/S架构的网络投票系统源码面向需要实现线上投票功能的学习者、开发者和相关专业课程的实践环节。系统采用浏览器/服务器模式用户通过浏览器即可参与投票核心逻辑与数据存储由服务器端处理支持100以内的并发请求适合中小规模活动与教学演示。后台管理模块覆盖投票创建、选项编辑、结果统计、系统配置等完整流程同时包含登录认证与权限控制确保只有授权人员可进行管理操作。压缩包共56个文件大小仅116KB以26个asp动态页面为主体配合mdb数据库存储投票数据css与js负责界面样式和前端交互gif/jpg作为图标素材txt与htm文档提供安装方法及功能说明结构清晰、便于按需修改。已有197人学习下载资源附有安装方法、功能简介和Readme说明可辅助快速部署登录、密码管理及各类admin页面代码为理解B/S架构下的用户认证与后台管理提供了可直接参考的示例。 做网络投票系统那阵子我接到过不少类似需求——有的客户想要企业内部评优投票有的想搞校园十佳歌手打榜还有的是事业单位要做民意测评。这些需求听起来简单真正落地时五花八门的坑全冒出来了。今天这篇就以“B/S方式网络投票系统”这个项目为例把从设计到实现再到排错的完整链路捋一遍给打算自己做投票系统的朋友一份能直接抄作业的参考。1. 项目概述与整体思路1.1 为什么网络投票系统首选B/S架构B/S全称Browser/Server浏览器/服务器架构。说白了就是用户打开浏览器输入网址就能用不需要安装任何客户端。这个特性放在投票场景里可以说是“天作之合”——投票参与者的电脑水平参差不齐有的是领导、有的是客户、有的是上了年纪的评审专家你不可能要求每个人去装一个Exe或者App。浏览器谁都会用地址栏敲个网址、点几下鼠标就完事。对比C/S架构B/S能直接省掉两大麻烦一是客户端分发和更新成本C/S模式下客户端一升级所有参与者的电脑都得跟着升级这一轮通知下来光电话沟通就能打爆你的手机。二是跨平台问题办公室里Windows和macOS并存太正常了C/S模式你得做两套客户端B/S模式下浏览器天然屏蔽了底层系统的差异。当然B/S也不是没有问题它的短板在于实时交互能力弱于C/S服务端压力也更集中。但投票系统本身没有高频实时操作投票动作发生频率低、数据量小这点短板完全在可接受范围内。1.2 投票系统的三个核心需求缺一不可一个合格的网络投票系统无论用在哪都逃不开下面这三个核心需求第一个是投票活动的配置管理。你要能创建多个投票活动每个活动可以设置标题、起止时间、投票规则单选还是多选、每人可投几票、候选人/选项列表。没有这个系统就是一个死板的功能页换一次投票就得改一次代码那完全不可维护。第二个是投票过程的高效执行与防重复控制。投票动作本身要在点击后秒级反馈不能让用户提交了之后转圈等半天。防重复则是投票系统最敏感的生命线同一人多投、刷票一旦发生一次整个投票的公正性就会被质疑活动直接失去意义。第三个是结果的实时统计与展示。主办方需要随时看到当前各选项的得票数和趋势曲线最好还能按设定规则自动排名。很多项目做完基础的投票执行就宣布验收结果主办方一看后台啥都没有还得自己拿Excel拉数据那体验就很糟糕了。围绕这三点去做开发整个项目的框架就清楚了。我见过不少失败案例都是因为一开始只盯着“能投票”这个表面功能结果做到中期发现缺这个少那个返工成本高得吓人。2. 技术选型与核心设计2.1 前后端技术栈的选择逻辑技术选型上我建议遵循“稳健优先、新人友好”的原则。投票系统不存在什么“高并发峰值百万”的场景除非你给顶流明星做打榜但那种需求一般也不会用通用投票系统解决所以不需要上来就搬出微服务全家桶。后端我用的Spring Boot2.x版本就够。Spring Boot的优点是开箱即用内置Tomcat打包成一个Jar就能跑部署时一条命令搞定。Java生态成熟后续加功能也好扩。如果你更熟悉Node.js用Express或者Egg.js也行但工程化能力相对弱一些在权限控制和事务管理上要自己多留神。前端我建议用Vue 3 Element Plus。Vue的响应式机制对投票这种有大量动态数据刷新的页面非常友好Element Plus则是现成的组件库表格、按钮、表单这些能省一大半UI工作量。注意这里我刻意回避了前后端分离的“过度设计”——也就是说管理后台和投票前台可以共用一套前端工程只是通过路由和权限控制来区分这样能少维护一套代码脑子里少装一套逻辑。数据库选型上MySQL 8.0是稳妥选择。投票系统的数据量不大但事务要求高——不好意思又是那个“防止超投”的问题。MySQL的ACID事务能力在这个场景下刚好够用配合Redis做缓存层性能完全不是瓶颈。2.2 数据库设计的核心表是怎么定出来的我习惯从“一个投票活动从生到死”的完整流程来倒推表结构。整个系统至少需要四张核心表投票活动表vote_activity记录活动基本信息和配置。字段包括活动名称、开始时间、结束时间、投票方式单选/多选、每人限投次数按活动维度、是否允许查看实时结果、创建人ID、状态未开始/进行中/已结束。投票选项表vote_option记录每个活动下的候选选项。关键字段所属活动ID、选项名称、选项描述、排序号、附加信息比如候选人的照片URL、初始票数、状态。这里要注意给每个选项存一个“初始票数”字段有时候主办方会把线下票折算后加进来有它就方便多了。投票记录表vote_record这是最核心的一张表记录每一次投票动作。关键字段活动ID、选项ID、投票人标识、投票时间、投票渠道、IP地址。这张表会随着投票进行持续膨胀必须给活动ID和投票人标识建联合索引不然数据一多查询会极慢。用户表system_user管理后台的登录账号。投票前台不一定需要登录但管理后台必须有权限控制。字段就不赘述了标准的一套账号、密码BCrypt加密存储明文存密码就是给自己埋雷、角色、状态。四张表的关系不难理解活动表是一级节点下面挂着选项表投票记录表同时关联活动表和选项表谁被投了一票就插一条记录用户表负责后台登录和投票记录没有直接关联。2.3 防重复投票的三种方案怎么组合最合理防重复投票是整个系统设计中最核心的章节没有之一。我见过太多直接在Sql里UPDATE vote_option SET count count 1 WHERE id ?的朴素写法一旦用户多点两次按钮票数就翻倍了。必须从前端到后端到数据库做三层防护。第一层前端控制。投票按钮点击后立刻置灰同时通过JavaScript在本地Cookie中写入一个标记短时间内禁止再次点击。这一层只能“防君子”因为用户清掉Cookie或者换浏览器就绕过了但至少能挡住90%的误操作。第二层服务端IP限制。后端获取用户的IP地址在一个时间窗口比如24小时内检查该IP是否已经投过票。IP限制的可靠性在大型内网环境中会打折扣——如果公司出口只有一个公网IPNAT后面几百号人都算同一个IP那就麻烦了。所以IP限制策略要灵活最好做成可配置内网环境改用“IPUser-Agent”组合限制公网环境直接限制IP。第三层强一致性的数据库防重。在投票记录表上建立唯一约束把“活动ID投票人标识”作为唯一键。这里有个小技巧——如果投票人标识是手机号那么唯一约束就是针对手机号的如果投票人标识是用户ID登录后投票那就是针对用户ID的。硬性插入重复记录时数据库会直接报错这是最硬的一道防线。三管齐下基本能防住日常会遇到的所有刷票手段。如果您要做的是那种万人级别的投票活动可能还需要引入验证码、滑块等机制但那种场景属于安全攻防范畴了本文先不展开。3. 实操过程与核心环节实现3.1 搭建项目骨架从零跑通整个流程环境准备阶段我列的清单是JDK 8、Maven 3.6、MySQL 8.0、Redis 5.0。后端的骨架用Spring Initializr生成引入Web、MyBatis-Plus、Redis、MySQL Driver这几组依赖即可。这里插一句MyBatis-Plus的代码生成器能直接根据数据库表生成Entity、Mapper、Service、Controller四层代码能省不少重复性的CRUD工作。前端用Vue CLI脚手架创建工程装Element Plus、Axios、Vue Router。交互上设置两个路由/vote投票前台和/admin管理后台后台路由加一个全局前置守卫判断本地有没有存登录token没有就跳登录页。我习惯先把“创建投票活动”的完整链路跑通再去做投票执行。原因是活动配置是后续所有操作的数据源头活动配置搞好了选项维护、投票执行、结果统计都是在这个基础上做加法流程上更顺畅。3.2 投票核心接口的实现与优化投票接口是整个系统的心脏。前端传来两个参数activityId和optionId——给哪个活动投了哪个选项。后端处理逻辑按这个顺序走第一步校验活动状态。查活动表确认当前时间在起止时间范围内活动状态是“进行中”。时间不对直接返回错误信息这个校验必须在后端做千万别依赖前端的倒计时。第二步校验投票次数。按第2节说的三层防重逻辑逐层检查。如果活动配置限定了每人只能投1次那先查投票记录表有没有该投票人的记录有就直接拒绝。这里要注意查询和插入之间要加事务控制否则并发同时进来两条请求还是可能双双通过校验——具体解决方式见第4节。第三步持久化投票数据。先向vote_record表插入一条投票记录再执行UPDATE vote_option SET count count 1 WHERE id ?更新票数。两步操作放在同一个事务里要么都成功要么都失败谁也别想单独生效。第四步同步缓存数据到Redis。得票数这类的热点数据用Redis的INCR命令做自增比直接更新MySQL快得多。但这里有个一致性策略要讲清楚——我用的方案是Redis只做展示层统计最终票数以MySQL为准。投票的时候同步更新两个地方查询统计结果的时候优先读Redis数据延迟在秒级以内对投票系统来说是完全可以接受的。Override Transactional(rollbackFor Exception.class) public VoteResult vote(VoteRequest request) { // 1. 校验活动状态 VoteActivity activity voteActivityMapper.selectById(request.getActivityId()); if (activity null || !进行中.equals(activity.getStatus())) { return VoteResult.fail(投票活动不存在或未开始); } Date now new Date(); if (now.before(activity.getStartTime()) || now.after(activity.getEndTime())) { return VoteResult.fail(不在投票时间范围内); } // 2. 校验投票次数唯一约束兜底 Integer count voteRecordMapper.selectCount(new LambdaQueryWrapperVoteRecord() .eq(VoteRecord::getActivityId, request.getActivityId()) .eq(VoteRecord::getVoterId, request.getVoterId())); if (count activity.getMaxVotesPerPerson()) { return VoteResult.fail(超出个人投票次数限制); } // 3. 插入投票记录 更新票数事务保证 VoteRecord record new VoteRecord(); record.setActivityId(request.getActivityId()); record.setOptionId(request.getOptionId()); record.setVoterId(request.getVoterId()); record.setVoteTime(now); voteRecordMapper.insert(record); VoteOption option voteOptionMapper.selectById(request.getOptionId()); option.setVoteCount(option.getVoteCount() 1); voteOptionMapper.updateById(option); // 4. 同步更新Redis缓存 stringRedisTemplate.opsForHash().increment(vote:activity: request.getActivityId(), option: request.getOptionId(), 1); return VoteResult.success(); }这样一套逻辑下来数据一致性有了响应速度也能保证。Redis的Hash结构存各选项票数查询结果时一次性取出连多次GET都省了。3.3 管理后台活动配置与结果导出的实现要点管理后台是主办方直接操作的部分我的经验是UI可以朴素但功能必须够用。至少包含活动管理增删改查、选项管理维护候选名单、数据统计实时展示票数排名。活动管理的表单里有个细节容易被忽略——时间配置的时区问题。用户在前端选了“2024年11月8日9:00”作为开始时间前端拿到的时间如果不做处理用new Date()格式化后传到后端会带上T字符和时区偏移。我建议前端传标准时间戳给后端后端用LocalDateTime接收并按上海时区解析这样能避免很多“明明设置9点开始结果11点才生效”之类的诡异问题。结果导出功能用EasyExcel就行了一行代码把数据库里的投票记录导出成Excel文件。导出时记得加上导出条件的筛选——按时间范围、按活动、按选项不然主办方拿到一张十万行的总表那也不是他们想要的。4. 常见问题与排查技巧实录4.1 并发场景下“票数超卖”问题的排查思路第一个想讲的问题就是并发超投。现象很好描述用户快速连续点击投票按钮后端的校验逻辑都通过了结果发了三次请求票数涨了三票。第一次遇到这种问题时我先怀疑前端结果发现前端已经把按钮置灰了但用户用脚本模拟请求绕过了前端控制于是问题定位到后端。后端的校验逻辑是“查询-判断-插入”三个步骤天然存在时间窗口。线程A和线程B同时查的时候都发现没有投票记录然后先后执行插入两条记录都进来了。解法是给投票记录表加唯一约束让数据库在约束层面拒绝第二次插入。具体操作建表时给vote_record表加UNIQUE KEY uk_activity_voter (activity_id, voter_id)。插入时用try-catch捕获DuplicateKeyException一旦捕获就说明重复投票了直接返回“投票次数已用完”的提示。把并发冲突下沉到数据库层解决比在应用层加分布式锁简单了不止一个级别——毕竟投票系统没必要为了这个场景引入ZooKeeper或者Redisson。4.2 获取客户端真实IP时为什么拿到的总是服务器IP这是部署阶段的一个高频坑。开发环境测试一切正常部署到服务器后拿到全是一堆内网IP或者0:0:0:0:0:0:0:1。原因在于你用Nginx做了反向代理后端通过request.getRemoteAddr()拿到的其实是Nginx的IP不是客户端的真实IP。要让后端拿到真实IP有两步要配置。第一步Nginx的location块里加上请求头设置proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;第二步后端在获取IP的时候优先从X-Forwarded-For请求头里取。注意网络安全上有一个老话叫“请求头不可信”客户端完全可以伪造X-Forwarded-For。所以在取IP进数据库做防重限制的时候我建议用X-Real-IP而不是X-Forwarded-For——X-Real-IP由Nginx统一覆盖客户端传了也会被Nginx重置掉。4.3 投票活动结束后数据统计对不上账活动结束主办方突然说统计结果和预期不符。这种问题多半出在“修改了投票规则但没重置数据”上。举个例子活动配置的时候允许多选每人可投2票跑到中途主办方受不了了要把规则改成每人1票。如果你直接在活动表上把max_votes_per_person改成1那之前投过2票的人依然是2票但前端按新规则只让他们投1票数据库里的历史记录没有做清理最后统计票数自然对不上。解决思路是涉及投票规则的变更一定要走“新增活动版本”而不是“修改原活动”。后端提供一个“复制活动”的接口把原活动的选项列表复制过来生成一个新的活动ID然后通知主办方后续投票用新活动的二维码或链接。历史数据原样保留新数据干干净净两边都不得罪。4.4 让你少加班写代码的五个避坑建议最后分享几个实操中踩出来的经验都是不用花钱就能买到的教训第一数据表里所有跟时间相关的字段都用datetime类型不用timestamp。timestamp有2038年问题虽然看着遥远但咱做系统的设计底线是把坑留给后人不如自己一次填平。第二投票前台页面的颜色和文案要克制。我看到有人把投票页面做得红红绿绿、动画满天飞结果用户连“提交投票”按钮都找不到。投票是个严肃动作界面越是简洁清晰投票转化率反而越高。第三记得给管理后台加“实时刷新”的开关。默认关闭主办方想看最新数据时点击刷新。有些主办方会把大屏投到会议现场实时模式能提升不少现场氛围感但高频自动刷新会给后端带来无谓的压力。第四备份策略别偷懒。投票期间每天凌晨自动备份一次数据库活动结束前再手动备份一次。真遇到用户数据被误删导致争议的时候一份原始备份就是你保住口碑的最后防线。第五一定一定上线前要压测。不用上重型工具用Jmeter起个线程组50个并发持续跑5分钟观察接口响应时间有没有线性恶化。投票当天服务器崩了这种事朋友圈里年年有人发别让主角变成自己。投票系统这个项目看起来简单但把“配置、执行、统计”这条链路上的细节都做好对工程能力和耐心都是实打实的考验。希望这篇文章能给正在做或打算做这类系统的朋友提供一些参考少走几个弯路。本文还有配套的精品资源点击获取 B/S架构网络投票系统从设计到实现：防重复与并发处理实战
简介一套基于B/S架构的网络投票系统源码面向需要实现线上投票功能的学习者、开发者和相关专业课程的实践环节。系统采用浏览器/服务器模式用户通过浏览器即可参与投票核心逻辑与数据存储由服务器端处理支持100以内的并发请求适合中小规模活动与教学演示。后台管理模块覆盖投票创建、选项编辑、结果统计、系统配置等完整流程同时包含登录认证与权限控制确保只有授权人员可进行管理操作。压缩包共56个文件大小仅116KB以26个asp动态页面为主体配合mdb数据库存储投票数据css与js负责界面样式和前端交互gif/jpg作为图标素材txt与htm文档提供安装方法及功能说明结构清晰、便于按需修改。已有197人学习下载资源附有安装方法、功能简介和Readme说明可辅助快速部署登录、密码管理及各类admin页面代码为理解B/S架构下的用户认证与后台管理提供了可直接参考的示例。 做网络投票系统那阵子我接到过不少类似需求——有的客户想要企业内部评优投票有的想搞校园十佳歌手打榜还有的是事业单位要做民意测评。这些需求听起来简单真正落地时五花八门的坑全冒出来了。今天这篇就以“B/S方式网络投票系统”这个项目为例把从设计到实现再到排错的完整链路捋一遍给打算自己做投票系统的朋友一份能直接抄作业的参考。1. 项目概述与整体思路1.1 为什么网络投票系统首选B/S架构B/S全称Browser/Server浏览器/服务器架构。说白了就是用户打开浏览器输入网址就能用不需要安装任何客户端。这个特性放在投票场景里可以说是“天作之合”——投票参与者的电脑水平参差不齐有的是领导、有的是客户、有的是上了年纪的评审专家你不可能要求每个人去装一个Exe或者App。浏览器谁都会用地址栏敲个网址、点几下鼠标就完事。对比C/S架构B/S能直接省掉两大麻烦一是客户端分发和更新成本C/S模式下客户端一升级所有参与者的电脑都得跟着升级这一轮通知下来光电话沟通就能打爆你的手机。二是跨平台问题办公室里Windows和macOS并存太正常了C/S模式你得做两套客户端B/S模式下浏览器天然屏蔽了底层系统的差异。当然B/S也不是没有问题它的短板在于实时交互能力弱于C/S服务端压力也更集中。但投票系统本身没有高频实时操作投票动作发生频率低、数据量小这点短板完全在可接受范围内。1.2 投票系统的三个核心需求缺一不可一个合格的网络投票系统无论用在哪都逃不开下面这三个核心需求第一个是投票活动的配置管理。你要能创建多个投票活动每个活动可以设置标题、起止时间、投票规则单选还是多选、每人可投几票、候选人/选项列表。没有这个系统就是一个死板的功能页换一次投票就得改一次代码那完全不可维护。第二个是投票过程的高效执行与防重复控制。投票动作本身要在点击后秒级反馈不能让用户提交了之后转圈等半天。防重复则是投票系统最敏感的生命线同一人多投、刷票一旦发生一次整个投票的公正性就会被质疑活动直接失去意义。第三个是结果的实时统计与展示。主办方需要随时看到当前各选项的得票数和趋势曲线最好还能按设定规则自动排名。很多项目做完基础的投票执行就宣布验收结果主办方一看后台啥都没有还得自己拿Excel拉数据那体验就很糟糕了。围绕这三点去做开发整个项目的框架就清楚了。我见过不少失败案例都是因为一开始只盯着“能投票”这个表面功能结果做到中期发现缺这个少那个返工成本高得吓人。2. 技术选型与核心设计2.1 前后端技术栈的选择逻辑技术选型上我建议遵循“稳健优先、新人友好”的原则。投票系统不存在什么“高并发峰值百万”的场景除非你给顶流明星做打榜但那种需求一般也不会用通用投票系统解决所以不需要上来就搬出微服务全家桶。后端我用的Spring Boot2.x版本就够。Spring Boot的优点是开箱即用内置Tomcat打包成一个Jar就能跑部署时一条命令搞定。Java生态成熟后续加功能也好扩。如果你更熟悉Node.js用Express或者Egg.js也行但工程化能力相对弱一些在权限控制和事务管理上要自己多留神。前端我建议用Vue 3 Element Plus。Vue的响应式机制对投票这种有大量动态数据刷新的页面非常友好Element Plus则是现成的组件库表格、按钮、表单这些能省一大半UI工作量。注意这里我刻意回避了前后端分离的“过度设计”——也就是说管理后台和投票前台可以共用一套前端工程只是通过路由和权限控制来区分这样能少维护一套代码脑子里少装一套逻辑。数据库选型上MySQL 8.0是稳妥选择。投票系统的数据量不大但事务要求高——不好意思又是那个“防止超投”的问题。MySQL的ACID事务能力在这个场景下刚好够用配合Redis做缓存层性能完全不是瓶颈。2.2 数据库设计的核心表是怎么定出来的我习惯从“一个投票活动从生到死”的完整流程来倒推表结构。整个系统至少需要四张核心表投票活动表vote_activity记录活动基本信息和配置。字段包括活动名称、开始时间、结束时间、投票方式单选/多选、每人限投次数按活动维度、是否允许查看实时结果、创建人ID、状态未开始/进行中/已结束。投票选项表vote_option记录每个活动下的候选选项。关键字段所属活动ID、选项名称、选项描述、排序号、附加信息比如候选人的照片URL、初始票数、状态。这里要注意给每个选项存一个“初始票数”字段有时候主办方会把线下票折算后加进来有它就方便多了。投票记录表vote_record这是最核心的一张表记录每一次投票动作。关键字段活动ID、选项ID、投票人标识、投票时间、投票渠道、IP地址。这张表会随着投票进行持续膨胀必须给活动ID和投票人标识建联合索引不然数据一多查询会极慢。用户表system_user管理后台的登录账号。投票前台不一定需要登录但管理后台必须有权限控制。字段就不赘述了标准的一套账号、密码BCrypt加密存储明文存密码就是给自己埋雷、角色、状态。四张表的关系不难理解活动表是一级节点下面挂着选项表投票记录表同时关联活动表和选项表谁被投了一票就插一条记录用户表负责后台登录和投票记录没有直接关联。2.3 防重复投票的三种方案怎么组合最合理防重复投票是整个系统设计中最核心的章节没有之一。我见过太多直接在Sql里UPDATE vote_option SET count count 1 WHERE id ?的朴素写法一旦用户多点两次按钮票数就翻倍了。必须从前端到后端到数据库做三层防护。第一层前端控制。投票按钮点击后立刻置灰同时通过JavaScript在本地Cookie中写入一个标记短时间内禁止再次点击。这一层只能“防君子”因为用户清掉Cookie或者换浏览器就绕过了但至少能挡住90%的误操作。第二层服务端IP限制。后端获取用户的IP地址在一个时间窗口比如24小时内检查该IP是否已经投过票。IP限制的可靠性在大型内网环境中会打折扣——如果公司出口只有一个公网IPNAT后面几百号人都算同一个IP那就麻烦了。所以IP限制策略要灵活最好做成可配置内网环境改用“IPUser-Agent”组合限制公网环境直接限制IP。第三层强一致性的数据库防重。在投票记录表上建立唯一约束把“活动ID投票人标识”作为唯一键。这里有个小技巧——如果投票人标识是手机号那么唯一约束就是针对手机号的如果投票人标识是用户ID登录后投票那就是针对用户ID的。硬性插入重复记录时数据库会直接报错这是最硬的一道防线。三管齐下基本能防住日常会遇到的所有刷票手段。如果您要做的是那种万人级别的投票活动可能还需要引入验证码、滑块等机制但那种场景属于安全攻防范畴了本文先不展开。3. 实操过程与核心环节实现3.1 搭建项目骨架从零跑通整个流程环境准备阶段我列的清单是JDK 8、Maven 3.6、MySQL 8.0、Redis 5.0。后端的骨架用Spring Initializr生成引入Web、MyBatis-Plus、Redis、MySQL Driver这几组依赖即可。这里插一句MyBatis-Plus的代码生成器能直接根据数据库表生成Entity、Mapper、Service、Controller四层代码能省不少重复性的CRUD工作。前端用Vue CLI脚手架创建工程装Element Plus、Axios、Vue Router。交互上设置两个路由/vote投票前台和/admin管理后台后台路由加一个全局前置守卫判断本地有没有存登录token没有就跳登录页。我习惯先把“创建投票活动”的完整链路跑通再去做投票执行。原因是活动配置是后续所有操作的数据源头活动配置搞好了选项维护、投票执行、结果统计都是在这个基础上做加法流程上更顺畅。3.2 投票核心接口的实现与优化投票接口是整个系统的心脏。前端传来两个参数activityId和optionId——给哪个活动投了哪个选项。后端处理逻辑按这个顺序走第一步校验活动状态。查活动表确认当前时间在起止时间范围内活动状态是“进行中”。时间不对直接返回错误信息这个校验必须在后端做千万别依赖前端的倒计时。第二步校验投票次数。按第2节说的三层防重逻辑逐层检查。如果活动配置限定了每人只能投1次那先查投票记录表有没有该投票人的记录有就直接拒绝。这里要注意查询和插入之间要加事务控制否则并发同时进来两条请求还是可能双双通过校验——具体解决方式见第4节。第三步持久化投票数据。先向vote_record表插入一条投票记录再执行UPDATE vote_option SET count count 1 WHERE id ?更新票数。两步操作放在同一个事务里要么都成功要么都失败谁也别想单独生效。第四步同步缓存数据到Redis。得票数这类的热点数据用Redis的INCR命令做自增比直接更新MySQL快得多。但这里有个一致性策略要讲清楚——我用的方案是Redis只做展示层统计最终票数以MySQL为准。投票的时候同步更新两个地方查询统计结果的时候优先读Redis数据延迟在秒级以内对投票系统来说是完全可以接受的。Override Transactional(rollbackFor Exception.class) public VoteResult vote(VoteRequest request) { // 1. 校验活动状态 VoteActivity activity voteActivityMapper.selectById(request.getActivityId()); if (activity null || !进行中.equals(activity.getStatus())) { return VoteResult.fail(投票活动不存在或未开始); } Date now new Date(); if (now.before(activity.getStartTime()) || now.after(activity.getEndTime())) { return VoteResult.fail(不在投票时间范围内); } // 2. 校验投票次数唯一约束兜底 Integer count voteRecordMapper.selectCount(new LambdaQueryWrapperVoteRecord() .eq(VoteRecord::getActivityId, request.getActivityId()) .eq(VoteRecord::getVoterId, request.getVoterId())); if (count activity.getMaxVotesPerPerson()) { return VoteResult.fail(超出个人投票次数限制); } // 3. 插入投票记录 更新票数事务保证 VoteRecord record new VoteRecord(); record.setActivityId(request.getActivityId()); record.setOptionId(request.getOptionId()); record.setVoterId(request.getVoterId()); record.setVoteTime(now); voteRecordMapper.insert(record); VoteOption option voteOptionMapper.selectById(request.getOptionId()); option.setVoteCount(option.getVoteCount() 1); voteOptionMapper.updateById(option); // 4. 同步更新Redis缓存 stringRedisTemplate.opsForHash().increment(vote:activity: request.getActivityId(), option: request.getOptionId(), 1); return VoteResult.success(); }这样一套逻辑下来数据一致性有了响应速度也能保证。Redis的Hash结构存各选项票数查询结果时一次性取出连多次GET都省了。3.3 管理后台活动配置与结果导出的实现要点管理后台是主办方直接操作的部分我的经验是UI可以朴素但功能必须够用。至少包含活动管理增删改查、选项管理维护候选名单、数据统计实时展示票数排名。活动管理的表单里有个细节容易被忽略——时间配置的时区问题。用户在前端选了“2024年11月8日9:00”作为开始时间前端拿到的时间如果不做处理用new Date()格式化后传到后端会带上T字符和时区偏移。我建议前端传标准时间戳给后端后端用LocalDateTime接收并按上海时区解析这样能避免很多“明明设置9点开始结果11点才生效”之类的诡异问题。结果导出功能用EasyExcel就行了一行代码把数据库里的投票记录导出成Excel文件。导出时记得加上导出条件的筛选——按时间范围、按活动、按选项不然主办方拿到一张十万行的总表那也不是他们想要的。4. 常见问题与排查技巧实录4.1 并发场景下“票数超卖”问题的排查思路第一个想讲的问题就是并发超投。现象很好描述用户快速连续点击投票按钮后端的校验逻辑都通过了结果发了三次请求票数涨了三票。第一次遇到这种问题时我先怀疑前端结果发现前端已经把按钮置灰了但用户用脚本模拟请求绕过了前端控制于是问题定位到后端。后端的校验逻辑是“查询-判断-插入”三个步骤天然存在时间窗口。线程A和线程B同时查的时候都发现没有投票记录然后先后执行插入两条记录都进来了。解法是给投票记录表加唯一约束让数据库在约束层面拒绝第二次插入。具体操作建表时给vote_record表加UNIQUE KEY uk_activity_voter (activity_id, voter_id)。插入时用try-catch捕获DuplicateKeyException一旦捕获就说明重复投票了直接返回“投票次数已用完”的提示。把并发冲突下沉到数据库层解决比在应用层加分布式锁简单了不止一个级别——毕竟投票系统没必要为了这个场景引入ZooKeeper或者Redisson。4.2 获取客户端真实IP时为什么拿到的总是服务器IP这是部署阶段的一个高频坑。开发环境测试一切正常部署到服务器后拿到全是一堆内网IP或者0:0:0:0:0:0:0:1。原因在于你用Nginx做了反向代理后端通过request.getRemoteAddr()拿到的其实是Nginx的IP不是客户端的真实IP。要让后端拿到真实IP有两步要配置。第一步Nginx的location块里加上请求头设置proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;第二步后端在获取IP的时候优先从X-Forwarded-For请求头里取。注意网络安全上有一个老话叫“请求头不可信”客户端完全可以伪造X-Forwarded-For。所以在取IP进数据库做防重限制的时候我建议用X-Real-IP而不是X-Forwarded-For——X-Real-IP由Nginx统一覆盖客户端传了也会被Nginx重置掉。4.3 投票活动结束后数据统计对不上账活动结束主办方突然说统计结果和预期不符。这种问题多半出在“修改了投票规则但没重置数据”上。举个例子活动配置的时候允许多选每人可投2票跑到中途主办方受不了了要把规则改成每人1票。如果你直接在活动表上把max_votes_per_person改成1那之前投过2票的人依然是2票但前端按新规则只让他们投1票数据库里的历史记录没有做清理最后统计票数自然对不上。解决思路是涉及投票规则的变更一定要走“新增活动版本”而不是“修改原活动”。后端提供一个“复制活动”的接口把原活动的选项列表复制过来生成一个新的活动ID然后通知主办方后续投票用新活动的二维码或链接。历史数据原样保留新数据干干净净两边都不得罪。4.4 让你少加班写代码的五个避坑建议最后分享几个实操中踩出来的经验都是不用花钱就能买到的教训第一数据表里所有跟时间相关的字段都用datetime类型不用timestamp。timestamp有2038年问题虽然看着遥远但咱做系统的设计底线是把坑留给后人不如自己一次填平。第二投票前台页面的颜色和文案要克制。我看到有人把投票页面做得红红绿绿、动画满天飞结果用户连“提交投票”按钮都找不到。投票是个严肃动作界面越是简洁清晰投票转化率反而越高。第三记得给管理后台加“实时刷新”的开关。默认关闭主办方想看最新数据时点击刷新。有些主办方会把大屏投到会议现场实时模式能提升不少现场氛围感但高频自动刷新会给后端带来无谓的压力。第四备份策略别偷懒。投票期间每天凌晨自动备份一次数据库活动结束前再手动备份一次。真遇到用户数据被误删导致争议的时候一份原始备份就是你保住口碑的最后防线。第五一定一定上线前要压测。不用上重型工具用Jmeter起个线程组50个并发持续跑5分钟观察接口响应时间有没有线性恶化。投票当天服务器崩了这种事朋友圈里年年有人发别让主角变成自己。投票系统这个项目看起来简单但把“配置、执行、统计”这条链路上的细节都做好对工程能力和耐心都是实打实的考验。希望这篇文章能给正在做或打算做这类系统的朋友提供一些参考少走几个弯路。本文还有配套的精品资源点击获取