先问一句：你要的是投票，还是一次公开压测
每次有人跟我说“我们搞个在线投票吧，很简单”，我都会想起那句程序员的老话：这需求一天能写完，一年也修不完。在线投票看着像个增删改查的小玩具，真跑起来才发现，它是并发、风控、审计、合规四件套的合集，还带一点社会学味道。评选活动一上线，链接进了群，流量就跟早高峰的地铁一样涌过来。
本文不聊“怎么提升参与感”这种玄学，只从技术开发者视角拆解：在线投票系统在高峰期会死在哪、刷票怎么防、多地域部署时延迟与公平怎么平衡。
一、并发峰值下，最先崩的往往不是数据库
很多人的第一反应是分库分表、加缓存、堆机器。可实际压测下来，最先出问题的通常是“重复投票判断”这一环——每个请求都要查一次“这个人投过没”，数据库的 QPS 直接被击穿。常见解法是把唯一约束前移到 Redis：用用户 ID 加活动 ID 做 key，用 SETNX 一步完成判断，剩下的交给异步落库。代价是要接受短暂的不一致，所以评选结果的展示最好走“准实时”而不是“强实时”。页面写一句“数据延迟数秒”没人会骂你，但票数跳回去了会。
另一个坑是写扩散。投票系统如果每次投票都触发排名重算、榜单刷新、消息推送，峰值时就会连锁雪崩。经验做法是：投票只写“票的流水”，榜单由定时任务或消息队列消费者增量聚合，前端缓存几秒。评选榜单不是股票行情，晚两秒没人损失。
二、刷票与评选：一场永不落幕的猫鼠游戏
只靠 IP 限流的在线投票，基本等于在门口挂了块“欢迎来刷”的牌子。移动网络下大量用户共享出口 IP，一刀切会误伤正常用户；而机刷党换 IP 的成本比你还低。靠谱的评选系统通常会叠加几层：设备指纹、行为特征（点击间隔、页面停留、滑动手势的分布）、账号权重，以及投票时间分布的异常检测。单一维度都能被绕过，组合起来才有意义。
还有个更省事的思路：把“投票”和“评选”分开。大众投票决定入围，专业评审决定名次，权重明确写进规则页。这样既降低了对单票真实性的苛求，也让刷票的收益没那么大。技术风控和规则设计，最好一起做。
三、多地域部署：延迟、时区与“最后一秒投票”
如果投票活动的参与者分布在不同地区，投票系统的接入层就要考虑就近接入：用 CDN 加速静态资源，动态请求按地域路由到最近的节点，票数最终汇总到中心存储。直接收益是投票请求的 RTT 从几百毫秒压到几十毫秒，体验从“点了没反应”变成“点了就成”。
麻烦在于截止时间。评选规则写的是“某日 24:00 截止”，但服务器分布在不同时区，用户手机上的时间也可能不准。正确做法是：截止时间统一用 UTC 存储，由服务端判定，前端只做展示；同时给最后几分钟留足余量，避免节点间时钟漂移造成“有人投进去了、有人没投进去”。跨地域的数据落地还要考虑合规，用户信息尽量就近存储、最小化收集。
四、可审计的票：把公平写成可验证的代码
技术团队最容易忽略的一件事，是给运营和参选方留一条“查账”的路。投票系统至少要能回答三个问题：这一票是谁投的（脱敏后可追溯）、什么时候投的、为什么被判为无效。把这些写成追加式、不可篡改的日志，事后可导出核对，评选的公信力才不是一句口号。
顺带一提，日志别只写成功。被风控拦下的请求同样要落盘，否则一旦有人质疑“我明明投了”，你连证据都拿不出来。
五、结论：把评选当成一次公开压测
在线投票、评选这类需求，本质是把系统的并发能力、风控能力和透明度同时暴露在公众面前。对开发者来说，最实用的心态是：别把它当活动页，当成一次公开压测来准备——压测脚本先跑一遍，防刷策略先灰度，榜单延迟先跟运营说清楚。做到这几点，投票系统就算不能百分百公平，至少能百分百解释得清。