2022-02-06

尾递归

什么是尾递归？
若函数在尾位置调用自身（或是一个尾调用本身的其他函数等等），则称这种情况为尾递归
尾调用的重要性在于它可以不在调用栈上面添加一个新的堆栈帧——而是更新它，如同迭代一般

但java中即使采用了这种编程方式实现了递归，也无法达到尾递归的效果

为啥java不支持呢，网上冲浪一番得出一些结论：

改变堆栈跟踪，从而使调试程序变得更加困难。我认为Java的主要目标之一是允许程序员轻松调试他们的代码，而堆栈跟踪对于做到这一点至关重要。
在高度面向对象的编程环境中。由于可以改用迭代，因此语言委员会必须认为不值得添加尾递归

布隆过滤器

布隆过滤器原理

这个是由柏顿.布隆在1970年提出
实现原理就是我们需要一个很长的二进制数组（也叫向量）；在添加数据时，使用多个hash函数对key进行hash运算得到一个索引值（即二进制数组的索引值）

redis中的布隆过滤器

Redis布隆过滤器的基本使用
在Redis中，布隆过滤器有两个基本命令，分别是：

bf.add：添加元素到布隆过滤器中，类似于集合的sadd命令，不过bf.add命令只能一次添加一个元素，如果想一次添加多个元素，可以使用bf.madd命令。
bf.exists：判断某个元素是否在过滤器中，类似于集合的sismember命令，不过bf.exists命令只能一次查询一个元素，如果想一次查询多个元素，可以使用bf.mexists命令。

上面的例子中使用的布隆过滤器只是默认参数的布隆过滤器，它在我们第一次使用 bf.add 命令时自动创建的。Redis还提供了自定义参数的布隆过滤器，想要尽量减少布隆过滤器的误判，就要设置合理的参数。

在使用 bf.add 命令添加元素之前，使用bf.reserve 命令创建一个自定义的布隆过滤器。bf.reserve命令有三个参数，分别是：

key：键
error_rate：期望错误率，期望错误率越低，需要的空间就越大。
capacity：初始容量，当实际元素的数量超过这个初始化容量时，误判率上升。

布隆过滤器的应用

1.防止缓存穿透
一般情况下，先查询缓存是否有该条数据，缓存中没有时，再查询数据库。当数据库也不存在该条数据时，每次查询都要访问数据库，这就是缓存穿透。缓存穿透带来的问题是，当有大量请求查询数据库不存在的数据时，就会给数据库带来压力，甚至会拖垮数据库。

可以使用布隆过滤器解决缓存穿透的问题，把已存在数据的key存在布隆过滤器中。当有新的请求时，先到布隆过滤器中查询是否存在，如果不存在该条数据直接返回；如果存在该条数据再查询缓存查询数据库。

2.黑名单校验
发现存在黑名单中的，就执行特定操作。比如：识别垃圾邮件，只要是邮箱在黑名单中的邮件，就识别为垃圾邮件。假设黑名单的数量是数以亿计的，存放起来就是非常耗费存储空间的，布隆过滤器则是一个较好的解决方案。把所有黑名单都放在布隆过滤器中，再收到邮件时，判断邮件地址是否在布隆过滤器中即可。

跳表VS红黑树

跳跃表其实也是一种通过“空间来换取时间”的一个算法，通过在每个节点中增加了向前的指针，从而提升查找的效率。

为什么redis zset使用跳表而不是红黑树？
1.按照区间来查找数据这个操作，红黑树的效率没有跳表高。
2.跳表更容易代码实现，而简单就意味着可读性好，不容易出错。
3.跳表更加灵活，它可以通过改变索引构建策略，有效平衡执行效率和内存消耗。

为什么hashmap用红黑树而不用跳表？
1.跳表是以空间换时间的数据结构，红黑树更节省空间
2.concurrentskiplistmap的实现就是跳表，说明在并发有序的要求场景下，跳表实现起来性价比更高，加锁难度也会小很多。

redis RDB VS AOF

RDB

