用Redis搞在线票数管理，实时更新又方便，系统咋搭建和优化

用Redis来管理在线票数,比如给一个热门活动投票，或者给直播里的主播送人气值，核心思路就是利用Redis两个最大的本事：一是所有数据都在内存里，读写速度飞快；二是它提供了超级好用的原子操作命令，下面就直接说怎么搭和怎么让它更稳当。

系统搭建：怎么把票数“放”进Redis

最开始,别想太复杂，最直接的招数就是为每个投票对象（比如一个选手，或者一件商品）在Redis里设置一个键（Key），键的名字要有意义，vote:activity123:player456，表示“活动123号里选手456的得票数”，这个键对应的值（Value）就是一个简单的数字，记录票数。

当有人投票时,最关键的一步来了：不能用“先读取当前票数，再加一，最后写回去”这种老方法，因为在高并发下，很多人同时做这三步，会丢票，这时候就要用Redis的原子命令 INCR（增加1）或者 INCRBY（增加指定数量），这个命令的执行是不会被打断的，保证每张票都只算一次，这是整个系统的稳定性和数据一致性是至关重要的，根据IBM开发者手册的观点，在分布式系统中，原子操作是确保数据一致性的基石，Redis的INCR命令正是这样的原子操作，它能完美解决并发计数时的竞争问题。

优化进阶：应对高并发和复杂场景

如果只是一个小活动,上面那招就够了，但如果像春运抢票或者顶流明星打榜那样，每秒有几十万甚至上百万的请求，就得继续优化了。

1. 写操作太多，Redis扛不住怎么办？—— 批量写入 即使Redis再快，每秒百万次的INCR命令对它也是巨大压力，而且网络开销也很大，这时候可以用“批处理”的思路，根据Oracle数据库最佳实践指南中常提到的批处理原则，将多个操作合并可以减少I/O损耗，我们可以先在应用程序的内存里做一个累加器，在服务器内存里维护一个计数器，每收到100张票，才通过 INCRBY vote:activity123:player456 100 命令一次性更新到Redis，这样压力就降到了原来的百分之一，这有个小风险：如果服务器在累加到100张之前突然重启，内存里还没提交的票就丢了，所以这个方法适合对少量数据丢失不那么敏感的场景（比如人气值），如果是金融交易就不能这么干。

   

2. 不仅要投票，还要记录谁投了票防刷—— 利用Set集合 为了防止同一个人重复投票，我们需要记录投票人ID，Redis的 SET 集合天生适合干这个，因为它能自动去重，投票时，在一个事务里执行两条命令：先用 SADD vote:activity123:voters 用户ID 尝试将用户ID加入投票者集合，这个命令会返回1（表示成功新增）或0（表示该用户已存在），如果返回1，再执行 INCR 给选手加票，为了保证这两步的原子性，可以把它们包在Redis的 MULTI/EXEC 事务里，确保要么都成功，要么都失败。

3. 数据持久化：防止Redis重启后数据丢光 Redis的数据都在内存里，如果服务器断电，所有票数就清零了，这是灾难性的，所以必须开启持久化功能，Redis主要有两种方式：

   • RDB（快照）：隔一段时间（比如5分钟）把整个数据库拍个快照存到硬盘上，优点是恢复速度快，文件紧凑，缺点是可能会丢失最近几分钟的数据。
   • AOF（追加日志）：把每一个写命令都记录到一个日志文件里，这样即使服务器宕机，重启后重新执行一遍日志里的命令，就能恢复数据，可以配置为每秒同步一次，这样最多只丢一秒的数据。 根据微软Azure缓存文档的建议，通常的做法是两者同时开启，用AOF来保证数据安全性，用RDB来做快速恢复和备份，这样就在性能和可靠性之间取得了很好的平衡。

4. 容量和性能瓶颈—— 使用集群 单个Redis实例的内存和性能是有上限的，当数据量巨大或者并发超高时，就需要用 Redis Cluster（集群），集群会把数据自动分片到多个Redis节点上，这样数据可以分散存储，请求压力也分摊了，系统的容量和性能就能水平扩展，搭建和维护集群比单机复杂，但这是应对超大规模系统的必由之路。

总结一下，用Redis搞票数管理，核心就是“内存速度”+“原子操作”，搭建时直接用INCR命令，优化时，根据场景选择对策：用批量写入抗高并发，用Set集合+事务防刷票，用RDB+AOF持久化保数据不丢，最后用集群来突破单机瓶颈，这样一步步下来，一个既能实时更新又能扛住巨大流量的票数系统就成型了。