关型数据库
关系型数据库：
是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据
主流的 MySQL、Oracle、MS SQL Server 和 DB2 都属于这类传统数据库
关型数据库的优缺点
特点：
1、数据关系模型基于关系模型，结构化存储，完整性约束
2、基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作
3、采用结构化的查询语言（SQL）做数据读写
4、操作需要数据的一致性，需要事务甚至是强一致性
优点：
1、保持数据的一致性（事务处理）
2、可以进行join等复杂查询
3、通用化，技术成熟
缺点：
1、数据读写必须经过sql解析，大量数据、高并发下读写性能不足
2、对数据做读写，或修改数据结构时需要加锁，影响并发操作
3、无法适应非结构化存储
4、扩展困难
5、昂贵、复杂
非关型数据库
NoSQL 数据库：
全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储
主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点
NoSQL 数据库优缺点
特点：
1、非结构化的存储
2、基于多维关系模型
3、具有特有的使用场景
优点：
1、高并发，大数据下读写能力较强
2、基本支持分布式，易于扩展，可伸缩
3、简单，弱结构化存储
缺点：
1、join等复杂操作能力较弱
2、事务支持较弱
3、通用性差
4、无完整约束复杂业务场景支持较差
Redis 数据库介绍
Redis简介
Redis 全称：Remote Dictionary Server
Redis是一个开源的、遵循BSD协议的、基于内存的而且目前比较流行的键值数据库(key-value database)，是一个非关系型数据库
Redis 提供将内存通过网络远程共享的一种服务，提供类似功能的还有memcached，但相比memcached，redis还提供了易扩展、高性能、具备数据持久性等功能。
Redis 在高并发、低延迟环境要求比较高的环境使用量非常广泛
Redis 特性
1、速度快：10WQPS，基于内存，C语言实现
2、单线程（纯内存、非阻塞、避免线程切换和竞态消耗）
3、持久化
4、支持多种数据结构
5、支持多种编程语言
6、功能丰富：支持Lua脚本,发布订阅，事务，pipeline等功能
7、简单：代码短小精悍（单机核心代码只有23000行左右）单线程开发容易，不依赖外部库，使用简单
8、主从复制
9、支持高可用和分布式
Redis 的应用场景
1、Session共享：常见于web集群中的Tomcat或者PHP中多web服务器session共享
2、缓存：数据查询、电商网站商品信息、新闻内容
3、计数器：访问排行榜、商品浏览数等和次数相关的数值统计场景
4、微博/微信社交场合：共同好友，粉丝数，关注，点赞评论等
5、消息队列：ELK的日志缓存、部分业务的订阅发布系统
6、地理位置：基于GEO(地理信息定位),实现摇一摇，附近的人，外卖等功能
缓存的实现流程
数据更新时：
写入数据时，进行的是mysql数据的写入，如果不成功则返回；如果成功，则删除Redis对应的选项，并返回
数据读取是：
读取数据时，首先读取存储在内存内的Redis数据，如果读取成功则将直接返回；
如果未读取到数据则进行mysql数据的读取，读取成功则将进行写对应的Redis数据，并将写好的Redis数据进行返回；
如果mysql数据依旧没有任何获取，则将进行不带任何数据的返回
Redis 的安装
rpm 包进行安装
可在网上进行下载相应的rpm包，或者使用本地的镜像源
安装操作：
[root@redis1 ~]# yum install redis -y
源码安装
1、安装编译环境
[root@redis1 ~]# yum install make gcc initscripts -y
2、下载相应的源码包
3、进行解压
[root@redis1 ~]# tar zxf redis-7.4.0.tar.gz
4、进行编译和安装
[root@redis1 ~]# make && make install
5、修改启动的相关文件内容
[root@redis1 utils]# vim install_server.sh
#注释掉其检测启动方式，不让其检测
6、启动 Redis
[root@redis1 ~]# ./install_server.sh
......
Please select the redis port for this instance: [6379] #端口号
Selecting default: 6379
Please select the redis config file name [/etc/redis/6379.conf] #配置文件
Selected default - /etc/redis/6379.conf
Please select the redis log file name [/var/log/redis_6379.log] #日志文件
Selected default - /var/log/redis_6379.log
Please select the data directory for this instance [/var/lib/redis/6379] #数据目录
Selected default - /var/lib/redis/6379
Please select the redis executable path [/usr/local/bin/redis-server] #命令路径
.....
Installation successful!
7、修改其配置文件
[root@redis1 ~]# vim /etc/redis/6379.conf
......
bind * -::*
......
[root@redis1 ~]# /etc/init.d/redis_6379 restart
#重启服务
8、测试
[root@redis1 ~]# redis-cli
127.0.0.1:6379> info
......
Redis 的基本操作
config get * #查看配置
select 1 #选择数据库（redisa中有0-15个数据库）
set key 数据 #写入数据
get key #获取数据
keys * #查看所有key
flushdb #清空当前数据库
flushall #清空所有数据库
move key 1 #移动key
del key #删除
rename oldkey newkey #改名
expire key 10 #设置过期时间（#如果没有设定数据过期时间，数据则会一直存在 /var/lib/redis/6379/dump.rdb 内存快照中）
persist key #设置持久化
keys user* #查询
exists key #判断是否存在
主从复制
主从同步过程
1、slave节点发送同步亲求到master节点
2、slave节点通过master节点的认证开始进行同步
3、master节点会开启bgsave进程发送内存rbd到slave节点，在此过程中是异步操作，也就是说master节点仍然可以进行写入动作
4、slave节点收到rdb后首先清空自己的所有数据
5、slave节点加载rdb并进行数据恢复
6、在master和slave同步过程中master还会开启新的bgsave进程把没有同步的数据进行缓存，然后通过自有的 replactionfeedslave 函数把未通过内存快照发送到slave的数据一条一条写入到slave中
主从同步配置
在配置多台 Redis 时建议用复制的方式节省编译时间
复制时应将 Redis 的整个目录复制至指定主机路径
复制时将 /usr/local/bin/ 下的关于 Redis 的数据一起复制
[root@redis1 ~]# scp -r /usr/local/bin 目标主机IP:/usr/local/
[root@redis1 ~]# rsync -al * /usr/local/bin 目标主机IP:/usr/local/
master 设备：
[root@redis1 ~]# vim /etc/redis/6379.conf
......
protected-mode no
#关闭其protected模式
......
root@redis1 ~]# /etc/init.d/redis_6379 restart
#重启服务
vlave 设备：
[root@redis1 ~]# /etc/init.d/redis_6379 restart
......
replicaof 172.25.254.10 6379
#指定其master设备IP和端口号
......
[root@redis1 ~]# /etc/init.d/redis_6379 restart
#重启服务
测试：
#进入master设备
[root@redis1 ~]# redis-cli
127.0.0.1:6379> info replication
#在mastser节点
[root@redis-node1 ~]# redis-cli
127.0.0.1:6379> set name 123
#在slave节点查看
[root@redis2 ~]# redis-cli
127.0.0.1:6379> get name
"123"
哨兵模式（高可用）
Redis 哨兵简介
1、Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，此功能在redis2.6+的版本已引用，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本
2、每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否"活"着，如果发现对方在指定配置时间(此项可配置)内未得到回应，则暂时认为对方已离线，也就是所谓的 "主观认为宕机 " （主观:是每个成员都具有的独自的而且可能相同也可能不同的意识），英文名称：Subjective Down，简称 sdown
3、有主观宕机，对应的就有客观宕机。当"哨兵群"中的多数Sentinel进程在对Master主服务器做出SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是 "客观宕机 " （客观:是不依赖于某种意识而已经实际存在的一切事物），英文名称是：Objectively Down， 简称 odown
4、通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）
5、Sentinel 机制可以解决master和slave角色的自动切换问题，但单个 Master 的性能瓶颈问题无法解决,类似于MySQL中的MHA功能
6、Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数
sentinel中的三个定时任务：
1、每10秒每个sentinel对master和slave执行info
（1）发现slave节点
（2）确认主从关系
2、每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
（1）通过sentinel__:hello频道交互
（2）交互对节点的"看法"和自身信息
3、每1秒每个sentinel对其他sentinel和redis执行ping动作
哨兵部署
1、修改哨兵配置文件路径
[root@redis1 ~]# cd redis-7.4.0/
[root@redis1 redis-7.4.0]# cp sentinel.conf /etc/redis/
#将源码包内的哨兵配置文件复制至Redsi配置目录下
2、修改 sentinel 配置文件
[root@redis1 ~]# vim /etc/redis/sentinel.conf
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分钟
3、将配置文件远程传输至其它的 Redis 主机
[root@redis1 ~]# scp /etc/redis/sentinel.conf root@目标主机IP:/etc/redis/
4、开启哨兵模式
[root@redis1 ~]# redis-sentinel /etc/redis/sentinel.conf
#开启哨兵模式后，哨兵程序会调用 " /etc/redis/sentinel.conf " 文件，并更改其配置文件，如果需要重新设定哨兵模式，需将原来的哨兵配置文件删除并重新编辑
测试：
当master主机宕机时，可查看哨兵模式下的页面信息
当故障设备恢复后，会成为slave设备并重新指向新的master
解决哨兵模式存在的问题
问题：
1、在生产环境中如果master和slave中的网络出现故障，由于哨兵的存在会把master踢出去
2、当网络恢复后，master发现环境发生改变，master就会把自己的身份转换成slave
3、master变成slave后会把网络故障那段时间写入自己中的数据清掉，这样数据就丢失了。
解决方案：
1、master在被写入数据时会持续连接slave，在mater确保有2个slave连接时，才能写入
2、如果slave数量少于2个则拒绝写入
#在matster中设定
[root@redis1 ~]# redis-cli
127.0.0.1:6379> CONFIG GET min-slaves-to-write
1) "min-slaves-to-write"
2) "0"
127.0.0.1:6379> CONFIG set min-slaves-to-write 2 #设定最少链接slave数量为2
OK
#如果要永久保存，则需要写到配置文件中/etc/redis/6379.conf
Redsi Cluster （无中心化设计）
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架构在写入数据时会遇到的情况：
1、当写入数据时，会通过算法计算出写入的数据应该在哪个哈希槽内；
2、如果不在当前写入的主机，则会报错并提示在哪台主机进行写入；
3、可以通过python脚本来进行数据的写入，这样就可以不用来回切换主机到指定的哈希槽
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 部署
创建 redis cluster 的前提：
1、每个redis node节点采用相同的硬件配置、相同的密码、相同的redis版本
2、每个节点必须开启的参数：
（1）cluster-enabled yes
#必须开启集群状态，开启后redis进程会有cluster显示
（2）cluster-config-file nodes-6379.conf
#此文件有redis cluster集群自动创建和维护，不需要任何手动操作
3、所有redis服务器必须没有任何数据
4、先启动为单机redis且没有任何key value
所有redis主机均配置：
#修改redis配置文件
[root@redis1 ~]# vim /etc/redis/redis.conf
......
bind * -::*
#开启端口
......
masterauth "123"
#集群主从认证
......
requirepass "123"
#集群登陆密码
#使用 redis-cli 命令连接redis数据库，进入数据库内使用 "auth 密码"进行认证
......
cluster-enabled yes
#开启cluster集群功能
......
cluster-config-file nodes-6379.conf
#指定集群配置文件
......
cluster-node-timeout 15000
#节点加入集群的超时时间单位是ms
......
[root@redis-master1 ~]# systemctl restart redis.service
#重启服务
redis-cli --cluster 参数
[root@redis1 ~]# redis-cli --cluster help
Cluster Manager Commands:
create host1:port1 ... hostN:portN #创建集群
--cluster-replicas <arg> #指定master的副本数
check <host:port> or <host> <port> #检测集群信息
info <host:port> or <host> <port> #查看集群信息
fix <host:port> or <host> <port> #修复集群
reshard <host:port> or <host> <port> #在线热迁移集群指定主机的slots数据
rebalance <host:port> or <host> <port> #平衡各集群主机的slot数量
add-node new_host:new_port existing_host:existing_port #添加主机
del-node host:port node_id #删除主机
import host:port #导入外部redis服务器的数据到当前集群
创建 redis-cluster 集群
创建流程如下：
[root@redis1 ~]# redis-cli --cluster create -a 123 \#创建redis集群
> 172.25.254.10:6379 172.25.254.20:6379 172.25.254.30:6379 \#添加集群设备
> 172.25.254.110:6379 172.25.254.120:6379 172.25.254.130:6379 \
> --cluster-replicas 1 #master的slave设备数为1
#集群配置文件：/var/lib/redis/nodes-6379.conf
检测redis集群状态：
[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379
#查看集群状态
[root@redis1 ~]# redis-cli -a 123 --cluster check 172.25.254.10:6379
#检测集群
写入数据：
[root@redis1 ~]# redis-cli -a 123
127.0.0.1:6379> set key1 value1
(error) MOVED 9189 172.25.254.20:6379
#提示该数据被分配到20的hash槽位上，应在20端进行写入
[root@redis2 ~]# redis-cli -a 123
127.0.0.1:6379> set key1 value1
OK
集群扩容
添加master：
[root@redis1 ~]# redis-cli -a 123 --cluster add-node 172.25.254.40:6379 172.25.254.10:6379
检测集群查看是否加入成功：
[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379
分配槽位（分配给master设备）：
[root@redis1 ~]# redis-cli -a 123 --cluster reshard 172.25.254.10:6379
添加slave：
[root@redis1 ~]# redis-cli -a 123 --cluster add-node 172.25.254.140:6379 172.25.254.10:6379 --cluster-slave --cluster-master-id 9ba748102ca1bcf27ff08e1b0407c1ddfbcf33ee
#（172.25.254.140:6379）指定要加入集群的设备IP；（172.25.254.10:6379）指定集群；（009571cb206a89afa6658b60b2d403136056ac09）指定master设备ID
检测集群查看是否加入成功：
[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379
集群的维护
添加节点的时候是先添加node节点到集群，然后分配槽位，删除节点的操作与添加节点的操作正好相反，是先将被删除的Redis node上的槽位迁移到集群中的其他Redis node节点上，然后再将其删除，如果一个Redis node节点上的槽位没有被完全迁移，删除该node的时候会提示有数据且无法删除
移除槽位：
[root@redis1 ~]# redis-cli -a 123 --cluster reshard 172.25.254.10:6379
......
How many slots do you want to move (from 1 to 16384)? 4096
What is the receiving node ID? 9f2f2dc6c43aebd4cfc9af5d6629a3b2513c3345
......
Source node #1: 3e6122890e25ad57fc1009db1f18f0ed5295349c
Source node #2: done
......
查看设备的槽位是否移除成功：
[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379
移除设备：
[root@redis1 ~]# redis-cli -a 123 --cluster del-node 172.25.254.110:6379 3e6122890e25ad57fc1009db1f18f0ed5295349c
#（172.25.254.120:6379）移除设备的IP和端口；（d458f34fa900d83212c021dc1e65396e490b5495）需进行移除的设备ID