RDB适合冷备份 将某个时间点的所有数据都存放到硬盘上。
优点：
1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复（将持久化到硬盘中的文件恢复即可）。
2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点:
1.如果你需要尽量避免在服务器故障时丢失数据，那么RDB 不适合你。 虽然Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据（最后一次的数据）。

2.每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF

追加到AOF文件的末尾，最后以不同的频次保存到到磁盘）适合热备
同步磁盘策略：
选项同步频率always每个写命令都同步everysec每秒同步一次no让操作系统来决定何时同步
always 选项会严重减低服务器的性能；
everysec 选项比较合适，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；
no 让操作系统来决定应该何时进行同步（并不能给服务器性能带来多大的提升，而且也会增加系统崩溃时数据丢失的数量）

随着服务器写请求的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的特性，能够去除 AOF 文件中的冗余写命令。
用户可以向 Redis 发送 BGREWRITEAOF 命令，这个命令会移除 AOF 文件中冗余的命令来重写 AOF 文件，使 AOF 文件的体积变得尽可能地小

优点：
1.AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
2.AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
3.AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

缺点：
1.对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。
虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 2.Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
3.RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

HashMap连环问

参考
https://zhuanlan.zhihu.com/p/163283988

redis的过期策略以及内存淘汰机制

分析:这个问题其实相当重要，到底redis有没用到家，这个问题就可以看出来。比如你redis只能存5G数据，可是你写了10G，那会删5G的数据。怎么删的，这个问题思考过么？还有，你的数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，有思考过原因么?
回答:
redis采用的是定期删除+惰性删除策略。
为什么不用定时删除策略?
定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.
定期删除+惰性删除是如何工作的呢?
定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。
采用定期删除+惰性删除就没其他问题了么?
不是的，如果定期删除没删除key。然后你也没及时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。
在redis.conf中有一行配置

#maxmemory-policy allkeys-lru
该配置就是配内存淘汰策略的(什么，你没配过？好好反省一下自己)
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用。
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key,去随机删。
4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐
ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

redis reactor模型

首先，Redis服务器中有两类事件，文件事件和时间事件。

文件事件（file event）：Redis客户端通过socket与Redis服务器连接，而文件事件就是服务器对套接字操作的抽象。例如，客户端发了一个GET命令请求，对于Redis服务器来说就是一个文件事件。

时间事件（time event）：服务器定时或周期性执行的事件。例如，定期执行RDB持久化。

在这里我们主要关注Redis处理文件事件的模型。参考《Redis的设计与实现》，Redis的文件事件处理模型是这样的：

在这个模型中，Redis服务器用主线程执行I/O多路复用程序、文件事件分派器以及事件处理器。而且，尽管多个文件事件可能会并发出现，Redis服务器是顺序处理各个文件事件的。

Redis服务器主线程的执行流程在Redis.c的main函数中体现，而关于处理文件事件的主要的有这几行：

int main(int argc, char **argv) {
   
    ...
    initServer();
    ...
    aeMain();
    ...
    aeDeleteEventLoop(server.el);
    return 0;
}

redis key value实现原理

本质也是数组+链表的形式来解决hash冲突，也会2倍扩容，和hashmap很类似，具体参考
https://www.cnblogs.com/wenbochang/p/11673590.html

2022-02-07

结合mvcc谈谈可重复读到底是怎么实现的

总体来说一句话：通过ReadView辅助记录记录事务版本号信息，继而通过查询比较undo log 版本链实现

不同事务的undo log是通过roll_pointer 指针链接在一起的。roll_pointer 指向上一条 undo log 日志。

具体参考 https://zhuanlan.zhihu.com/p/166152616

ReadView

什么是ReadView?
read view 用一个可见性的算法，来判断当前是读取真实的数据，还是undo log的数据。这里可以简单理解read view 内部维护了一个事物id列表，里面有最大值和最小值，可以判断其它事物的id是否在这个可见范围内。

Rr级别下的ReadView

在可重复读隔离级别下，只会在第一次执行查询语句时生成ReadView

因此我们发现两次查询，第二次无论时机如何，他们的结果都会根据第一次ReadView进行判断，结果就是“张石”。

