1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// 使用STL中unordered_map作为字典
template <typename T1, typename T2>
using Dict =
    std::unordered_map<T1, T2, std::hash<T1>, std::equal_to<T1>,
                       __gnu_cxx::__pool_alloc<std::pair<const T1, T2>>>;

// 数据库键类型为std::string
// 数据库五种值类型定义
// __pool_alloc内部使用链表进行管理内存、预分配内存、不归还内存给操作系统等机制来减少malloc的调用次数。
using String = Dict<std::string, std::string>;
using List = Dict<std::string,
                  std::list<std::string, __gnu_cxx::__pool_alloc<std::string>>>;
using Hash =
    Dict<std::string, std::map<std::string, std::string, std::less<>,
                               __gnu_cxx::__pool_alloc<
                                   std::pair<const std::string, std::string>>>>;
using Set =
    Dict<std::string, std::unordered_set<std::string, std::hash<std::string>,
                                         std::equal_to<>,
                                         __gnu_cxx::__pool_alloc<std::string>>>;
using ZSet = Dict<std::string, SkipListSp>;
using Expire = Dict<std::string, Timestamp>;

// 五个数据字典
  String string_;
  List list_;
  Hash hash_;
  Set set_;
  ZSet zset_;

// 数据类型
    const short kDbString = 0;
    const short kDbList = 1;
    const short kDbHash = 2;
    const short kDbSet = 3;
    const short kDbZSet = 4;

    const std::string kDefaultObjValue = "NULL";

    // RDB默认保存时间(ms)
    const muduo::Timestamp kRdbDefaultTime(1000 * 1000 * 1000);

    // 过期删除策略
    const short kDingshiDel = 0x0;
    const short kDuoxingDel = 0x1;
    const short kDingqiDel = 0x2;

    // 定期删除每次抽查的key数量
    const int kCheckNum = 20;

过期删除

过期删除策略：定时、惰性、定期

定期删除

每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查，并删除其中的过期key。

1
2
3
4
5
6
// 五个过期字典
  Expire string_expire_;
  Expire list_expire_;
  Expire hash_expire_;
  Expire set_expire_;
  Expire zset_expire_;

1、这个间隔检查的时间是多长呢？

1
2
3
4
5
// 使用Muduo提供的定时器模块，在设置key过期时间时添加一个定时任务，时间到期就删除该key
// 添加定期删除策略的定时任务
int expire_del_time = 3; // 每三秒执行一次
muduo::net::EventLoop::getEventLoopOfCurrentThread()->runEvery(
    expire_del_time, std::bind(&Database::DingqiHandler, this));

2、随机抽查的数量是多少呢？

  1. 从过期字典中随机抽取 20 个 key；
  2. 检查这 20 个 key 是否过期，并删除已过期的 key；
  3. 如果本轮检查的已过期 key 的数量，超过 5 个（20/4），也就是「已过期 key 的数量」占比「随机抽取 key 的数量」大于 25%，则继续重复步骤 1；如果已过期的 key 比例小于 25%，则停止继续删除过期 key，然后等待下一轮再检查。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 // 遍历数据字典，拿到当前key的过期时间并与 Timestamp::now() 比对
Timestamp tmp;
  if (type == dbobject::kDbString)
  {
    auto it = string_expire_.find(key);
    if (string_expire_.find(key) != string_expire_.end())
    {
      tmp = it->second;
    }
    else
    {
      tmp = Timestamp::invalid();
    }
  }

惰性删除

不主动删除过期键，每次从数据库访问 key 时，都检测 key 是否过期，如果过期则删除该 key。

内存淘汰

LRU 算法 实现方式是在 Redis 的对象结构体中添加一个额外的字段，用于记录此数据的最后一次访问时间。 但无法解决缓存污染问题，比如应用一次读取了大量的数据，而这些数据只会被读取这一次，那么这些数据会留存在 Redis 缓存中很长一段时间，造成缓存污染。

LFU 算法相比于 LRU 算法的实现，多记录了「数据的访问频次」的信息。 根据访问频率来淘汰数据的，而不只是访问次数。访问频率需要考虑 key 的访问是多长时间段内发生的。key 的先前访问距离当前时间越长，那么这个 key 的访问频率相应地也就会降低，这样被淘汰的概率也会更大。

