Redis为什么需要强一致？

有人说，开源Redis的最终一致性已经能满足大部分应用场景，也有人说，多副本的强一致代价太大，没有必要实现。要笔者说，其实弱一致性已经不满足很多应用场景的诉求。怎么，不信？请听笔者娓娓道来。

1.不一致带来的困扰

1.1 秒杀变秒崩
分享一个电商秒杀活动中限流器的例子，在电商的秒杀活动中，为了扛住前端对数据库的超大流量冲击，一般使用两种方案来保护系统，一个是缓存，另一个则是限流。缓存这个容易实现，只需要在数据库前加一层缓存服务器，而对于限流来说，最简单的可以使用Redis的计数器来实现限流功能。

具体来说，假设我们需要对某个接口限定流量为5000QPS，即每秒钟访问的次数不能超过5000。那么我们可以这么做：在一开始的时候设置一个计数器counter为5000，并且过期时间为1s，即1s后计数器失效。每当一个请求过来的时候，counter的值减1，判断当前counter的值是否等于0，如果等于，则说明请求次数过多，直接拒绝请求。如果counter计数器不存在，则重置计数器为5000，开始新一秒的接口限流，注意并发情况下计数器需要加锁。

正常情况下，这种方案不会出现问题，但是针对这种秒杀活动，不怕一万，就怕万一，万一Redis突然宕机怎么办，那岂不是限流器形同虚设，所有流量全部涌向后端的数据库，瞬间系统崩溃。此时聪明的你肯定会想到，给Redis搞一个备用服务器不就解决了，主服务器如果宕机，备用服务器顶上。没错，这种方案是对的，但是只正确了一半。为什么呢，如下图所示。

当给Redis配置从服务器之后，如果主服务器出现宕机，可以立刻切换到从服务器，但是由于开源Redis主从服务器之间的数据是异步复制的，如果网络不畅，经常发生主从数据不一致，如果此时主服务器发生宕机，切换到从服务器之后，因为限流器的判断出错，流量压力很容易超出阈值，一下子涌向数据库服务器，同样会造成系统崩溃。

仔细探究这个问题产生，根因是在于开源Redis的一致性机制为弱一致性，在某些时间内，主从副本数据不一致。而要彻底解决这个问题，只有真正的强一致才能解决。

1.2 难以维护的MySQL组件
其实不止Redis，就连大名鼎鼎的MySQL也逃不过弱一致的坑。MySQL的部署中，为了保证高可用性，主从热备份是MySQL常用的部署方式。但是如果发生故障时，仅仅靠MySQL自身的同步机制，是