由此可见可重复读隔离级别下可以避免不可重复读。

Rc级别下的ReadView

RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。

mysql中binlog redolog undolog 各自的作用

关系图

binlog

binlog 设计目标
binlog 是作为mysql操作记录归档的日志，这个日志记录了所有对数据库的数据、表结构、索引等等变更的操作。也就是说只要是对数据库有变更的操作都会记录到binlog里面来， 可以把数据库的数据当成我们银行账户里的余额，而binlog就相当于我们银行卡的流水。账户余额只是一个结果，至于这个结果怎么来的，那就必须得看流水了。而同样在mysql里我们就是通过binlog来归档、验证、恢复、同步数据。

binlog 记录内容
binlog应该说是Mysql里最核心的日志， 它记录了除了查询语句(select、show)之外的所有的 DDL 和 DML 语句,也就意味着我们基本上所有对数据库的操作变更都会记录到binlog里面。binlog以事件形式记录，不仅记录了操作的语句，同时还记录了语句所执行的消耗的时间。 binlog 有三种记录格式，分别是ROW、STATEMENT、MIXED。

1、ROW： 基于变更的数据行进行记录，如果一个update语句修改一百行数据，那么这种模式下就会记录100行对应的记录日志。

2、STATEMENT：基于SQL语句级别的记录日志，相对于ROW模式，STATEMENT模式下只会记录这个update 的语句。所以此模式下会非常节省日志空间，也避免着大量的IO操作。

3、MIXED： 混合模式，此模式是ROW模式和STATEMENT模式的混合体，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog。

这三种模式需要注意的是：使用 row 格式的 binlog 时，在进行数据同步或恢复的时候不一致的问题更容易被发现，因为它是基于数据行记录的。而使用 mixed 或者 statement 格式的 binlog 时，很多事务操作都是基于SQL逻辑记录，我们都知道一个SQL在不同的时间点执行它们产生的数据变化和影响是不一样的，所以这种情况下，数据同步或恢复的时候就容易出现不一致的情况。

binlog 写入策略
在进行事务的过程中，首先会把binlog 写入到binlog cache中（因为写入到cache中会比较快，一个事务通常会有多个操作，避免每个操作都直接写磁盘导致性能降低），事务最终提交的时候再吧binlog 写入到磁盘中。当然事务在最终commit的时候binlog是否马上写入到磁盘中是由参数 sync_binlog 配置来决定的。

1、sync_binlog=0 的时候，表示每次提交事务binlog不会马上写入到磁盘，而是先写到page cache,相对于磁盘写入来说写page cache要快得多,不过在Mysql 崩溃的时候会有丢失日志的风险。

2、sync_binlog=1 的时候，表示每次提交事务都会执行 fsync 写入到磁盘 ；

3、sync_binlog的值大于1 的时候，表示每次提交事务都 先写到page cach，只有等到积累了N个事务之后才fsync 写入到磁盘，同样在此设置下Mysql 崩溃的时候会有丢失N个事务日志的风险。

很显然三种模式下，sync_binlog=1 是强一致的选择，选择0或者N的情况下在极端情况下就会有丢失日志的风险，具体选择什么模式还是得看系统对于一致性的要求。

为什么statement模式下主从复制会有bug
如果使用了一些函数，statement 格式无法完成主从复制的操作。
因为执行的sql语句在不同的场景下可能会有不同的效果。比如sql中使用的了date（）函数，主从同步的时候用的不是原始存入的日期，而是当前日期。

redolog

redo log 设计目标
redo log 是属于引擎层(innodb)的日志，它的设计目标是支持innodb的“事务”的特性，事务ACID特性分别是原子性、一致性、隔离性、持久性， 一致性是事务的最终追求的目标，隔离性、原子性、持久性是达成一致性目标的手段，根据的文章我们已经知道隔离性是通过锁机制来实现的。 而事务的原子性和持久性则是通过redo log 和undo log来保障的。

