一、前言
Redis 提供了5种数据类型:String(字符串)、Hash(哈希)、List(列表)、Set(集合)、Zset(有序集合),理解每种数据类型的特点对于redis的开发和运维非常重要。
备注: 按照分析顺序,本节应该说道有序集合对象了,但是考虑到有序集合对象的底层实现中使用到了跳跃表结构,避免在分析有序集合时造成突兀,所以本节先来看看 redis 中跳跃表结构的具体实现。
1. CAP 的由来
要理解 CAP,首先我们要清楚,为何会有人提出 CAP?他提出 CAP 是为了解决什么问题?
时间回到 1985 年,彼时,后来证明了 CAP 理论的 Lynch 教授此时给当时的 IT 界来了一记惊雷:
她通过不可辩驳的证明告诉业界的工程师们,如果在一个不稳定(消息要么乱序要么丢了)的网络环境里(分布式异步模型),想始终保持数据一致是不可能的。
这是个什么概念呢?就是她打破了那些既想提供超高质量服务,又想提供超高性能服务的技术人员的幻想。
这本质是在告诉大家,在分布式系统里,需要妥协。
但是,如何妥协?分布式系统里到底应该怎么权衡这种 trade-off?
我们可以想象一下,在 CAP 定理提出之前,没有这些方向性的指引,在设计和实施分布式系统时该有多么混乱。一套分布式系统是由多个模块组成的,这些模块本身可能由不同的开发人员去完成。然而,对于这些人,在公共层面,竟然没有一个原则去指导他们该怎么完成这套功能。
比如,我们在同步两个节点的数据时,如果发生了错误,到底我们应该怎么做呢?如果没有统一的标准和方向,那很可能在一套分布式系统中的不同模块,会出现不同的处理情况。
假设一套系统,由 A、B 两个模块构成。
A 模块的设计理念是:节点间出现了问题,它可能会选择不断的重试,一直等到节点通信恢复。
而 B 的设计理念是:节点间出现了问题,它断开就是了,可能最多就记录下状态,等以后处理。
可是,当 A、B 之间出现了通信怎么办?那会出现 A 往 B 发请求,出问题会不断重试。而 B 往 A 发请求,出问题则直接断开的情况。
当然,在后面我们会说明,CAP 的理念在实际工程中,会允许这种不一致。可是,那种不一致是提前设计好和规划好的,是根据实际数据的重要性和业务需求做的妥协,而不是这种混乱的妥协。
所以,IT 界的人们就一直在摸索,试图找到一些纲领去指导分布式系统的设计,这一找就找了 15 年。
2000 年时,Eric Brewer 教授在 PODC 会议上提出了 CAP 理论,但是由于没有被证明过,所以,当时只能被称为 CAP 猜想。这个猜想引起了巨大的反响,因为 CAP 很符合人们对设计纲领的预期。
在 2002 年后,经过 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 猜想后,CAP 理论正式成为了分布式系统理论的基石之一。
2. CAP 到底是什么
CAP 定理表达了一个分布式系统里不可能同时满足以下的三个特性:
2.1. C:数据一致性
什么是数据一致性?咋一看真的很让人糊涂,一致性是什么?是指数据能一起变化,是能让数据整齐划一。
那么问题又来了,数据何时会变化?数据怎么才能被称为一起变化?我们现在来回答这些问题,当我们搞清楚了这些问题,那么对数据一致性就会有了清晰的理解。
首先第一个问题,数据何时会一起变化?
答案是:仅且仅当包含数据的服务,收到数据更新请求的时候,数据才会发生变化。而数据更新请求则仅包括数据的增、删、改这三种请求,而这三种请求又被统称为写请求。所以,数据只有在写请求的时候才会发生变化。
那我们来回答