进一步节省内存

编译优化

在 struct 声明了 __attribute__ ((packed)) ，它的作用是：告诉编译器取消结构体在编译过程中的优化对齐，按照实际占用字节数进行对齐。

1
2
3
4
struct __attribute__((packed)) test2  {
    char a;
    int b;
 } test2;

img

数据结构

SDS

简单动态字符串（simple dynamic string，SDS） 的数据结构来表示字符串

img

flags，用来表示不同类型的 SDS。一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64。

这 5 种类型的主要区别就在于，它们数据结构中的 len 和 alloc 成员变量的数据类型不同。所以可以灵活保存不同大小的字符串，比如在保存小字符串时，结构头占用空间小。

压缩列表

由连续内存块组成的顺序型数据结构，有点类似于数组。

img

压缩列表节点包含三部分内容：

  • *prevlen*，记录了「前一个节点」的长度，目的是为了实现从后向前遍历；
  • *encoding*，记录了当前节点实际数据的「类型和长度」，类型主要有两种：字符串和整数。
  • *data*，记录了当前节点的实际数据，类型和长度都由 encoding 决定

根据数据大小和类型进行不同的空间大小分配

缺陷：

  • 不能保存过多的元素，否则查询效率就会降低；
  • 新增或修改某个元素时，压缩列表占用的内存空间需要重新分配，甚至可能引发连锁更新的问题。

哈希表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
typedef struct dictEntry {
    //键值对中的键
    void *key;
  
    //键值对中的值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    //指向下一个哈希表节点。这个指针可以将多个哈希值相同的键值对链接起来，以此来解决哈希冲突
    struct dictEntry *next;
} dictEntry;

键值对中的值可以是一个指向实际值的指针，或者是一个无符号的 64 位整数或有符号的 64 位整数或double 类的值（值的数据内嵌在 dictEntry 结构里，无需再用一个指针指向实际的值，从而节省了内存空间）

RDB

RDB持久化在四种情况下会执行：

  • 执行save命令
  • 执行bgsave命令
  • Redis停机时
  • 触发RDB条件时

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

  • 当主进程执行读操作时，访问共享内存；
  • 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

用新RDB文件替换旧的RDB文件

1
2
3
std::unordered_map<std::string, std::function<std::string(VecS &&)>> cmd_dict_; // <命令名称, 命令回调函数对象>

cmd_dict_.insert(std::make_pair("bgsave", std::bind(&DbServer::BgsaveCommand, this, std::placeholders::_1)));

如保存库0的string类型数据

1
2
3
KV0001 SD0 ^0
ST 过期时间XXXX
sprintf(buf, "!%d#%s!%d$%s", static_cast<int>(key.size()), key.c_str(),static_cast<int>(value.size()), value.c_str());

加载RDB的时候做字符串解析即可

AOF

写回策略

提供了 3 种写回硬盘的策略 No 、Always 、Everysec 。

img

后台重写

重写 AOF 过程是由后台子进程 bgrewriteaof 来完成的， 主进程在通过 fork 系统调用生成 bgrewriteaof 子进程时，操作系统会把主进程的「页表」复制一份给子进程，这个页表记录着虚拟地址和物理地址映射关系，而不会复制物理内存，也就是说，两者的虚拟空间不同，但其对应的物理空间是同一个。 在发生写操作的时候，操作系统才会去复制物理内存 。

有两个阶段会导致阻塞父进程：

  • 创建子进程的途中，由于要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长；
  • 创建完子进程后，如果子进程或者父进程修改了共享数据，就会发生写时复制，这期间会拷贝物理内存，如果内存越大，自然阻塞的时间也越长；

如果是使用线程，多线程之间会共享内存，那么在修改共享内存数据的时候，需要通过加锁来保证数据的安全，而这样就会降低性能

img

bgsave 快照过程中，如果主线程修改了共享数据，发生了写时复制后，RDB 快照保存的是原本的内存数据，而主线程刚修改的数据，是没办法在这一时间写入 RDB 文件的，只能交由下一次的 bgsave 快照。

使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。 当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

跳表

Redis 只有 Zset 对象的底层实现用到了跳表，跳表的优势是能支持平均 O(logN) 复杂度的节点查找。