redo log 能保证对于已经COMMIT的事务产生的数据变更，即使是系统宕机崩溃也可以通过它来进行数据重做，达到数据的一致性，这也就是事务持久性的特征，一旦事务成功提交后，只要修改的数据都会进行持久化，不会因为异常、宕机而造成数据错误或丢失,所以解决异常、宕机而可能造成数据错误或丢是redo log的核心职责。

redo log记录的内容
redo log记录的是操作数据变更的日志，听起来好像和binlog有类似的地方，有时候我都会想有了binlog为什么还要redo log，当然从其它地方可以找到很多的理由，但是我认为最核心的一点就是redo log记录的数据变更粒度和binlog的数据变更粒度是不一样的（事务提交前是不会记录bignlog的），也正因为这个binlog是没有进行崩溃恢复事务数据的能力的。

以修改数据为例，binlog 是以表为记录主体，在ROW模式下，binlog保存的表的每行变更记录。

比如update tb_user set age =18 where name =‘赵白’ ，如果这条语句修改了三条记录的话，那么binlog记录就是

 UPDATE `db_test`.`tb_user` WHERE @1=5 @2='赵白' @3=91 @4='1543571201' SET  @1=5 @2='赵白' @3=18 @4='1543571201'
 UPDATE `db_test`.`tb_user` WHERE @1=6 @2='赵白' @3=91 @4='1543571201' SET  @1=5 @2='赵白' @3=18 @4='1543571201'
 UPDATE `db_test`.`tb_user` WHERE @1=7 @2='赵白' @3=91 @4='1543571201' SET  @1=5 @2='赵白' @3=18 @4='1543571201'

redo log则是记录着磁盘数据的变更日志，以磁盘的最小单位“页”来进行记录。上面的修改语句，在redo log里面记录得可能就是下面的形式。

把表空间10、页号5、偏移量为10处的值更新为18。
把表空间11、页号1、偏移量为2处的值更新为18。
把表空间12、页号2、偏移量为9处的值更新为18。

当我们把数据从内存保存到磁盘的过程中，Mysql是以页为单位进行刷盘的，这里的页并不是磁盘的页，而是Mysql自己的单位，Mysql里的一页数据单位为16K，所以在刷盘的过程中需要把数据刷新到磁盘的多个扇区中去。 而把16K数据刷到磁盘的每个扇区里这个过程是无法保证原子性的，也就意味着Mysql把数据从内存刷到磁盘的过程中，如果数据库宕机，那么就可能会造成一步分数据成功，一部分数据失败的结果。而这个时候通过binlog这种级别的日志是无法恢复的，一个update可能更改了多个磁盘区域的数据，如果根据SQL语句回滚，那么势必会让那些已经刷盘成功的数据造成数据不一致。所以这个时候还是得需要通过redo log这种记录到磁盘数据级别的日志进行数据恢复。

redo log写入策略
redo lo占用的空间是一定的，并不会无线增大（可以通过参数设置），写入的时候是进顺序写的，所以写入的性能比较高。当redo log空间满了之后又会从头开始以循环的方式进行覆盖式的写入。

在写入redo log的时候也有一个redo log buffer，日志什么时候会刷到磁盘是通过innodb_flush_log_at_trx_commit 参数决定。

innodb_flush_log_at_trx_commit=0 ，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;

innodb_flush_log_at_trx_commit=1，表示每次事务提交时都将 redo log 直接持久化到磁盘；

innodb_flush_log_at_trx_commit=2，表示每次事务提交时都只是把 redo log 写到 page cache。

除了上面几种机制外，还有其它两种情况会把redo log buffer中的日志刷到磁盘。

1、定时处理：有线程会定时(每隔 1 秒)把redo log buffer中的数据刷盘。

2、根据空间处理：redo log buffer 占用到了一定程度( innodb_log_buffer_size 设置的值一半)占，这个时候也会把redo log buffer中的数据刷盘。

undolog

undo log设计目标
undo log 也属于引擎层(innodb)的日志，从上面的redo log介绍中我们就已经知道了，redo log 和undo log的核心是为了保证innodb事务机制中的持久性和原子性，事务提交成功由redo log保证数据持久性，而事务可以进行回滚从而保证事务操作原子性则是通过undo log 来保证的。

