关系型数据库和 NoSQL 数据库
数据库主要分为两大类：关系型数据库与 NoSQL 数据库
关系型数据库是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据中数据主流的 MySQL、Oracle、MS SQL Server 和 DB2 都属于这类传统数据库。
NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。
RDBMS和NOSQL的特点及优缺点：
为什么还要用 NoSQL 数据库呢？
主要是由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的 NoSQL 产品，NoSQL 根本性的优势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高
redis简介
什么是redis
Redis (Remote Dictionary Server)
在2009年发布，开发者是意大利的萨尔瓦多·桑菲利波普（Salvatore Sanfilippo），他本想为自己的公司开发一个用于替换MySQL的产品Redis，但是没有想到他把Redis开源后大受欢迎，短短几年，Redis就有了很大的用户群体，目前国内外使用的公司众多,比如:阿里,百度,新浪微博,知乎网,GitHub,Twitter 等。
Redis是一个开源的、遵循BSD协议的、基于内存的而且目前比较流行的键值数据库(key-value database)，是一个非关系型数据库，redis 提供将内存通过网络远程共享的一种服务，提供类似功能的还有memcached，但相比memcached，redis还提供了易扩展、高性能、具备数据持久性等功能。
Redis 在高并发、低延迟环境要求比较高的环境使用量非常广泛
Redis特性
速度快: 10W QPS,基于内存,C语言实现
单线程
持久化
支持多种数据结构
支持多种编程语言
功能丰富: 支持Lua脚本,发布订阅,事务,pipeline等功能
简单: 代码短小精悍(单机核心代码只有23000行左右),单线程开发容易,不依赖外部库,使用简单
主从复制
支持高可用和分布式
单线程为何如此快?
纯内存
非阻塞
避免线程切换和竞态消耗
Redis应用场景
Session 共享：常见于web集群中的Tomcat或者PHP中多web服务器session共享
缓存：数据查询、电商网站商品信息、新闻内容
计数器：访问排行榜、商品浏览数等和次数相关的数值统计场景
微博/微信社交场合：共同好友,粉丝数,关注,点赞评论等
消息队列：ELK的日志缓存、部分业务的订阅发布系统
地理位置: 基于GEO(地理信息定位),实现摇一摇,附近的人,外卖等功能
缓存的实现流程
数据更新操作流程
数据读操作流程
Redis的安装
# dnf install redis -y 【不建议使用，用下面的方法】
源码安装
在一台主机中不能即用rpm安装也用源码安装
node1 ~]# tar zxf redis-7.4.0.tar.gz
# dnf install make gcc initscripts-10.11.6-1.el9.x86_64 -y
# make && make install
启动Redis
# cd utils/
# ./install_server.sh 【启动，但会报错】
# vim install_server.sh 【编译文件，格式化报错】
# ./install_server.sh 【这里全部回车】
配置redis
# vim /etc/redis/6379.conf
# /etc/init.d/redis_6379 restart
# netstat -antlpe | grep redis 查看端口：
# redis-cli
127.0.0.1:6379> info ##【查看redis】
# scp -r /mnt/redis-7.4.0 root@172.25.254.20:/mnt 【复制文件】
# scp -r /mnt/redis-7.4.0 root@172.25.254.30:/mnt
# rsync -a /usr/local/bin/ root@172.25.254.20:/usr/local/bin/ 【同步设备文件】
# rsync -a /usr/local/bin/ root@172.25.254.30:/usr/local/bin/
Redis的基本操作
# redis-cli
> select 1 【选择库】
查看配置
> CONFIG GET bind 【查看bind配置】
> CONFIG GET * 【查看所有】
写入和读取数据
> SET name lee 【设置名称数据】
> GET name
> set name lee ex 5
OK
> get name 【5秒后过期】
> KEYS * 【查看所有key数据】
移动数据
> set name lee
> MOVE name 1 【移动数据】
> GET name
> select 1
> get name
设定数据过期时间
> EXPIRE name 3 【更改name变3秒过期】
删除
> del name
改变键名
> RENAME name id 【修改name数据变id】
> get name
> get id 【查看id】
持久化保存
> PERSIST name
判断key是否存在
> EXISTS name 【查看name是否存在】
清空库
> flushdb 【清空当前库】
> FLUSHAL 【清空所有】
Redis 主从复制
在配置多台redis时建议用复制的方式节省编译时间
配置主从同步
修改mastser节点的配置文件
所有库 ~]# dnf install make gcc initscripts-10.11.6-1.el9.x86_64 -y
# /mnt/redis-7.4.0/utils/install_server.sh
# vim /etc/redis/6379.conf
# /etc/init.d/redis_6379 restart
# systemctl enable --now redis_6379 【开机启动】
配置slave节点
node（2和3） ~]# vim /etc/redis/6379.conf
# /etc/init.d/redis_6379 restart
> info replication
测试效果
主库
# redis-cli
> set name lee
从库
# redis-cli
> get name
如果没有成功做下面配置
node1 ]# vim /etc/rc.d/init.d/redis_6379
# chmod +x /etc/rc.d/init.d/redis_6379
# systemctl daemon-reload 【重启】
# systemctl stop redis_6379
# pkill -9 redis-server
# systemctl start redis_6379
# netstat -antlupe | grep 6379 运行结果：
主从同步过程
slave节点发送同步亲求到master节点
slave节点通过master节点的认证开始进行同步
master节点会开启bgsave进程发送内存rbd到slave节点，在此过程中是异步操作，也就是说master节点仍然可以进行写入动作
slave节点收到rdb后首先清空自己的所有数据
slave节点加载rdb并进行数据恢复
在master和slave同步过程中master还会开启新的bgsave进程把没同步的数据缓存
然后通过自有的replactionfeedslave函数把未通过内存快照发动到slave的数据一条一条写入到slave中
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
哨兵的实验过程
在所有阶段中关闭 protected-mode no
编辑配置文件
node1 ]# cd /mnt/redis-7.4.0/
# cp sentinel.conf /etc/redis/
# 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.10 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分钟
# scp /etc/redis/sentinel.conf root@172.25.254.20:/etc/redis/
# scp /etc/redis/sentinel.conf root@172.25.254.30:/etc/redis/
注意：/etc/redis/sentinel.conf 文件在用哨兵程序调用后会更改其配置文件，如果需要重新做需要删掉文件重新编辑
所有node ]# redis-sentinel /etc/redis/sentinel.conf
node1 ]# redis-cli
> shutdown
node3 ~]# redis-cli
> info replication
这个时候10重启数据库
node3 ~]# redis-cli
> info replication
在整个架构中可能会出现的问题
在生产环境中如果master和slave中的网络出现故障，由于哨兵的存在会把master提出去，当网络恢复后，master发现环境发生改变，master就会把自己的身份转换成slave
master变成slave后会把网络故障那段时间写入自己中的数据清掉，这样数据就丢失了。
解决：
master在被写入数据时会持续连接slave，mater确保有2个slave可以写入我才允许写入，如果slave数量少于2个便拒绝写入
# redis-cli
> CONFIG GET min-slaves-to-write
> CONFIG set min-slaves-to-write 2
> CONFIG GET min-slaves-to-write
当一个从库挂掉了
如果要永久保存写到配置文件中/etc/redis/6379.conf
Redis 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 架构
假如三个主节点分别是：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.每个节点必须开启的参数
cluster-enabled yes #必须开启集群状态，开启后redis进程会有cluster显示
cluster-config-file nodes-6380.conf #此文件有redis cluster集群自动创建和维护，不需要任何手动操作
3.所有redis服务器必须没有任何数据
4.先启动为单机redis且没有任何key value
部署redis cluster
在所有redis主机中
所有库 ]# /etc/init.d/redis_6379 stop
# cd /mnt/redis-7.4.0/
# make uninstall
# find / -name redis -exec rm -fr {} \; 【删除残留文件】
# for i in 10 20 30 40 50 60 70 80; do ssh -l root 172.25.254.$i dnf install redis -y; done
# vim /etc/redis/redis.conf 【编译主配置文件】
masterauth "123456" #集群主从认证
requirepass "123456" # redis登陆密码 redis-cli 命令连接redis后要用“auth 密码”进行认证
cluster-enabled yes #开启cluster集群功能
cluster-config-file nodes-6379.conf #指定集群配置文件
cluster-node-timeout 15000 #节点加入集群的超时时间单位是ms
# systemctl enable --now redis
# systemctl restart redis
# redis-cli
redis-cli --cluster 参数说明
# 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
# for i in 10 20 30 40 50 60 70 80; do scp /etc/redis/redis.conf root@172.25.254.$i:/etc/redis/redis.conf; done
# for i in 10 20 30 40 50 60 70 80; do ssh -l root 172.25.254.$i systemctl enable redis; done
# redis-cli --cluster create -a 123456 172.25.254.10:6379 172.25.254.20:6379 172.25.254.30:6379 172.25.254.40:6379 172.25.254.50:6379 172.25.254.60:6379
# ll /var/lib/redis/nodes-6379.conf 【保存集群节点信息的文件】
# rm -fr /var/lib/redis/nodes-6379.conf
# redis-cli cluster reset hardis 【重启】
检测redis集群状态
# redis-cli -a 123456 --cluster info 172.25.254.10:6379 【查看集群状态】
# redis-cli -a 123456 cluster info
# redis-cli -a 123456 --cluster check 172.25.254.10:6379 【检测集群】
写入数据
10 ]# redis-cli -a 123456
> set key1 value1 #被分配到30的hash槽位上
20 ]# redis-cli -a 123456
> set key1 value1
集群扩容
# redis-cli -a 123456 --cluster add-node 172.25.254.40:6379 172.25.254.10:6379 【添加主库】
# redis-cli -a 123456 --cluster info 172.25.254.10:6379
分配槽位
# redis-cli -a 123456 --cluster reshard 172.25.254.10:6379
添加salve
# redis-cli -a 123456 --cluster add-node 172.25.254.40:6379 172.25.254.10:6379 --cluster-slave --cluster-master-id 547912600b38f37da74619e683f3952b155c690a
clsuter集群维护
添加节点的时候是先添加node节点到集群，然后分配槽位，删除节点的操作与添加节点的操作正好相反，是先将被删除的Redis node上的槽位迁移到集群中的其他Redis node节点上，然后再将其删除，如果一个Redis node节点上的槽位没有被完全迁移，删除该node的时候会提示有数据且无法删除。
移除要下线主机的哈希槽位
30 ~]# redis-cli -a 123456 --cluster reshard 172.25.254.30:6379
删除slave和master
30 ~]# redis-cli -a 123456 --cluster del-node 172.25.254.70:6379 14a463019adc36dbd17c5ad284f989da04b83740
# redis-cli -a 123456 --cluster del-node 172.25.254.10:6379 547912600b38f37da74619e683f3952b155c690a
# redis-cli -a 123456 --cluster info 172.25.254.10:6379