zset 结构体里有两个数据结构：一个是跳表，一个是哈希表。这样的好处是既能进行高效的范围查询，也能进行高效单点查询。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
typedef struct zset {
    dict *dict;
    zskiplist *zsl;
} zset;

// 「跳表节点」
typedef struct zskiplistNode {
    //Zset 对象的元素值
    sds ele;
    //元素权重值
    double score;
    //后向指针
    struct zskiplistNode *backward;
  
    //节点的level数组，保存每层上的前向指针和跨度
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

// 「跳表」
typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    // 跳表的长度
    unsigned long length;
    // 跳表的最大层数
    int level;
} zskiplist;

Zset 对象在执行数据插入或是数据更新的过程中，会依次在跳表和哈希表中插入或更新相应的数据，从而保证了跳表和哈希表中记录的信息一致。

Zset 对象能支持范围查询（如 ZRANGEBYSCORE 操作），这是因为它的数据结构设计采用了跳表，而又能以常数复杂度获取元素权重（如 ZSCORE 操作），这是因为它同时采用了哈希表进行索引。

跳表是在链表基础上改进过来的，实现了一种「多层」的有序链表，这样的好处是能快读定位数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
class Skiplist
{
public:
  using ptr = std::shared_ptr<Skiplist>;
  Skiplist();
  ~Skiplist();
  Skiplist(Skiplist &) = delete;
  Skiplist &operator=(Skiplist &) = delete;

  SkiplistNode *CreateNode(const std::string &obj, double score, int level);
  int GetRandomLevel();
  void InsertNode(const std::string &, double);
  void DeleteNode(const std::string &, double);
  unsigned long GetCountInRange(RangeSpec &range);
  std::vector<SkiplistNode *> GetNodeInRange(RangeSpec &range);
  unsigned long GetLength() { return length_; }

private:
  int ValueGteMin(double value, RangeSpec &spec);
  int ValueLteMax(double value, RangeSpec &spec);

private:
  // 头节点
  SkiplistNode *header_;

  // 用来保证key不同
  std::unordered_map<std::string, double> key_set_;

  int level_;
  unsigned long length_;
};

查询

  • 如果当前节点的权重「小于」要查找的权重时，跳表就会访问该层上的下一个节点。
  • 如果当前节点的权重「等于」要查找的权重时，并且当前节点的 SDS 类型数据「小于」要查找的数据时，跳表就会访问该层上的下一个节点。

如果上面两个条件都不满足，或者下一个节点为空时，跳表就会使用目前遍历到的节点的 level 数组里的下一层指针，然后沿着下一层指针继续查找，这就相当于跳到了下一层接着查找。

如果层高最大限制是 64，那么在创建跳表「头节点」的时候，就会直接创建 64 层高的头节点。

在创建节点时候，会生成范围为[0-1]的一个随机数，如果这个随机数小于 0.25（相当于概率 25%），那么层数就增加 1 层，然后继续生成下一个随机数，直到随机数的结果大于 0.25 结束，最终确定该节点的层数。

这样的做法，相当于每增加一层的概率不超过 25%，层数越高，概率越低，层高最大限制是 64。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int Skiplist::GetRandomLevel()
{
  // 0.25的概率
  static const unsigned int kBranching = 4;
  int level = 1;
  while (level < MAX_LEVEL && ((rand() % kBranching) == 0))
  {
    level++;
  }
  assert(level > 0);
  assert(level <= MAX_LEVEL);

  return level;
}

插入：

img

首先保证key（跳表中的元素）是唯一的。

从最高层开始，每一层头结点开始，从左到右遍历。看能不能找到一样分数且元素相同的

1
2
3
4
5
6
7
8
9
10
11
12
13
// 从最上层开始遍历
 for (int i = level_ - 1; i >= 0; --i)
 {
   while (tmp->levels_[i]->forward_ &&
          (tmp->levels_[i]->forward_->score_ < score ||
           (tmp->levels_[i]->forward_->score_ == score &&
            tmp->levels_[i]->forward_->obj_ != obj)))
   {
     tmp = tmp->levels_[i]->forward_;
   }
   // 记录第i层遍历到的最后一个节点,即在该节点后插入新节点
   update[i] = tmp;
 }