要对事务数据回滚到历史的数据状态，所以我们也能猜到undo log是保存的是数据的历史版本，通过历史版本让数据在任何时候都可以回滚到某一个事务开始之前的状态。undo log除了进行事务回滚的日志外还有一个作用，就是为数据库提供MVCC多版本数据读的功能。

undo log记录内容
在Mysql里数据每次修改前，都首先会把修改之前的数据作为历史保存一份到undo log里面的，数据里面会记录操作该数据的事务ID，然后我们可以通过事务ID来对数据进行回滚。

mysql事务隔离级别

读未提交（read-uncommitted）
不可重复读（read-committed）
可重复读（repeatable-read）
串行化（serializable）

为什么Mysql默认级别是rr

众所周知很多数据库默认级别都是rc，如oracle
mysql使用rr作为默认级别其实是和biglog的机制有关，因为MySQL早期只有statement这种bin log格式，这时候，如果使用提交读(Read Committed)、未提交读(Read Uncommitted)这两种隔离级别会出现问题。

此时查询 主库

+---+
| b |
+---+
| 3 |
+---+
1 row in set

查询从库

Empty set

这样，你就出现了主从不一致性的问题！原因其实很简单，就是在master上执行的顺序为先删后插！而此时binlog为STATEMENT格式，它记录的顺序为先插后删！从(slave)同步的是binglog，因此从机执行的顺序和主机不一致！就会出现主从不一致！

为了避免这样的问题发生。MySQL就把数据库的默认隔离级别设置成了Repetable Read，那么，Repetable Read的隔离级别下是如何解决这样问题的那？

那是因为Repetable Read这种隔离级别，会在更新数据的时候不仅对更新的行加行级锁，还会增加GAP lock。上面的例子，在事务2执行的时候，因为事务1增加了GAP lock，就会导致事务执行被卡住，需要等事务1提交或者回滚后才能继续执行。（关于GAP lock，我后面会有文章单独介绍）。

除了设置默认的隔离级别外，MySQL还禁止在使用statement格式的bin log的情况下，使用READ COMMITTED作为事务隔离级别。

一旦用户主动修改隔离级别，尝试更新时，会报错：

ERROR 1598 (HY000): Binary logging not possible. Message: Transaction
level ‘READ-COMMITTED’ in InnoDB is not safe for binlog mode 'STATEME

RR VS RC

1. 在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多；
2. 在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行；
3. 在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性；

什么是半一致读
具体参考： https://www.yht7.com/news/97107

以上列出了选择RC隔离级别的原因，但是使用RC隔离级别要注意一点，就是binlog的格式要设置为row模式，即记录每行实际数据的变更。

redis红锁

红锁解决什么问题？

当我们请求一个分布式锁的时候，成功了，但是这时候slave还没有复制我们的锁，masterDown了，我们的应用继续请求锁的时候，会从继任了master的原slave上申请，也会成功。

这就会导致，同一个锁被获取了不止一次

如何解决

用Redis中的多个master实例，来获取锁，只有大多数实例获取到了锁，才算是获取成功。具体的红锁算法分为以下五步：

1. 获取当前的时间（单位是毫秒）。
2. 使用相同的key和随机值在N个节点上请求锁。这里获取锁的尝试时间要远远小于锁的超时时间，防止某个masterDown了，我们还在不断的获取锁，而被阻塞过长的时间。
   只有在大多数节点上获取到了锁，而且总的获取时间小于锁的超时时间的情况下，认为锁获取成功了。
3. 如果锁获取成功了，锁的超时时间就是最初的锁超时时间进去获取锁的总耗时时间。
4. 如果锁获取失败了，不管是因为获取成功的节点的数目没有过半，还是因为获取锁的耗时超过了锁的释放时间，都会将已经设置了key的master上的key删除

redis哨兵模式

为什么要用哨兵模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

实现方式

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

1. 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2. 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换（failover）的过程。
假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

启动顺序

首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

优缺点

