Redis自增怎么搞得快点儿，优化那些细节别忽略了

第一，网络开销是最大的敌人，能省就省。 你每次发一个INCR命令，Redis服务器处理它可能就花零点几毫秒，但网络来回一次可能就要1-2毫秒，大部分时间其实都花在路上了，优化的首要目标就是减少网络往返。

• 流水线（Pipeline）技术： 这是必杀技，别一个个地发INCR命令，而是把一堆命令攒起来，一次性发给Redis，然后再一次性读取所有的回复，如果你要给100个用户增加积分，用流水线能把100次网络往返压缩成1次，速度提升是几十上百倍的，这就像你下楼取快递，一次取100个包裹，远比上下楼100次要快得多。
• 连接池： 每次操作都新建一个TCP连接，握手过程非常耗时，一定要用连接池，连接池会维护一批“热乎”的连接，你用的时候直接从池子里拿，用完了放回去，避免了频繁创建和销毁连接的开销，这是基础中的基础。

第二，Redis自身的“状态”要健康。 Redis本身跑得不快，你再优化客户端也没用。

• 别让CPU成瓶颈： Redis是单线程干活儿的（指处理命令的核心模块），它特别怕CPU被打满，如果你一台机器上还跑了其他特别耗CPU的进程，比如数据计算、日志分析什么的，和Redis抢CPU，那Redis自然就慢下来了，最好让Redis独占一颗CPU核心，让它安心工作。
• 内存和持久化是重点：
  • 内存不够了？ 这是最致命的问题，一旦内存用满，Redis要么拒绝写入，要么会开始用swap，也就是把数据挪到硬盘上的虚拟内存里，硬盘比内存慢好几个数量级，一旦发生swap，性能会断崖式下跌，务必监控内存使用情况，别让它爆掉。
  • 持久化策略选对： Redis为了数据不丢，需要把数据存到硬盘上（持久化），主要有两种方式：RDB（拍快照）和AOF（记日志）。
    • AOF模式 如果设置成appendfsync always，意思是每写一条命令（比如每个INCR）都立刻刷一次硬盘，这样最安全，但也是最慢的，因为硬盘读写成了瓶颈，对于计数器这种可以容忍少量丢失的数据，完全没必要这么干，通常建议设为appendfsync everysec（每秒刷一次），或者干脆appendfsync no（让操作系统自己决定什么时候刷），这样对性能影响最小。
    • RDB快照 在生成快照（bgsave）的时候，Redis会fork一个子进程来干活，如果你的数据量特别大，fork操作本身可能会因为拷贝内存页表而卡住主线程一会儿，虽然不频繁，但也算是个需要注意的点。

第三，命令和使用姿势要正确。

• 别用错命令： 获取一个key的值，用GET，但如果你想知道一个集合有多少个成员，应该用SCARD，而不是先GET整个集合回来再自己数，那效率天差地别，对于自增，明确用途：INCR是原子性+1，INCRBY可以一次性增加指定整数，如果需要处理小数，用INCRBYFLOAT，用对命令是基本素养。
• 警惕“大key”: 如果一个key对应的value特别大，比如一个list里存了几十万个元素，那么任何操作它（包括删除）都可能引起Redis短暂的卡顿，对于计数器来说，一般不会成为大key，但你要检查一下你的业务，有没有不小心把别的数据结构弄得特别大，从而影响了整个Redis实例的稳定性。
• 过期时间设置： 如果你的计数器是有生命周期的，用EXPIRE设置过期时间，但要注意，Redis淘汰过期key的策略（惰性删除+定期删除）如果碰上大量key同时过期，可能会引起瞬间的延迟，最好给过期时间加个随机抖动，比如统一过期时间设为3600 + random(300)，让它们在1小时左右的时间段内陆续过期，避免集中淘汰。

第四，架构层面想办法。 当单机Redis的性能达到瓶颈时，就要考虑分布式方案了。

• 分片（Sharding）： 把不同的key分散到多个Redis实例上，比如用户ID为奇数的计数器放在实例A，偶数的放在实例B，这样压力就分摊了，很多Redis客户端直接支持分片，或者你可以通过代理中间件（如Twemproxy, Codis）来做，也可以直接用Redis Cluster，这是应对海量计数请求的终极手段。
• 本地缓存+批量上报： 对于一些精度要求不是极高、可以接受一定延迟的计数场景（比如网页点击数），可以在应用服务器本地先累加，比如累加到1000次，再通过一个INCRBY 1000命令更新到Redis，这极大地减少了网络请求次数，但缺点是如果应用服务器重启，本地累加的数据可能会丢失，所以适用于可容忍少量数据丢失的场景。

从快到慢，从易到难：

1. 首选优化网络： 用连接池，必用流水线。
2. 保证Redis本身健康： 给足资源（CPU、内存），调整持久化策略（比如AOF用everysec）。
3. 检查使用细节： 用对命令，避免大key，合理设置过期时间。
4. 最终方案是分而治之： 数据分片到多个实例。

按照这个顺序去排查和优化,你的Redis自增操作速度肯定能上去，很多优化其实不是针对INCR命令本身，而是为整个Redis实例创造一个良好的运行环境。