共计 5088 个字符，预计需要花费 13 分钟才能阅读完成。
redis 的五种数据类型
1、string（字符串）；2、hash（哈希）；3、list（列表）；4、set（汇合）；5、sort set（有序汇合）。其中，string（字符串）是 redis 中最根本的数据类型，一个 key 对应一个 value，string 能够蕴含任何数据。Redis 为什么这么快？
（1）齐全基于内存，数据存在内存中，绝大部分申请是纯正的内存操作，十分疾速，跟传统的磁盘文件数据存储相比，防止了通过磁盘 IO 读取到内存这部分的开销。
（2）数据结构简略，对数据操作也简略。Redis 中的数据结构是专门进行设计的，每种数据结构都有一种或多种数据结构来反对。Redis 正是依赖这些灵便的数据结构，来晋升读取和写入的性能。
（3）采纳单线程，省去了很多上下文切换的工夫以及 CPU 耗费，不存在竞争条件，不必去思考各种锁的问题，不存在加锁开释锁操作，也不会呈现死锁而导致的性能耗费。
（4）应用基于 IO 多路复用机制的线程模型，能够解决并发的链接。
Redis 基于 Reactor 模式开发了本人的网络事件处理器，这个处理器被称为文件事件处理器 file event handler。因为这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型，然而它采纳 IO 多路复用机制同时监听多个 Socket，并依据 Socket 上的事件来抉择对应的事件处理器进行解决。文件事件处理器的构造蕴含 4 个局部
redis 分布式锁怎么应用？
原理：基于 setNX 命令，避免死锁须要设置过期工夫，避免过期时程序未实现，须要主动续期。主动续期能够应用 redision 的 watchdog 实现。应用流程：先上锁，如果上锁胜利则执行业务，最初开释锁。如果上锁失败则返回或重试等，依据业务状况而定。什么是 Redis 的脑裂景象
当 Redis 主从集群环境呈现两个主节点为客户端提供服务，这时客户端申请命令可能会产生数据失落的状况。脑裂带来的影响
脑裂呈现后带来最重大的结果就是数据失落，为什么会呈现数据失落的问题呢，次要起因是新主库确定后会向所有的实例发送 slave of 命令，让所有实例从新进行全量同步，而全量同步首先就会将实例上的数据先清空，所以在主从同步期间在原主库执行的命令将会被清空（下面场景二是同样的情理，在网络分区复原后原主节点将被降级为从节点，并且执行全量同步导致数据失落），所以这就是数据失落的具体起因。如何应答脑裂
脑裂的次要起因其实就是哨兵集群认为主节点曾经呈现故障了，从新选举其它从节点作为主节点，而原主节点其实是假故障，从而导致短暂的呈现两个主节点，那么在主从切换期间客户端一旦给原主节点发送命令，就会造成数据失落。所以应答脑裂的解决办法应该是去限度原主库接管申请，Redis 提供了两个配置项。min-slaves-to-write：与主节点通信的从节点数量必须大于等于该值主节点，否则主节点回绝写入。min-slaves-max-lag：主节点与从节点通信的 ACK 音讯提早必须小于该值，否则主节点回绝写入。这两个配置项必须同时满足，不然主节点回绝写入。在假故障期间满足 min-slaves-to-write 和 min-slaves-max-lag 的要求，那么主节点就会被禁止写入，脑裂造成的数据失落状况天然也就解决了。总结
Redis 脑裂能够采纳 min-slaves-to-write 和 min-slaves-max-lag 合理配置尽量躲避，但无奈彻底解决，Redis 脑裂最实质的问题是主从集群外部没有共识算法来保护多个节点的强一致性，它不像 Zookeeper 那样，每次写入必须大多数节点胜利后才算胜利，当脑裂产生时，Zookeeper 节点被孤立，此时无奈写入大多数节点，写申请会间接失败，因而 Zookeeper 能力保障集群的强一致性。Redis 的各种集群计划、及优缺点比照
1. 主从模式
redis 单节点尽管有通过 RDB 和 AOF 长久化机制能将数据长久化到硬盘上，但数据是存储在一台服务器上的，如果服务器呈现硬盘故障等问题，会导致数据不可用，而且读写无奈拆散，读写都在同一台服务器上，申请量大时会呈现 I / O 瓶颈。为了防止单点故障 和 读写不拆散，Redis 提供了复制（replication）性能实现 master 数据库中的数据更新后，会主动将更新的数据同步到其余 slave 数据库上。如上 redis 主从构造特点：一个 master 能够有多个 salve 节点；salve 节点能够有 slave 节点，从节点是级联构造。
主从模式优缺点
1. 长处: 主从构造具备读写拆散，提高效率、数据备份，提供多个正本等长处。
2. 有余: 最大的有余就是主从模式不具备主动容错和复原性能，主节点故障，集群则无奈进行工作，可用性比拟低，从节点升主节点须要人工手动干涉。
一般的主从模式，当主数据库解体时，须要手动切换从数据库成为主数据库:
1. 在从数据库中应用 SLAVE NO ONE 命令将从数据库晋升成主数据持续服务。
2. 启动之前解体的主数据库，而后应用 SLAVEOF 命令将其设置成新的主数据库的从数据库，即可同步数据。
2. 哨兵模式
第一种主从同步 / 复制的模式，当主服务器宕机后，须要手动把一台从服务器切换为主服务器，这就须要人工干预，麻烦费劲，还会造成一段时间内服务不可用，这时候就须要哨兵模式退场了。哨兵模式是从 Redis 的 2.6 版本开始提供的，然而过后这个版本的模式是不稳固的，直到 Redis 的 2.8 版本当前，这个哨兵模式才稳定下来。
哨兵模式外围还是主从复制，只不过在绝对于主从模式在主节点宕机导致不可写的状况下，多了一个竞选机制：从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在零碎中启动一个 sentinel 过程。
如上图，哨兵自身也有单点故障的问题，所以在一个一主多从的 Redis 零碎中，能够应用多个哨兵进行监控，哨兵不仅会监控主数据库和从数据库，哨兵之间也会互相监控。每一个哨兵都是一个独立的过程，作为过程，它会独立运行。
(1)哨兵模式的作用：
监控所有服务器是否失常运行：通过发送命令返回监控服务器的运行状态，解决监控主服务器、从服务器外，哨兵之间也互相监控。
故障切换：当哨兵监测到 master 宕机，会主动将 slave 切换成 master，而后通过公布订阅模式告诉其余的从服务器，批改配置文件，让它们切换 master。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即便复原时，并不会复原原来的主身份，而是作为新主的一个从。
(2)哨兵实现原理
哨兵在启动过程时，会读取配置文件的内容，通过如下的配置找出须要监控的主数据库：
sentinel monitor master-name ip port quorum
master-name 是主数据库的名字
ip 和 port 是以后主数据库地址和端口号
quorum 示意在执行故障切换操作前，须要多少哨兵节点批准。
这里之所以只须要连贯主节点，是因为通过主节点的 info 命令，获取从节点信息，从而和从节点也建设连贯，同时也能通过主节点的 info 信息晓得新增从节点的信息。
一个哨兵节点能够监控多个主节点，然而并不提倡这么做，因为当哨兵节点解体时，同时有多个集群切换会产生故障。哨兵启动后，会与主数据库建设两条连贯。
1. 订阅主数据库_sentinel_:hello 频道以获取同样监控该数据库的哨兵节点信息
2. 定期向主数据库发送 info 命令，获取主数据库自身的信息。
跟主数据库建设连贯后会定时执行以下三个操作：
（1）每隔 10s 向 master 和 slave 发送 info 命令。作用是获取以后数据库信息，比方发现新增从节点时，会建设连贯，并退出到监控列表中，当主从数据库的角色发生变化进行信息更新。
（2）每隔 2s 向主数据里和从数据库的_sentinel_:hello 频道发送本人的信息。作用是将本人的监控数据和哨兵分享。每个哨兵会订阅数据库的_sentinel:hello 频道，当其余哨兵收到音讯后，会判断该哨兵是不是新的哨兵，如果是则将其退出哨兵列表，并建设连贯。
（3）每隔 1s 向所有主从节点和所有哨兵节点发送 ping 命令，作用是监控节点是否存活。
(3)主观下线和主观下线
哨兵节点发送 ping 命令时，当超过肯定工夫 (down-after-millisecond) 后，如果节点未回复，则哨兵认为主观下线。主观下线示意以后哨兵认为该节点曾经上面，如果该节点为主数据库，哨兵会进一步判断是够须要对其进行故障切换，这时候就要发送命令 (SENTINEL is-master-down-by-addr) 询问其余哨兵节点是否认为该主节点是主观下线，当达到指定数量 (quorum) 时，哨兵就会认为是主观下线。
当主节点主观下线时就须要进行主从切换，主从切换的步骤为：
（1）选出领头哨兵。
（2）领头哨兵所有的 slave 选出优先级最高的从数据库。优先级能够通过 slave-priority 选项设置。
（3）如果优先级雷同，则从复制的命令偏移量越大（即复制同步数据越多，数据越新），越优先。
（4）如果以上条件都一样，则抉择 run ID 较小的从数据库。
选出一个从数据库后，哨兵发送 slave no one 命令降级为主数据库，并发送 slaveof 命令将其余从节点的主数据库设置为新的主数据库。
(4)哨兵模式优缺点
1. 长处
哨兵模式是基于主从模式的，解决可主从模式中 master 故障不能够主动切换故障的问题。
2. 有余 - 问题
（1）是一种中心化的集群实现计划：始终只有一个 Redis 主机来接管和解决写申请，写操作受单机瓶颈影响。
（2）集群里所有节点保留的都是全量数据，节约内存空间，没有真正实现分布式存储。数据量过大时，主从同步重大影响 master 的性能。
（3）Redis 主机宕机后，哨兵模式正在投票选举的状况之外，因为投票选举完结之前，谁也不晓得主机和从机是谁，此时 Redis 也会开启爱护机制，禁止写操作，直到选举出了新的 Redis 主机。
主从模式或哨兵模式每个节点存储的数据都是全量的数据，数据量过大时，就须要对存储的数据进行分片后存储到多个 redis 实例上。此时就要用到 Redis Sharding 技术。
4.Redis Cluster
Redis 的哨兵模式尽管曾经能够实现高可用，读写拆散，然而存在几个方面的有余：
哨兵模式下每台 Redis 服务器都存储雷同的数据，很节约内存空间；数据量太大，主从同步时重大影响了 master 性能。
哨兵模式是中心化的集群实现计划，每个从机和主机的耦合度很高，master 宕机到 salve 选举 master 复原期间服务不可用。
哨兵模式始终只有一个 Redis 主机来接管和解决写申请，写操作还是受单机瓶颈影响，没有实现真正的分布式架构。
redis 在 3.0 上退出了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的数据。cluster 模式为了解决单机 Redis 容量无限的问题，将数据按肯定的规定调配到多台机器，内存 /QPS 不受限于单机，可受害于分布式集群高扩展性。Redis Cluster 是一种服务器 Sharding 技术(分片和路由都是在服务端实现)，采纳多主多从，每一个分区都是由一个 Redis 主机和多个从机组成，片区和片区之间是互相平行的。Redis Cluster 集群采纳了 P2P 的模式，齐全去中心化。
如上图，官网举荐，集群部署至多要 3 台以上的 master 节点，最好应用 3 主 3 从六个节点的模式。Redis Cluster 集群具备如下几个特点：
集群齐全去中心化，采纳多主多从；所有的 redis 节点彼此互联(PING-PONG 机制)，外部应用二进制协定优化传输速度和带宽。
客户端与 Redis 节点直连，不须要两头代理层。客户端不须要连贯集群所有节点，连贯集群中任何一个可用节点即可。
每一个分区都是由一个 Redis 主机和多个从机组成，分片和分片之间是互相平行的。
每一个 master 节点负责保护一部分槽，以及槽所映射的键值数据；集群中每个节点都有全量的槽信息，通过槽每个 node 都晓得具体数据存储到哪个 node 上。
redis cluster 次要是针对海量数据 + 高并发 + 高可用的场景，海量数据，如果你的数据量很大，那么倡议就用 redis cluster，数据量不是很大时，应用 sentinel 就够了。redis cluster 的性能和高可用性均优于哨兵模式。
Redis Cluster 采纳虚构哈希槽分区而非一致性 hash 算法，事后调配一些卡槽，所有的键依据哈希函数映射到这些槽内，每一个分区内的 master 节点负责保护一部分槽以及槽所映射的键值数据。