优点：
Redis Sentinel集群部署简单；
能够解决Redis主从模式下的高可用切换问题；
很方便实现Redis数据节点的线形扩展，轻松突破Redis自身单线程瓶颈，可极大满足Redis大容量或高性能的业务需求；
可以实现一套Sentinel监控一组Redis数据节点或多组数据节点。

缺点：
部署相对Redis主从模式要复杂一些，原理理解更繁琐；
资源浪费，Redis数据节点中slave节点作为备份节点不提供服务；
Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换，对Redis的数据节点做失败判定分为主观下线和客观下线两种，对于Redis的从节点有对节点做主观下线操作，并不执行故障转移。
不能解决读写分离问题，实现起来相对复杂。

2022-02-08

redis集群模式

为什么需要集群模式

即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。为了最大化利用内存，可以采用集群，就是分布式存储。即每台redis存储不同的内容，

优缺点

优点：
无中心架构；
数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；
可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除；
高可用性：部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升；
降低运维成本，提高系统的扩展性和可用性。

缺点：

1. Client实现复杂，驱动要求实现Smart Client，缓存slots
   mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
2. 节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout)，被判断下线，这种failover是没有必要的。
3. 数据通过异步复制，不保证数据的强一致性。
4. 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
5. Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率。
6. Key批量操作限制，如使用mset、mget目前只支持具有相同slot值的Key执行批量操作。对于映射为不同slot值的Key由于Keys不支持跨slot查询，所以执行mset、mget、sunion等操作支持不友好。
7. Key事务操作支持有限，只支持多key在同一节点上的事务操作，当多个Key分布于不同的节点上时无法使用事务功能。
8. Key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点。
9. 不支持多数据库空间，单机下的redis可以支持到16个数据库，集群模式下只能使用1个数据库空间，即db 0。
10. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
11. 避免产生hot-key，导致主库节点成为系统的短板。
12. 避免产生big-key，导致网卡撑爆、慢查询等。
13. 重试时间应该大于cluster-node-time时间。
14. Redis Cluster不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。

mysql之b-树 b+树

B-树

B-树,这里的 B 表示 balance( 平衡的意思),B-树是一种多路自平衡的搜索树（B树是一颗多路平衡查找树）
它类似普通的平衡二叉树，不同的一点是B-树允许每个节点有更多的子节点。下图是 B-树的简化图.

B-树有如下特点:

1. 所有键值分布在整颗树中（索引值和具体data都在每个节点里）；
2. 任何一个关键字出现且只出现在一个结点中；
3. 搜索有可能在非叶子结点结束（最好情况O(1)就能找到数据）； 在关键字全集内做一次查找,性能逼近二分查找；
4. B-树是专门为外部存储器设计的，如磁盘，它对于读取和写入大块数据有良好的性能，所以一般被用在文件系统及数据库中

为什么磁盘不使用AVL树，红黑树？

传统用来搜索的平衡二叉树有很多，如 AVL 树，红黑树等。这些树在一般情况下查询性能非常好，但当数据非常大的时候它们就无能为力了。原因当数据量非常大时，内存不够用，大部分数据只能存放在磁盘上，只有需要的数据才加载到内存中。一般而言内存访问的时间约为 50 ns，而磁盘在 10 ms 左右。速度相差了近 5 个数量级，磁盘读取时间远远超过了数据在内存中比较的时间。这说明程序大部分时间会阻塞在磁盘 IO 上。那么我们如何提高程序性能？减少磁盘 IO 次数，像 AVL 树，红黑树这类平衡二叉树从设计上无法“迎合”磁盘。

上图是一颗简单的平衡二叉树，平衡二叉树是通过旋转来保持平衡的，而旋转是对整棵树的操作，若部分加载到内存中则无法完成旋转操作。其次平衡二叉树的高度相对较大为 log n（底数为2），这样逻辑上很近的节点实际可能非常远，无法很好的利用磁盘预读（局部性原理），所以这类平衡二叉树在数据库和文件系统上的选择就被 pass 了。

空间局部性原理：如果一个存储器的某个位置被访问，那么将它附近的位置也会被访问。

网上很多的说法