计数器的最佳实践是存 Redis，每次启动时统计存量数据吗？用 MySQL 的触发器每次操作都实时写盘影响高并发写性能，用 Redis 断电没写盘会导致计数不准

[D0n9]

在说什么？

[ZhLTE]

多搞几台服务器，做集群，定时检测是否断电，定时同步状态，定时持久化数据备份

[drymonfidelia]

@D0n9 例如每个商品订单量之类的计数器，如果下单时+1 会增加查询数量

[shuax]

既然 redis 断电不写盘，那为什么 mysql 能写盘。

[IvanLi127]

上 redis 集群，每个节点独立供电。

[Chinsung]

这种一般是 redis 没有就从 DB 读，然后有的话就 redis 里加加，定时任务或者 mq 这些异步机制去做同步吧，不过这样本质和 redis 的 aof 其实就是只处理这个值的而已，开销少很多，因为 aof 本身是所有写都记录的，如果你的计数器更新频繁，断电了你的部分更新大概率还在 buffer 里，肯定没写盘
一致性要求高点，可以 redis 里加完，丢一条 mq 更新 db ，要么 mq 里直接记着当前值，要么消费 mq 的时候去 redis 查一下再更新 db 的值，保证下不要往小更新或者注意下更新时间就行
一致性要求再高点，那就 db 不存数值，每次启动 count 订单数到 redis 里去维护

[wxf666]

@Chinsung #6

1. 会不会多个请求，同时发现 redis 里没有，又都从 DB 读，导致多次消耗，却只有一次记录呢？

2. 感觉楼主不是关注一致性问题，而是 redis 持久性没得到保证问题。。

[fuis]

这个问题，可以换高性能 SSD 解决；如果还是不想落盘，服务器可以增加 UPS ，断电的有通知，用电池的电量撑到落盘结束再下电。

[Chinsung]

@wxf666 #7
1. 这种没有银弹的，如果访问频率不高，那么就允许这部分性能突刺，如果高，就要考虑预热方案
2. 这个场景下持久化失败或者持久化的延迟，带来的就是一致性问题啊，redis 这种 aof 的异步写不可能保证内存和硬盘强一致的，本身 mysql 就是考虑这种权衡做了 trade-off ，你如果既要又要，那么得针对这种场景定制一个持久化方案了

其实还有个办法，把硬盘的性能提升到支持足够低的 aof 延迟并且修改下 aof 的策略，或者单独拆一个 redis 出来专门搞这个 key ，这样在量不大的情况下，或许可以满足当下的场景