【谈一谈】Redis是AP还是CP?
再说这个话题之前,这里的是
AP和CP不是"A片"和"C骗"啊 !~哈哈哈,就离谱,博文后面我会解释下的我说下自己对
Redis的感觉,我一直很好奇Redis,不仅仅是当缓存用那么简单,包括的它的底层设计所以,思考再三,我决定先从
Redis基础开始写(基础是王道!~万丈高楼平地起,我米开始!~嘿嘿)
一、总纲图:
二、什么是CAP?
要想谈一谈我们本文的主题
AP和CP,可能有的小伙伴会说: 这我也不是 怎么熟悉啊!那么我们先复习下大名鼎鼎 的
CAP理论
CAP理论
看下面的这张图,我们会发现
CAP对应的三个单词 【建议自己画画图,印象深刻】
C: 一致性(Consistency)--
- 每次读取都会收到最新的写入数据或者错误信息
- (
注:这里面的一致性 ,指的是强一致性,不是市面上所说的所有节点在相同时间看到是一样的数据)
A:可用性(Availability)--
- 每个请求都会收到非错误 地响应,但是这个响应的信息不保证 是最新的 ,只保证可用
P:分区容错性(Partition Tolerance)--
- 就是网络节点间丢弃或者延迟一定数量(就是任意数量 )信息,也不影响大局 ,系统还是能够正常运行
好了,我们言归正传,回到我们的主题上面
三、为啥说Redis是AP?不是CP?
我们知道,
Redis是一个开源的内存数据库,且是执行单线程处理但是网上,若是喜欢读博客的小伙伴,会发现很多人说这样一句话:
- 单机的
Redis是CP的,集群的REDIS是AP的
这句话真的对吗? 大家在看下文前,倾思考思考!~我当时读到第一反应就是疑惑,于是我就去查询大量资料
有的人说:
CAP是针对分布式场景中,如果是单机REDIS,就压根儿和什么分布式不着边,都没P了!!还说哈AP和CP??- 在单机的
REDIS中,应为只有一个实例,那么他的一致性是有保障的,如果这个节点挂了,就没有可用性可言了,所以他是CP系统我在这里说下,以上两个观点都特么错的!!!以偏概全,混淆是非!~就是AP!!
~哈哈哈!你可能会说:我去,那你证明啊,这特么为啥是错的啊!,别急嘛!我们往下读,让你心服口服,嘿嘿
REDIS是AP的理由
第一点: 一致性
我们都知道,
REDIS的设计目标 是高性能 ,高扩展 和高可用性 ,而且
REDIS的一致性模型是最终一致性:(什么意思呢?)就是在某个时间点读取的数据可能不是最新的,但殊途同归 ,最终会达到一致的状态
为什么Redis无法保持强一致性??
主要原因: 异步复制
-
因为
Redis在分布式的设计中采用的是异步复制,者导致在节点之间存在数据在同步和延迟不一致的情况存在 -
换句话说:
- 当某个节点的数据发生改变 ,
Redis会将这个节点的修改操作发送给其他节点进行同步~(这是正常步骤,没毛病是不,我们继续往下看) - 但是 (不怕一万,就怕万一来了,哈哈哈)因为网络传输的延迟 ,拥塞等原因,这些操作没有立即被被其他节点收到和执行,
- 从而产生节点之间数据不一致的情况!!!
- 当某个节点的数据发生改变 ,
-
抛开上面的影响点 ,
节点故障对Redis的一致性影响也是很大的举个例子:
当一个节点宕机 时,这个节点的 数据就可能同步不到其他节点上,这就会导致数据在节点间不一致
你可能有疑惑?那
Redis不是有哨兵和复制等机制吗?但是,问题就是但是,哈哈~这些机制是能提高系统的可用性和容错性,能完全解决吗?
~(你没看错,就是完全解决 ,能吗??)不能吧,自己主观推下也能想到那种万一场景吧!!!
你说既然异步 不行,那么我就用同步机制 就不好了!!不就是
CP了???~no!no!NO !哈哈哈,年轻人,想的太简单了哈!~
我们看看官网是怎么说的()
-
Redis客户端可以使用WAIT命令请求特定数据进行同步复制 -
使用
WAIT,只能说发生故障 时丢失写操作的概率会大大降低,且是在难以触发的故障模式情况下 -
但是!!
-
WAIT只能确保数据在Redis实例中有指定数量的副本被确认不能将一组
REdis转换为具有强一制性的CP系统 -
什么意思?
在故障转移 期间,由于
Redis的持久化配置 ,当中已确认的写操作 ,仍然可能会丢失
完结!~
士不可以不弘毅,任重而道远,诸君共勉!~