每一层依次插入即可

分布式

Redis 主从复制模式中的数据是异步复制的，这样导致分布式锁的不可靠性。如果在 Redis 主节点获取到锁后，在没有同步到其他节点时，Redis 主节点宕机了，此时新的 Redis 主节点依然可以获取锁，所以多个应用服务就可以同时获取到锁。

Redlock 算法的基本思路，是让客户端和多个独立的 Redis 节点依次请求申请加锁，如果客户端能够和半数以上的节点成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁，否则加锁失败。

这样一来，即使有某个 Redis 节点发生故障，因为锁的数据在其他节点上也有保存，所以客户端仍然可以正常地进行锁操作，锁的数据也不会丢失。

基于setnx实现的分布式锁存在下面的问题：

重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。

不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。

**超时释放：**我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患

主从一致性： 如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。

为了提高redis的可用性，我们会搭建集群或者主从，现在以主从为例

此时我们去写命令，写在主机上， 主机会将数据同步给从机，但是假设在主机还没有来得及把数据写入到从机去的时候，此时主机宕机，哨兵会发现主机宕机，并且选举一个slave变成master，而此时新的master中实际上并没有锁信息，此时锁信息就已经丢掉了。

为了解决这个问题，redission提出来了MutiLock锁，使用这把锁咱们就不使用主从了，每个节点的地位都是一样的， 这把锁加锁的逻辑需要写入到每一个主丛节点上，只有所有的服务器都写入成功，此时才是加锁成功，假设现在某个节点挂了，那么他去获得锁的时候，只要有一个节点拿不到，都不能算是加锁成功，就保证了加锁的可靠性。

目前绑了18个命令

一致性

img

IO多路复用

最简单的socket

只能一对一通信，因为使用的是同步阻塞的方式，当服务端在还没处理完一个客户端的网络 I/O 时，或者 读写操作发生阻塞时，其他客户端是无法与服务端连接的。

在 TCP 连接的过程中，服务器的内核实际上为每个 Socket 维护了两个队列：

  • 一个是「还没完全建立」连接的队列，称为 TCP 半连接队列，这个队列都是没有完成三次握手的连接，此时服务端处于 syn_rcvd 的状态；
  • 一个是「已经建立」连接的队列，称为 TCP 全连接队列，这个队列都是完成了三次握手的连接，此时服务端处于 established 状态；

当 TCP 全连接队列不为空后，服务端的 accept() 函数，就会从内核中的 TCP 全连接队列里拿出一个已经完成连接的 Socket 返回应用程序，后续数据传输都用这个 Socket。

对于 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数约为 2 的 48 次方。

这个理论值相当“丰满”，但是服务器肯定承载不了那么大的连接数，主要会受两个方面的限制：

  • 文件描述符，Socket 实际上是一个文件，也就会对应一个文件描述符。在 Linux 下，单个进程打开的文件描述符数是有限制的，没有经过修改的值一般都是 1024，不过我们可以通过 ulimit 增大文件描述符的数目；
  • 系统内存，每个 TCP 连接在内核中都有对应的数据结构，意味着每个连接都是会占用一定内存的；

多线程模型

img

这个队列是全局的，每个线程都会操作，为了避免多线程竞争，线程在操作这个队列前要加锁。

新到来一个 TCP 连接，就需要分配一个进程或者线程，那么如果要达到 C10K，意味着要一台机器维护 1 万个连接，相当于要维护 1 万个进程/线程，操作系统就算死扛也是扛不住的。

IO多路复用

一个进程虽然任一时刻只能处理一个请求，但是处理每个请求的事件时，耗时控制在 1 毫秒以内，这样 1 秒内就可以处理上千个请求，把时间拉长来看，多个请求复用了一个进程，这就是多路复用，这种思想很类似一个 CPU 并发多个进程，所以也叫做时分多路复用。

select 和 poll 并没有本质区别，它们内部都是使用「线性结构」来存储进程关注的 Socket 集合。

在使用的时候，首先需要把关注的 Socket 集合通过 select/poll 系统调用从用户态拷贝到内核态，然后由内核检测事件，当有网络事件产生时，内核需要遍历进程关注 Socket 集合，找到对应的 Socket，并设置其状态为可读/可写，然后把整个 Socket 集合从内核态拷贝到用户态，用户态还要继续遍历整个 Socket 集合找到可读/可写的 Socket，然后对其处理。

