0x0A.谈谈集群版Redis和Gossip协议
A.1 关于集群的一些基础
单实例Redis架构
注:图片来自网络
集群与分片
客户端分片：这种情况主要是类似于哈希取模的做法，当客户端对服务端的数量完全掌握和控制时，可以简单使用。
中间层分片：这种情况是在客户端和服务器端之间增加中间层，充当管理者和调度者，客户端的请求打向中间层，由中间层实现请求的转发和回收，当然中间层最重要的作用是对多台服务器的动态管理。
服务端分片：不使用中间层实现去中心化的管理模式，客户端直接向服务器中任意结点请求，如果被请求的Node没有所需数据，则像客户端回复MOVED，并告诉客户端所需数据的存储位置，这个过程实际上是客户端和服务端共同配合，进行请求重定向来完成的。
中间层分片的集群版Redis
服务端分片的官方集群版本
注:图片来自网络
A.2 Redis Cluster的基本运行原理
结点状态信息结构
当前集群状态
集群中各节点所负责的slots信息，及其migrate状态
集群中各节点的master-slave状态
集群中各节点的存活状态及不可达投票
Gossip协议的概念
gossip 协议（gossip protocol）又称 epidemic 协议（epidemic protocol），是基于流行病传播方式的节点或者进程之间信息交换的协议。
在分布式系统中被广泛使用，比如我们可以使用 gossip 协议来确保网络中所有节点的数据一样。
gossip protocol 最初是由施乐公司帕洛阿尔托研究中心（Palo Alto Research Center）的研究员艾伦·德默斯（Alan Demers）于1987年创造的。
https://www.iteblog.com/archives/2505.html
Gossip算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致，这充分说明了Gossip的特点：在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，只要这些节可以通过网络连通，最终他们的状态都是一致的，当然这也是疫情传播的特点。
https://www.backendcloud.cn/2017/11/12/raft-gossip/
Gossip协议的使用
Meet 通过「cluster meet ip port」命令，已有集群的节点会向新的节点发送邀请，加入现有集群。
Ping 节点每秒会向集群中其他节点发送 ping 消息，消息中带有自己已知的两个节点的地址、槽、状态信息、最后一次通信时间等。
Pong 节点收到 ping 消息后会回复 pong 消息，消息中同样带有自己已知的两个节点信息。
Fail 节点 ping 不通某节点后，会向集群所有节点广播该节点挂掉的消息。其他节点收到消息后标记已下线。
注:图片来自网络
基于Gossip协议的故障检测
有半数以上的主节点将 node 标记为 PFAIL 状态。
当前节点也将 node 标记为 PFAIL 状态。
0x0B.谈谈对Redis的内存回收机制的理解
Redis作为内存型数据库，如果单纯的只进不出早晚就撑爆了，事实上很多把Redis当做主存储DB用的家伙们早晚会尝到这个苦果，当然除非你家厂子确实不差钱，数T级别的内存都毛毛雨，或者数据增长一定程度之后不再增长的场景，就另当别论了。
为了让Redis服务安全稳定的运行，让使用内存保持在一定的阈值内是非常有必要的，因此我们就需要删除该删除的，清理该清理的，把内存留给需要的键值对，试想一条大河需要设置几个警戒水位来确保不决堤不枯竭，Redis也是一样的，只不过Redis只关心决堤即可，来一张图：
图中设定机器内存为128GB，占用64GB算是比较安全的水平，如果内存接近80%也就是100GB左右，那么认为Redis目前承载能力已经比较大了，具体的比例可以根据公司和个人的业务经验来确定。
笔者只是想表达出于安全和稳定的考虑，不要觉得128GB的内存就意味着存储128GB的数据，都是要打折的。
B.1 回收的内存从哪里来
Redis占用的内存是分为两部分：存储键值对消耗和本身运行消耗。显然后者我们无法回收，因此只能从键值对下手了，键值对可以分为几种：带过期的、不带过期的、热点数据、冷数据。对于带过期的键值是需要删除的，如果删除了所有的过期键值对之后内存仍然不足怎么办？那只能把部分数据给踢掉了。
B.2 如何实施过期键值对的删除
要实施对键值对的删除我们需要明白如下几点：
带过期超时的键值对存储在哪里？
如何判断带超时的键值对是否可以被删除了？
删除机制有哪些以及如何选择？
1.键值对的存储
老规矩来到github看下源码，src/server.h中给的redisDb结构体给出了答案：
typedef struct redisDb {
dict *dict; /* The keyspace for this DB */
dict *expires; /* Timeout of keys with a timeout set */
dict *blocking_keys; /* Keys with clients waiting for data (BLPOP)*/
dict *ready_keys; /* Blocked keys that received a PUSH */
dict *watched_keys; /* WATCHED keys for MULTI/EXEC CAS */
int id; /* Database ID */
long long avg_ttl; /* Average TTL, just for stats */
unsigned long expires_cursor; /* Cursor of the active expire cycle. */
list *defrag_later; /* List of key names to attempt to defrag one by one, gradually. */
} redisDb;
Redis本质上就是一个大的key-value，key就是字符串，value有是几种对象：字符串、列表、有序列表、集合、哈希等，这些key-value都是存储在redisDb的dict中的，来看下黄健宏画的一张非常赞的图：
看到这里，对于删除机制又清晰了一步，我们只要把redisDb中dict中的目标key-value删掉就行，不过貌似没有这么简单，Redis对于过期键值对肯定有自己的组织规则，让我们继续研究吧！
redisDb的expires成员的类型也是dict，和键值对是一样的，本质上expires是dict的子集，expires保存的是所有带过期的键值对，称之为过期字典吧，它才是我们研究的重点。
对于键，我们可以设置绝对和相对过期时间、以及查看剩余时间：
使用EXPIRE和PEXPIRE来实现键值对的秒级和毫秒级生存时间设定，这是相对时长的过期设置
使用EXPIREAT和EXPIREAT来实现键值对在某个秒级和毫秒级时间戳时进行过期删除，属于绝对过期设置
通过TTL和PTTL来查看带有生存时间的键值对的剩余过期时间
上述三组命令在设计缓存时用处比较大，有心的读者可以留意。
过期字典expires和键值对空间dict存储的内容并不完全一样，过期字典expires的key是指向Redis对应对象的指针，其value是long long型的unix时间戳，前面的EXPIRE和PEXPIRE相对时长最终也会转换为时间戳，来看下过期字典expires的结构，笔者画了个图：
2. 键值对的过期删除判断
判断键是否过期可删除，需要先查过期字典是否存在该值，如果存在则进一步判断过期时间戳和当前时间戳的相对大小，做出删除判断，简单的流程如图：
3. 键值对的删除策略
经过前面的几个环节，我们知道了Redis的两种存储位置：键空间和过期字典，以及过期字典expires的结构、判断是否过期的方法，那么该如何实施删除呢？
先抛开Redis来想一下可能的几种删除策略：
定时删除：在设置键的过期时间的同时，创建定时器，让定时器在键过期时间到来时，即刻执行键值对的删除；
定期删除：每隔特定的时间对数据库进行一次扫描，检测并删除其中的过期键值对；
惰性删除：键值对过期暂时不进行删除，至于删除的时机与键值对的使用有关，当获取键时先查看其是否过期，过期就删除，否则就保留；
在上述的三种策略中定时删除和定期删除属于不同时间粒度的主动删除，惰性删除属于被动删除。
三种策略都有各自的优缺点：定时删除对内存使用率有优势，但是对CPU不友好，惰性删除对内存不友好，如果某些键值对一直不被使用，那么会造成一定量的内存浪费，定期删除是定时删除和惰性删除的折中。
Reids采用的是惰性删除和定时删除的结合，一般来说可以借助最小堆来实现定时器，不过Redis的设计考虑到时间事件的有限种类和数量，使用了无序链表存储时间事件，这样如果在此基础上实现定时删除，就意味着O(N)遍历获取最近需要删除的数据。
但是我觉得antirez如果非要使用定时删除，那么他肯定不会使用原来的无序链表机制，所以个人认为已存在的无序链表不能作为Redis不使用定时删除的根本理由，冒昧猜测唯一可能的是antirez觉得没有必要使用定时删除。
4. 定期删除的实现细节
定期删除听着很简单，但是如何控制执行的频率和时长呢？
试想一下如果执行频率太少就退化为惰性删除了，如果执行时间太长又和定时删除类似了，想想还确实是个难题！并且执行定期删除的时机也需要考虑，所以我们继续来看看Redis是如何实现定期删除的吧！笔者在src/expire.c文件中找到了activeExpireCycle函数，定期删除就是由此函数实现的，在代码中antirez做了比较详尽的注释，不过都是英文的，试着读了一下模模糊糊弄个大概，所以学习英文并阅读外文资料是很重要的学习途径。
先贴一下代码，核心部分算上注释大约210行，具体看下：
#define ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP 20 /* Keys for each DB loop. */
#define ACTIVE_EXPIRE_CYCLE_FAST_DURATION 1000 /* Microseconds. */
#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* Max % of CPU to use. */
#define ACTIVE_EXPIRE_CYCLE_ACCEPTABLE_STALE 10 /* % of stale keys after which
we do extra efforts. */
void activeExpireCycle(int type) {
/* Adjust the running parameters according to the configured expire
* effort. The default effort is 1, and the maximum configurable effort
* is 10. */
unsigned long
effort = server.active_expire_effort-1, /* Rescale from 0 to 9. */
config_keys_per_loop = ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP +
ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP/4*effort,
config_cycle_fast_duration = ACTIVE_EXPIRE_CYCLE_FAST_DURATION +
ACTIVE_EXPIRE_CYCLE_FAST_DURATION/4*effort,
config_cycle_slow_time_perc = ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC +
2*effort,
config_cycle_acceptable_stale = ACTIVE_EXPIRE_CYCLE_ACCEPTABLE_STALE-
effort;
/* This function has some global state in order to continue the work
* incrementally across calls. */
static unsigned int current_db = 0; /* Last DB tested. */
static int timelimit_exit = 0; /* Time limit hit in previous call? */
static long long last_fast_cycle = 0; /* When last fast cycle ran. */
int j, iteration = 0;
int dbs_per_call = CRON_DBS_PER_CALL;
long long start = ustime(), timelimit, elapsed;
/* When clients are paused the dataset should be static not just from the
* POV of clients not being able to write, but also from the POV of
* expires and evictions of keys not being performed. */
if (clientsArePaused()) return;
if (type == ACTIVE_EXPIRE_CYCLE_FAST) {
/* Don't start a fast cycle if the previous cycle did not exit
* for time limit, unless the percentage of estimated stale keys is
* too high. Also never repeat a fast cycle for the same period
* as the fast cycle total duration itself. */
if (!timelimit_exit &&
server.stat_expired_stale_perc < config_cycle_acceptable_stale)
return;
if (start < last_fast_cycle + (long long)config_cycle_fast_duration*2)
return;
last_fast_cycle = start;
}
/* We usually should test CRON_DBS_PER_CALL per iteration, with
* two exceptions:
*
* 1) Don't test more DBs than we have.
* 2) If last time we hit the time limit, we want to scan all DBs
* in this iteration, as there is work to do in some DB and we don't want
* expired keys to use memory for too much time. */
if (dbs_per_call > server.dbnum || timelimit_exit)
dbs_per_call = server.dbnum;
/* We can use at max 'config_cycle_slow_time_perc' percentage of CPU
* time per iteration. Since this function gets called with a frequency of
* server.hz times per second, the following is the max amount of
* microseconds we can spend in this function. */
timelimit = config_cycle_slow_time_perc*1000000/server.hz/100;
timelimit_exit = 0;
if (timelimit <= 0) timelimit = 1;
if (type == ACTIVE_EXPIRE_CYCLE_FAST)
timelimit = config_cycle_fast_duration; /* in microseconds. */
/* Accumulate some global stats as we expire keys, to have some idea
* about the number of keys that are already logically expired, but still
* existing inside the database. */
long total_sampled = 0;
long total_expired = 0;
for (j = 0; j < dbs_per_call && timelimit_exit == 0; j++) {
/* Expired and checked in a single loop. */
unsigned long expired, sampled;
redisDb *db = server.db+(current_db % server.dbnum);
/* Increment the DB now so we are sure if we run out of time
* in the current DB we'll restart from the next. This allows to
* distribute the time evenly across DBs. */
current_db++;
/* Continue to expire if at the end of the cycle more than 25%
* of the keys were expired. */
do {
unsigned long num, slots;
long long now, ttl_sum;
int ttl_samples;
iteration++;
/* If there is nothing to expire try next DB ASAP. */
if ((num = dictSize(db->expires)) == 0) {
db->avg_ttl = 0;
break;
}
slots = dictSlots(db->expires);
now = mstime();
/* When there are less than 1% filled slots, sampling the key
* space is expensive, so stop here waiting for better times...
* The dictionary will be resized asap. */
if (num && slots > DICT_HT_INITIAL_SIZE &&
(num*100/slots < 1)) break;
/* The main collection cycle. Sample random keys among keys
* with an expire set, checking for expired ones. */
expired = 0;
sampled = 0;
ttl_sum = 0;
ttl_samples = 0;
if (num > config_keys_per_loop)
num = config_keys_per_loop;
/* Here we access the low level representation of the hash table
* for speed concerns: this makes this code coupled with dict.c,
* but it hardly changed in ten years.
*
* Note that certain places of the hash table may be empty,
* so we want also a stop condition about the number of
* buckets that we scanned. However scanning for free buckets
* is very fast: we are in the cache line scanning a sequential
* array of NULL pointers, so we can scan a lot more buckets
* than keys in the same time. */
long max_buckets = num*20;
long checked_buckets = 0;
while (sampled < num && checked_buckets < max_buckets) {
for (int table = 0; table < 2; table++) {
if (table == 1 && !dictIsRehashing(db->expires)) break;
unsigned long idx = db->expires_cursor;
idx &= db->expires->ht[table].sizemask;
dictEntry *de = db->expires->ht[table].table[idx];
long long ttl;
/* Scan the current bucket of the current table. */
checked_buckets++;
while(de) {
/* Get the next entry now since this entry may get
* deleted. */
dictEntry *e = de;
de = de->next;
ttl = dictGetSignedIntegerVal(e)-now;
if (activeExpireCycleTryExpire(db,e,now)) expired++;
if (ttl > 0) {
/* We want the average TTL of keys yet
* not expired. */
ttl_sum += ttl;
ttl_samples++;
}
sampled++;
}
}
db->expires_cursor++;
}
total_expired += expired;
total_sampled += sampled;
/* Update the average TTL stats for this database. */
if (ttl_samples) {
long long avg_ttl = ttl_sum/ttl_samples;
/* Do a simple running average with a few samples.
* We just use the current estimate with a weight of 2%
* and the previous estimate with a weight of 98%. */
if (db->avg_ttl == 0) db->avg_ttl = avg_ttl;
db->avg_ttl = (db->avg_ttl/50)*49 + (avg_ttl/50);
}
/* We can't block forever here even if there are many keys to
* expire. So after a given amount of milliseconds return to the
* caller waiting for the other active expire cycle. */
if ((iteration & 0xf) == 0) { /* check once every 16 iterations. */
elapsed = ustime()-start;
if (elapsed > timelimit) {
timelimit_exit = 1;
server.stat_expired_time_cap_reached_count++;
break;
}
}
/* We don't repeat the cycle for the current database if there are
* an acceptable amount of stale keys (logically expired but yet
* not reclained). */
} while ((expired*100/sampled) > config_cycle_acceptable_stale);
}
elapsed = ustime()-start;
server.stat_expire_cycle_time_used += elapsed;
latencyAddSampleIfNeeded("expire-cycle",elapsed/1000);
/* Update our estimate of keys existing but yet to be expired.
* Running average with this sample accounting for 5%. */
double current_perc;
if (total_sampled) {
current_perc = (double)total_expired/total_sampled;
} else
current_perc = 0;
server.stat_expired_stale_perc = (current_perc*0.05)+
(server.stat_expired_stale_perc*0.95);
}说实话这个代码细节比较多，由于笔者对Redis源码了解不多，只能做个模糊版本的解读，所以难免有问题，还是建议有条件的读者自行前往源码区阅读，抛砖引玉看下笔者的模糊版本：
该算法是个自适应的过程，当过期的key比较少时那么就花费很少的cpu时间来处理，如果过期的key很多就采用激进的方式来处理，避免大量的内存消耗，可以理解为判断过期键多就多跑几次，少则少跑几次；
由于Redis中有很多数据库db，该算法会逐个扫描，本次结束时继续向后面的db扫描，是个闭环的过程；
定期删除有快速循环和慢速循环两种模式，主要采用慢速循环模式，其循环频率主要取决于server.hz，通常设置为10，也就是每秒执行10次慢循环定期删除，执行过程中如果耗时超过25%的CPU时间就停止；
慢速循环的执行时间相对较长，会出现超时问题，快速循环模式的执行时间不超过1ms，也就是执行时间更短，但是执行的次数更多，在执行过程中发现某个db中抽样的key中过期key占比低于25%则跳过；
主体意思：定期删除是个自适应的闭环并且概率化的抽样扫描过程，过程中都有执行时间和cpu时间的限制，如果触发阈值就停止，可以说是尽量在不影响对客户端的响应下润物细无声地进行的。
5. DEL删除键值对
在Redis4.0之前执行del操作时如果key-value很大，那么可能导致阻塞，在新版本中引入了BIO线程以及一些新的命令，实现了del的延时懒删除，最后会有BIO线程来实现内存的清理回收。
B.2 内存淘汰机制
为了保证Redis的安全稳定运行，设置了一个max-memory的阈值，那么当内存用量到达阈值，新写入的键值对无法写入，此时就需要内存淘汰机制，在Redis的配置中有几种淘汰策略可以选择，详细如下：
noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错；
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中移除最近最少使用的 key；
allkeys-random：当内存不足以容纳新写入数据时，在键空间中随机移除某个 key；
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key；
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key；
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除；
后三种策略都是针对过期字典的处理，但是在过期字典为空时会noeviction一样返回写入失败，毫无策略地随机删除也不太可取，所以一般选择第二种allkeys-lru基于LRU策略进行淘汰。
个人认为antirez一向都是工程化思维，善于使用概率化设计来做近似实现，LRU算法也不例外，Redis中实现了近似LRU算法，并且经过几个版本的迭代效果已经比较接近理论LRU算法的效果了，这个也是个不错的内容，由于篇幅限制，本文计划后续单独讲LRU算法时再进行详细讨论。
过期健删除策略强调的是对过期健的操作，如果有健过期而内存足够，Redis不会使用内存淘汰机制来腾退空间，这时会优先使用过期健删除策略删除过期健。
内存淘汰机制强调的是对内存数据的淘汰操作，当内存不足时，即使有的健没有到达过期时间或者根本没有设置过期也要根据一定的策略来删除一部分，腾退空间保证新数据的写入。
0x0C.谈谈对Redis数据同步机制和原理的理解
理解持久化和数据同步的关系，需要从单点故障和高可用两个角度来分析：
C.1 单点宕机故障
假如我们现在只有一台作为缓存的Redis机器，通过持久化将热点数据写到磁盘，某时刻该Redis单点机器发生故障宕机，此期间缓存失效，主存储服务将承受所有的请求压力倍增，监控程序将宕机Redis机器拉起。
重启之后，该机器可以Load磁盘RDB数据进行快速恢复，恢复的时间取决于数据量的多少，一般秒级到分钟级不等，恢复完成保证之前的热点数据还在，这样存储系统的CacheMiss就会降低，有效降低了缓存击穿的影响。
在单点Redis中持久化机制非常有用，只写文字容易让大家睡着，我画了张图：
作为一个高可用的缓存系统单点宕机是不允许的，因此就出现了主从架构，对主节点的数据进行多个备份，如果主节点挂点，可以立刻切换状态最好的从节点为主节点，对外提供写服务，并且其他从节点向新主节点同步数据，确保整个Redis缓存系统的高可用。
如图展示了一个一主两从读写分离的Redis系统主节点故障迁移的过程，整个过程并没有停止正常工作，大大提高了系统的高可用：
从上面的两点分析可以得出个小结论【划重点】：
持久化让单点故障不再可怕，数据同步为高可用插上翅膀。
我们理解了数据同步对Redis的重要作用，接下来继续看数据同步的实现原理和过程、重难点等细节问题吧！
C.2 Redis系统中的CAP理论
对分布式存储有了解的读者一定知道CAP理论，说来惭愧笔者在2018年3月份换工作的时候，去Face++旷视科技面后端开发岗位时就遇到了CAP理论，除了CAP理论问题之外其他问题都在射程内，所以最终还是拿了Offer。
在理论计算机科学中，CAP定理又被称作布鲁尔定理Brewer's theorem，这个定理起源于加州大学伯克利分校的计算机科学家埃里克·布鲁尔在2000年的分布式计算原理研讨会PODC上提出的一个猜想。
在2002年麻省理工学院的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。它指出对于一个分布式计算系统来说，不可能同时满足以下三点：
C Consistent 一致性 连贯性
A Availability 可用性
P Partition Tolerance 分区容忍性
来看一张阮一峰大佬画的图：
举个简单的例子，说明一下CP和AP的兼容性：
理解CP和AP的关键在于分区容忍性P，网络分区在分布式存储中再平常不过了，即使机器在一个机房，也不可能全都在一个机架或一台交换机。
这样在局域网就会出现网络抖动，笔者做过1年多DPI对于网络传输中最深刻的三个名词：丢包、乱序、重传。所以我们看来风平浪静的网络，在服务器来说可能是风大浪急，一不小心就不通了，所以当网络出现断开时，这时就出现了网络分区问题。
对于Redis数据同步而言，假设从结点和主结点在两个机架上，某时刻发生网络断开，如果此时Redis读写分离，那么从结点的数据必然无法与主继续同步数据。在这种情况下，如果继续在从结点读取数据就造成数据不一致问题，如果强制保证数据一致从结点就无法提供服务造成不可用问题，从而看出在P的影响下C和A无法兼顾。
其他几种情况就不深入了，从上面我们可以得出结论：当Redis多台机器分布在不同的网络中，如果出现网络故障，那么数据一致性和服务可用性无法兼顾，Redis系统对此必须做出选择，事实上Redis选择了可用性，或者说Redis选择了另外一种最终一致性。
C.3 Redis的最终一致性和复制
Redis选择了最终一致性，也就是不保证主从数据在任何时刻都是一致的，并且Redis主从同步默认是异步的，亲爱的盆友们不要晕！不要蒙圈！
我来一下解释同步复制和异步复制(注意：考虑读者的感受 我并没有写成同步同步和异步同步 哈哈)：
一图胜千言，看红色的数字就知道同步复制和异步复制的区别了：
异步复制：当客户端向主结点写了hello world，主节点写成功之后就向客户端回复OK，这样主节点和客户端的交互就完成了，之后主节点向从结点同步hello world，从结点完成之后向主节点回复OK，整个过程客户端不需要等待从结点同步完成，因此整个过程是异步实现的。
同步复制：当客户端向主结点写了hello world，主节点向从结点同步hello world，从结点完成之后向主节点回复OK，之后主节点向客户端回复OK，整个过程客户端需要等待从结点同步完成，因此整个过程是同步实现的。
Redis选择异步复制可以避免客户端的等待，更符合现实要求，不过这个复制方式可以修改，根据自己需求而定吧。
1.从从复制
假如Redis高可用系统中有一主四从，如果四个从同时向主节点进行数据同步，主节点的压力会比较大，考虑到Redis的最终一致性，因此Redis后续推出了从从复制，从而将单层复制结构演进为多层复制结构，笔者画了个图看下：
2.全量复制和增量复制
全量复制是从结点因为故障恢复或者新添加从结点时出现的初始化阶段的数据复制，这种复制是将主节点的数据全部同步到从结点来完成的，所以成本大但又不可避免。
增量复制是主从结点正常工作之后的每个时刻进行的数据复制方式，涓涓细流同步数据，这种同步方式又轻又快，优点确实不少，不过如果没有全量复制打下基础增量复制也没戏，所以二者不是矛盾存在而是相互依存的。
3.全量复制过程分析
Redis的全量复制过程主要分三个阶段：
快照阶段：从结点向主结点发起SYNC全量复制命令，主节点执行bgsave将内存中全部数据生成快照并发送给从结点，从结点释放旧内存载入并解析新快照，主节点同时将此阶段所产生的新的写命令存储到缓冲区。
缓冲阶段：主节点向从节点同步存储在缓冲区的操作命令，这部分命令主节点是bgsave之后到从结点载入快照这个时间段内的新增命令，需要记录要不然就出现数据丢失。
增量阶段：缓冲区同步完成之后，主节点正常向从结点同步增量操作命令，至此主从保持基本一致的步调。
借鉴参考1的一张图表，写的很好：
考虑一个多从并发全量复制问题：
如果此时有多个从结点同时向主结点发起全量同步请求会怎样？
Redis主结点是个聪明又诚实的家伙，比如现在有3个从结点A/B/C陆续向主节点发起SYNC全量同步请求。
主节点在对A进行bgsave的同时，B和C的SYNC命令到来了，那么主节点就一锅烩，把针对A的快照数据和缓冲区数据同时同步给ABC，这样提高了效率又保证了正确性。
主节点对A的快照已经完成并且现在正在进行缓冲区同步，那么只能等A完成之后，再对B和C进行和A一样的操作过程，来实现新节点的全量同步，所以主节点并没有偷懒而是重复了这个过程，虽然繁琐但是保证了正确性。
再考虑一个快照复制循环问题：
主节点执行bgsave是比较耗时且耗内存的操作，期间从结点也经历装载旧数据->释放内存->装载新数据的过程，内存先升后降再升的动态过程，从而知道无论主节点执行快照还是从结点装载数据都是需要时间和资源的。
抛开对性能的影响，试想如果主节点快照时间是1分钟，在期间有1w条新命令到来，这些新命令都将写到缓冲区，如果缓冲区比较小只有8k，那么在快照完成之后，主节点缓冲区也只有8k命令丢失了2k命令，那么此时从结点进行全量同步就缺失了数据，是一次错误的全量同步。
无奈之下，从结点会再次发起SYNC命令，从而陷入循环，因此缓冲区大小的设置很重要，二话不说再来一张图：
4.增量复制过程分析
增量复制过程稍微简单一些，但是非常有用，试想复杂的网络环境下，并不是每次断开都无法恢复，如果每次断开恢复后就要进行全量复制，那岂不是要把主节点搞死，所以增量复制算是对复杂网络环境下数据复制过程的一个优化，允许一段时间的落后，最终追上就行。
增量复制是个典型的生产者-消费者模型，使用定长环形数组(队列)来实现，如果buffer满了那么新数据将覆盖老数据，因此从结点在复制数据的同时向主节点反馈自己的偏移量，从而确保数据不缺失。
这个过程非常好理解，kakfa这种MQ也是这样的，所以在合理设置buffer大小的前提下，理论上从的消费能力是大于主的生产能力的，大部分只有在网络断开时间过长时会出现buffer被覆盖，从结点消费滞后的情况，此时只能进行全量复制了。
5.无盘复制
理解无盘复制之前先看下什么是有盘复制呢？
所谓盘是指磁盘，可能是机械磁盘或者SSD，但是无论哪一种相比内存都更慢，我们都知道IO操作在服务端的耗时是占大头的，因此对于全量复制这种高IO耗时的操作来说，尤其当服务并发比较大且还在进行其他操作时对Redis服务本身的影响是比较大大，之前的模式时这样的：
在Redis2.8.18版本之后，开发了无盘复制，也就是避免了生成的RDB文件落盘再加载再网络传输的过程，而是流式的遍历发送过程，主节点一边遍历内存数据，一边将数据序列化发送给从结点，从结点没有变化，仍然将数据依次存储到本地磁盘，完成传输之后进行内存加载，可见无盘复制是对IO更友好。
0x0D.谈谈基于Redis的分布式锁和Redlock算法
D.1 基于Redis的分布式锁简介
最初分布式锁借助于setnx和expire命令，但是这两个命令不是原子操作，如果执行setnx之后获取锁但是此时客户端挂掉，这样无法执行expire设置过期时间就导致锁一直无法被释放，因此在2.8版本中Antirez为setnx增加了参数扩展，使得setnx和expire具备原子操作性。
在单Matster-Slave的Redis系统中，正常情况下Client向Master获取锁之后同步给Slave，如果Client获取锁成功之后Master节点挂掉，并且未将该锁同步到Slave，之后在Sentinel的帮助下Slave升级为Master但是并没有之前未同步的锁的信息，此时如果有新的Client要在新Master获取锁，那么将可能出现两个Client持有同一把锁的问题，来看个图来想下这个过程：
为了保证自己的锁只能自己释放需要增加唯一性的校验，综上基于单Redis节点的获取锁和释放锁的简单过程如下:
// 获取锁 unique_value作为唯一性的校验
SET resource_name unique_value NX PX 30000
// 释放锁 比较unique_value是否相等 避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
这就是基于单Redis的分布式锁的几个要点。
D.2 Redlock算法基本过程
Redlock算法是Antirez在单Redis节点基础上引入的高可用模式。在Redis的分布式环境中，我们假设有N个完全互相独立的Redis节点，在N个Redis实例上使用与在Redis单实例下相同方法获取锁和释放锁。
现在假设有5个Redis主节点(大于3的奇数个)，这样基本保证他们不会同时都宕掉，获取锁和释放锁的过程中，客户端会执行以下操作:
获取当前Unix时间，以毫秒为单位
依次尝试从5个实例，使用相同的key和具有唯一性的value获取锁
当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间，这样可以避免客户端死等客户端使用当前时间减去开始获取锁时间就得到获取锁使用的时间。当且仅当从半数以上的Redis节点取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功
如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间，这个很重要
如果因为某些原因，获取锁失败（没有在半数以上实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁，无论Redis实例是否加锁成功，因为可能服务端响应消息丢失了但是实际成功了，毕竟多释放一次也不会有问题
上述的5个步骤是Redlock算法的重要过程，也是面试的热点，有心的读者还是记录一下吧！
D.3 Redlock算法是否安全的争论
1.关于马丁·克莱普曼博士
2016年2月8号分布式系统的专家马丁·克莱普曼博士(Martin Kleppmann)在一篇文章How to do distributed locking 指出分布式锁设计的一些原则并且对Antirez的Redlock算法提出了一些质疑。笔者找到了马丁·克莱普曼博士的个人网站以及一些简介，一起看下：
1.我是剑桥大学计算机科学与技术系的高级研究助理和附属讲师，由勒弗乌尔姆信托早期职业奖学金和艾萨克牛顿信托基金资助。我致力于本地优先的协作软件和分布式系统安全。
2.我也是剑桥科珀斯克里斯蒂学院计算机科学研究的研究员和主任，我在那里从事本科教学。
3.2017年，我为奥雷利出版了一本名为《设计数据密集型应用》的书。它涵盖了广泛的数据库和分布式数据处理系统的体系结构，是该出版社最畅销书之一。
4.我经常在会议上发言，我的演讲录音已经被观看了超过15万次。
5.我参与过各种开源项目，包括自动合并、Apache Avro和Apache Samza。
6.2007年至2014年间，我是一名工业软件工程师和企业家。我共同创立了Rapportive(2012年被领英收购)和Go Test(2009年被红门软件收购)。
7.我创作了几部音乐作品，包括《二月之死》(德语)，这是唐克·德拉克特对该书的音乐戏剧改编，于2007年首映，共有150人参与。
大牛就是大牛，能教书、能出书、能写开源软件、能创业、能写音乐剧，优秀的人哪方面也优秀，服气了。
2.马丁博士文章的主要观点
马丁·克莱普曼在文章中谈及了分布式系统的很多基础问题，特别是分布式计算的异步模型，文章分为两大部分前半部分讲述分布式锁的一些原则，后半部分针对Redlock提出一些看法：
Martin指出即使我们拥有一个完美实现的分布式锁，在没有共享资源参与进来提供某种fencing栅栏机制的前提下，我们仍然不可能获得足够的安全性
Martin指出，由于Redlock本质上是建立在一个同步模型之上，对系统的时间有很强的要求，本身的安全性是不够的
针对fencing机制马丁给出了一个时序图：
针对这种情况马丁指出要增加fencing机制，具体来说是fencing token隔离令牌机制，同样给出了一张时序图：
客户端1获得锁并且获得序号为33的令牌，但随后它进入长时间暂停，直至锁超时过期，客户端2获取锁并且获得序号为34的令牌，然后将其写入发送到存储服务。随后，客户端1复活并将其写入发送到存储服务，然而存储服务器记得它已经处理了具有较高令牌号的写入34，因此它拒绝令牌33的请求。
Redlock算法并没有这种唯一且递增的fencing token生成机制，这也意味着Redlock算法不能避免由于客户端阻塞带来的锁过期后的操作问题，因此是不安全的。
这个观点笔者觉得并没有彻底解决问题，因为如果客户端1的写入操作是必须要执行成功的，但是由于阻塞超时无法再写入同样就产生了一个错误的结果，客户端2将可能在这个错误的结果上进行操作，那么任何操作都注定是错误的。
3.马丁博士对Redlock的质疑
马丁·克莱普曼指出Redlock是个强依赖系统时间的算法，这样就可能带来很多不一致问题，他给出了个例子一起看下：
假设多节点Redis系统有五个节点A/B/C/D/E和两个客户端C1和C2，如果其中一个Redis节点上的时钟向前跳跃会发生什么？
客户端C1获得了对节点A、B、c的锁定，由于网络问题，法到达节点D和节点E 节点C上的时钟向前跳，导致锁提前过期 客户端C2在节点C、D、E上获得锁定，由于网络问题，无法到达A和B 客户端C1和客户端C2现在都认为他们自己持有锁
分布式异步模型：
上面这种情况之所以有可能发生，本质上是因为Redlock的安全性对Redis节点系统时钟有强依赖，一旦系统时钟变得不准确，算法的安全性也就无法保证。
马丁其实是要指出分布式算法研究中的一些基础性问题，好的分布式算法应该基于异步模型，算法的安全性不应该依赖于任何记时假设。
分布式异步模型中进程和消息可能会延迟任意长的时间，系统时钟也可能以任意方式出错。这些因素不应该影响它的安全性，只可能影响到它的活性，即使在非常极端的情况下，算法最多是不能在有限的时间内给出结果，而不应该给出错误的结果，这样的算法在现实中是存在的比如Paxos/Raft，按这个标准衡量Redlock的安全级别是达不到的。
4.马丁博士文章结论和基本观点
马丁表达了自己的观点，把锁的用途分为两种：
效率第一
使用分布式锁只是为了协调多个客户端的一些简单工作，锁偶尔失效也会产生其它的不良后果，就像你收发两份相同的邮件一样，无伤大雅正确第一
使用分布式锁要求在任何情况下都不允许锁失效的情况发生，一旦发生失效就可能意味着数据不一致、数据丢失、文件损坏或者其它严重的问题，就像给患者服用重复剂量的药物一样，后果严重
最后马丁出了如下的结论：
为了效率而使用分布式锁
单Redis节点的锁方案就足够了Redlock则是个过重而昂贵的设计为了正确而使用分布式锁
Redlock不是建立在异步模型上的一个足够强的算法，它对于系统模型的假设中包含很多危险的成分
马丁认为Redlock算法是个糟糕的选择，因为它不伦不类：出于效率选择来说，它过于重量级和昂贵，出于正确性选择它又不够安全。
5.Antirez的反击
马丁的那篇文章是在2016.2.8发表之后Antirez反应很快，他发表了"Is Redlock safe?"进行逐一反驳，文章地址如下：
http://antirez.com/news/101
Antirez认为马丁的文章对于Redlock的批评可以概括为两个方面：
带有自动过期功能的分布式锁，必须提供某种fencing栅栏机制来保证对共享资源的真正互斥保护，Redlock算法提供不了这样一种机制 Redlock算法构建在一个不够安全的系统模型之上，它对于系统的记时假设有比较强的要求，而这些要求在现实的系统中是无法保证的
Antirez对这两方面分别进行了细致地反驳。
关于fencing机制
Antirez提出了质疑：既然在锁失效的情况下已经存在一种fencing机制能继续保持资源的互斥访问了，那为什么还要使用一个分布式锁并且还要求它提供那么强的安全性保证呢？
退一步讲Redlock虽然提供不了递增的fencing token隔离令牌，但利用Redlock产生的随机字符串可以达到同样的效果，这个随机字符串虽然不是递增的，但却是唯一的。
关于记时假设
Antirez针对算法在记时模型假设集中反驳，马丁认为Redlock失效情况主要有三种：
1.时钟发生跳跃 2.长时间的GC pause 3.长时间的网络延迟
后两种情况来说，Redlock在当初之处进行了相关设计和考量，对这两种问题引起的后果有一定的抵抗力。
时钟跳跃对于Redlock影响较大，这种情况一旦发生Redlock是没法正常工作的。
Antirez指出Redlock对系统时钟的要求并不需要完全精确，只要误差不超过一定范围不会产生影响，在实际环境中是完全合理的，通过恰当的运维完全可以避免时钟发生大的跳动。
6.马丁的总结和思考
分布式系统本身就很复杂，机制和理论的效果需要一定的数学推导作为依据，马丁和Antirez都是这个领域的专家，对于一些问题都会有自己的看法和思考，更重要的是很多时候问题本身并没有完美的解决方案。
这次争论是分布式系统领域非常好的一次思想的碰撞，很多网友都发表了自己的看法和认识，马丁博士也在Antirez做出反应一段时间之后再次发表了自己的一些观点：
For me, this is the most important point: I don’t care who is right or wrong in this debate — I care about learning from others’ work, so that we can avoid repeating old mistakes, and make things better in future. So much great work has already been done for us: by standing on the shoulders of giants, we can build better software.
By all means, test ideas by arguing them and checking whether they stand up to scrutiny by others. That’s part of the learning process. But the goal should be to learn, not to convince others that you are right. Sometimes that just means to stop and think for a while.
简单翻译下就是：
对马丁而言并不在乎谁对谁错，他更关心于从他人的工作中汲取经验来避免自己的错误重复工作，正如我们是站在巨人的肩膀上才能做出更好的成绩。
另外通过别人的争论和检验才更能让自己的想法经得起考验，我们的目标是相互学习而不是说服别人相信你是对的，所谓一人计短，思考辩驳才能更加接近真理。
全部评论