一、关系型数据库和 NoSQL 数据库

1.1 数据库主要分为两大类：关系型数据库与 NoSQL 数据库

关系型数据库 ，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据主流的 MySQL 、 Oracle 、 MS SQL Server 和 DB2 都属于这类传统数据库。

---

NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。

 1.2 为什么还要用 NoSQL 数据库呢？

主要是由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的 NoSQL 产品， NoSQL 根本性的优势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高

 四、Redis的基本操作

五、Redis 主从复制

5.1 环境配置

redis-node1 master

redis-node2 slave

redis-node3 slave

 六、Redis的哨兵（高可用）

实验环境：我们用主两从来实现Redis的高可用架构

6.1 Redis哨兵

Sentinel 进程是用于监控 redis 集群中 Master 主服务器工作的状态，在 Master 主服务器发生故障的时候，可以实现Master 和 Slave 服务器的切换，保证系统的高可用，此功能在 redis2.6+ 的版本已引用， Redis 的哨兵模式到了2.8 版本之后就稳定了下来。一般在生产环境也建议使用 Redis 的 2.8 版本的以后版本

每个哨兵 (Sentinel) 进程会向其它哨兵 (Sentinel) 、 Master 、 Slave 定时发送消息，以确认对方是否 ” 活 ”着，如果发现对方在指定配置时间( 此项可配置 ) 内未得到回应，则暂时认为对方已离线，就是所谓的 ”主观认为宕机” ( 主观 : 是每个成员都具有的独自的而且可能相同也可能不同的意识 ) ，英文名称：Subjective Down，简称 SDOWN

有主观宕机，对应的有客观宕机。当 “ 哨兵群 ” 中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的 Master Server 下线判断，这种方式就是“ 客观宕机 ”( 客观 : 是不依赖于某种意识而已经实际存在的一切事物 ) ，英文名称是：Objectively Down， 简称 ODOWN

通过一定的 vote 算法，从剩下的 slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置，并开启故障转移（failover ）

Sentinel 机制可以解决 master 和 slave 角色的自动切换问题，但单个 Master 的性能瓶颈问题无法解决 , 类似于MySQL 中的 MHA 功能

Redis Sentinel 中的 Sentinel 节点个数应该为大于等于 3 且最好为奇数

---

sentinel 中的三个定时任务

• 每10秒每个sentinel对master和slave执行info
  • 发现slave节点
  • 确认主从关系
• 每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
  • 通过sentinel__:hello频道交互
  • 交互对节点的“看法”和自身信息
• 每1秒每个sentinel对其他sentinel和redis执行pi

 6.2 哨兵的实验过程

在所有阶段中关闭 protected-mode no

---

6.2.1.在master节点中

protected-mode no                      #关闭保护模式
port 26379                             #监听端口
daemonize no                           #进入不打如后台
pidfile /var/run/redis-sentinel.pid    #sentinel进程pid文件
loglevel notice                        #日志级别
sentinel monitor mymaster 172.25.254.100 6379 2     #创建sentinel监控监控master主机，2表示必须得到2票
sentinel down-after-milliseconds mymaster 10000     #master中断时长，10秒连不上视为
master下线
sentinel parallel-syncs mymaster 1             #发生故障转移后，同时开始同步新master数据的slave数量
sentinel failover-timeout mymaster 180000     #整个故障切换的超时时间为3分钟

6.2.2 启动服务

 6.3. 在整个架构中可能会出现的问题

问题：

在生产环境中如果 master 和 slave 中的网络出现故障，由于哨兵的存在会把 master 提出去

当网络恢复后， master 发现环境发生改变， master 就会把自己的身份转换成 slave

master 变成 slave 后会把网络故障那段时间写入自己中的数据清掉，这样数据就丢失了。

解决：

master 在被写入数据时会持续连接 slave ， mater 确保有 2 个 slave 可以写入我才允许写入

如果 slave 数量少于 2 个便拒绝写入

在matster中设定

七、Redis Cluster（无中心化设计）

7.1 Redis Cluster 工作原理

在哨兵 sentinel 机制中，可以解决 redis 高可用问题，即当 master 故障后可以自动将 slave 提升为 master ，从而可以保证redis 服务的正常使用，但是无法解决 redis 单机写入的瓶颈问题，即单机 redis 写入性能受限于单机的内存大小、并发数量、网卡速率等因素。

redis 3.0 版本之后推出了无中心架构的 redis cluster 机制，在无中心的 redis 集群当中，其每个节点保存当前节点数据和整个集群状态, 每个节点都和其他所有节点连接

---

Redis Cluster 特点如下

1. 所有Redis节点使用(PING机制)互联
2. 集群中某个节点的是否失效，是由整个集群中超过半数的节点监测都失效，才能算真正的失效
3. 客户端不需要proxy即可直接连接redis，应用程序中需要配置有全部的redis服务器IP
4. redis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上，读写需要到指定的redis node上进行操作，因此有多少个redis node相当于redis 并发扩展了多少倍，每个redis node 承担16384/N个槽位
5. Redis cluster预先分配16384个(slot)槽位，当需要在redis集群中写入一个key -value的时候，会使用CRC16(key) mod 16384之后的值，决定将key写入值哪一个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。

---

Redis cluster 架构

假如三个主节点分别是： A, B, C 三个节点，采用哈希槽 (hash slot) 的方式来分配 16384 个 slot 的话它们三个节点分别承担的slot 区间可以是：

节点A覆盖 0－5460
节点B覆盖 5461－10922
节点C覆盖 10923－16383

---

Redis cluster 主从架构

Redis cluster 的架构虽然解决了并发的问题，但是又引入了一个新的问题，每个 Redis master 的高可用如何解决？

那就是对每个 master 节点都实现主从复制 , 从而实现 redis 高可用性

---

Redis Cluster 部署架构说明

 7.2 创建redis cluster的前提

1. 每个redis node节点采用相同的硬件配置、相同的密码、相同的redis版本。
2. 每个节点必须开启的参数

cluster-enabled yes             #必须开启集群状态，开启后redis进程会有cluster显示
cluster-config-file nodes-6380.conf         #此文件有redis cluster集群自动创建和维护，不需要任何手动操作

1. 所有redis服务器必须没有任何数据
2. 先启动为单机redis且没有任何key value

 7.3 部署redis cluster

在所有 redis 主机中

vim /etc/redis/redis.conf

masterauth "123456" 
requirepass "123456" 
cluster-enabled yes 
cluster-config-file nodes-6379.conf 
cluster-node-timeout 15000 

启动

systemctl restart redis.service

进入认证

将文件复制到其他主机上

然后启动