很明显发现，select 和 poll 的缺陷在于，当客户端越多，也就是 Socket 集合越大，Socket 集合的遍历和拷贝会带来很大的开销，因此也很难应对 C10K。

epoll 是解决 C10K 问题的利器，通过两个方面解决了 select/poll 的问题。

  • epoll 在内核里使用「红黑树」来关注进程所有待检测的 Socket，红黑树是个高效的数据结构，增删改一般时间复杂度是 O(logn)，通过对这棵黑红树的管理，不需要像 select/poll 在每次操作时都传入整个 Socket 集合，减少了内核和用户空间大量的数据拷贝和内存分配。
  • epoll 使用事件驱动的机制，内核里维护了一个「链表」来记录就绪事件，只将有事件发生的 Socket 集合传递给应用程序，不需要像 select/poll 那样轮询扫描整个集合（包含有和无事件的 Socket ），大大提高了检测的效率。

而且，epoll 支持边缘触发和水平触发两种事件触发模式 ，而 select/poll 只支持水平触发，一般而言，边缘触发的方式会比水平触发的效率高。

配置

Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议：

  • 用来做缓存的Redis实例尽量不要开启持久化功能
  • 建议关闭RDB持久化功能，使用AOF持久化
  • 利用脚本定期在slave节点做RDB，实现数据备份
  • 设置合理的rewrite阈值，避免频繁的bgrewrite
  • 配置no-appendfsync-on-rewrite = yes，禁止在rewrite期间做aof，避免因AOF引起的阻塞
  • 部署有关建议：
    • Redis实例的物理机要预留足够内存，应对fork和rewrite
    • 单个Redis实例内存上限不要太大，例如4G或8G。可以加快fork的速度、减少主从同步、数据迁移压力
    • 不要与CPU密集型应用部署在一起
    • 不要与高硬盘负载应用一起部署。例如：数据库、消息队列
  • 如果 fork 耗时很大，比如超过1秒，则需要做出优化调整：
    • 单个实例的内存占用控制在 10 GB 以下，这样 fork 函数就能很快返回。
    • 如果 Redis 只是当作纯缓存使用，不关心 Redis 数据安全性问题，可以考虑关闭 AOF 和 AOF 重写，这样就不会调用 fork 函数了。
    • 在主从架构中，要适当调大 repl-backlog-size，避免因为 repl_backlog_buffer 不够大，导致主节点频繁地使用全量同步的方式，全量同步的时候，是会创建 RDB 文件的，也就是会调用 fork 函数。

BigKey的危害

  • 网络阻塞
    • 对BigKey执行读请求时，少量的QPS就可能导致带宽使用率被占满，导致Redis实例，乃至所在物理机变慢
  • 数据倾斜
    • BigKey所在的Redis实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡。集群模型在 slot 分片均匀情况下，会出现数据和查询倾斜情况，部分有大 key 的 Redis 节点占用内存多，QPS 也会比较大。
  • Redis阻塞
    • 对元素较多的hash、list、zset等做运算会耗时较旧，使主线程被阻塞
    • 在使用 Always 策略的时候，主线程在执行完命令后，会把数据写入到 AOF 日志文件，然后会调用 fsync() 函数，将内核缓冲区的数据直接写入到硬盘，等到硬盘写操作完成后，该函数才会返回。如果写入是一个大 Key，主线程在执行 fsync() 函数的时候，阻塞的时间会比较久，因为当写入的数据量很大的时候，数据同步到硬盘这个过程是很耗时的。
  • CPU压力
    • 对BigKey的数据序列化和反序列化会导致CPU的使用率飙升，影响Redis实例和本机其它应用

在应用程序释放内存时，操作系统需要把释放掉的内存块插入一个空闲内存块的链表，以便后续进行管理和再分配。这个过程本身需要一定时间，而且会阻塞当前释放内存的应用程序。 所以，如果一下子释放了大量内存，空闲内存块链表操作时间就会增加，相应地就会造成 Redis 主线程的阻塞， 如果主线程发生了阻塞，其他所有请求可能都会超时，超时越来越多，会造成 Redis 连接耗尽，产生各种异常。

为啥单线程？

img

IO 多路复⽤是指在⼀个线程中同时监听多个⽂件描述符，⼀旦某个⽂件描述符就绪，就⽴即处理对应的事件。在 Redis 中，采⽤的是基于 epoll 的 IO 多路复⽤技术，可以实现⾼效的事件监听和响应。

在 Redis 中，客户端的请求是由⼀个单线程来处理的，⽽ IO 操作却是通过 epoll 多路复⽤技术实现的。这种设计⽅式既能充分利⽤ CPU 的计算能⼒，⼜能够保证⾜够的 IO 处理能⼒，从⽽实现了⾼效的键值存储服务。

集群

主从复制

主从复制共有三种模式：全量复制、基于长连接的命令传播、增量复制。

第一次同步

img

主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 连接。 这个连接是长连接的，目的是避免频繁的 TCP 连接和断开带来的性能开销。

断网了咋办？

img

主服务器怎么知道要将哪些增量数据发送给从服务器呢？

img

  • 如果判断出从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，那么主服务器将采用增量同步的方式；
  • 相反，如果判断出从服务器要读取的数据已经不存在 repl_backlog_buffer 缓冲区里，那么主服务器将采用全量同步的方式。

主从切换过程中，产生数据丢失的情况有两种：

  • 异步复制同步丢失，假设将 min-slaves-max-lag 配置为 10s 后，根据目前 master->slave 的复制速度，如果数据同步完成所需要时间超过10s，就会认为 master 未来宕机后损失的数据会很多，master 就拒绝写入新请求。这样就能将 master 和 slave 数据差控制在10s内，即使 master 宕机也只是这未复制的 10s 数据。
  • 集群产生脑裂数据丢失。由于网络问题，集群节点之间失去联系。主从数据不同步；重新平衡选举，产生两个主服务。等网络恢复，旧主节点会降级为从节点，再与新主节点进行同步复制的时候，由于会从节点会清空自己的缓冲区，所以导致之前客户端写入的数据丢失了。

可以把 min-slaves-to-write 和 min-slaves-max-lag 这两个配置项搭配起来使用，分别给它们设置一定的阈值，假设为 N 和 T。

这两个配置项组合后的要求是，主节点连接的从节点中至少有 N 个从节点，「并且」主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主节点就不会再接收客户端的写请求了。

当客户端发现 master 不可写后，我们可以采取降级措施，将数据暂时写入本地缓存和磁盘中，在一段时间（等 master 恢复正常）后重新写入 master 来保证数据不丢失 。

哨兵节点主要负责三件事情：监控、选主、通知。

如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令，哨兵就会将它们标记为「主观下线」。

当一个哨兵判断主节点为「主观下线」后，就会向其他哨兵发起命令，其他哨兵收到这个命令后，就会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。 当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后，这时主节点就会被该哨兵标记为「客观下线」。

之所以针对「主节点」设计「主观下线」和「客观下线」两个状态，是因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。

1、第一轮投票：判断主节点下线

2、第二轮投票：选出哨兵leader

某个哨兵判定主节点客观下线后，该哨兵就会发起投票，告诉其他哨兵，它想成为 leader，想成为 leader 的哨兵节点，要满足两个条件：

  • 第一，拿到半数以上的赞成票；
  • 第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

3、由哨兵 leader 进行主从故障转移

选举出了哨兵 leader 后，就可以进行主从故障转移的过程了。该操作包含以下四个步骤：

  • 第一步：在已下线主节点（旧主节点）属下的所有「从节点」里面，挑选出一个从节点，并将其转换为主节点，选择的规则：
    • 过滤掉已经离线的从节点；
    • 过滤掉历史网络连接状态不好的从节点；
    • 将剩下的从节点，进行三轮考察：优先级、复制进度、ID 号。在每一轮考察过程中，如果找到了一个胜出的从节点，就将其作为新主节点。
  • 第二步：让已下线主节点属下的所有「从节点」修改复制目标，修改为复制「新主节点」；
  • 第三步：将新主节点的 IP 地址和信息，通过「发布者/订阅者机制」通知给客户端；
  • 第四步：继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点；

哨兵节点之间是通过 Redis 的发布者/订阅者机制来相互发现的。

img