关系型数据库的特点
- 结构化数据存储：关系型数据库使用表格结构来组织数据，每一行代表一条记录，每一列代表一个字段，数据之间通过外键等关系相互关联。
- 数据完整性：支持定义主键、外键等约束，保证数据的准确性和一致性。
- SQL查询语言：使用结构化查询语言（SQL）进行数据的查询、插入、更新和删除操作。
- 事务管理：支持事务处理，确保数据库操作的原子性、一致性、隔离性和持久性（ACID属性）。
- 复杂查询能力：支持复杂的多表连接查询、聚合函数、子查询等。
- 可扩展性：通过分布式数据库系统、集群技术等手段实现一定程度的水平扩展。
NoSQL数据库的特点
- 非关系型数据模型：NoSQL数据库采用键值对、文档、图形等多种数据模型，不需要预先定义表结构，可以根据实际需求动态调整数据模型。
- 高性能和高扩展性：通常具有更高的读写性能，特别是在处理大量写入操作时更为高效，支持水平扩展，可以在集群中添加更多的节点来提高性能和容量。
- 最终一致性：通常采用最终一致性模型，即在数据更新后，不保证立即在所有节点上一致，而是在一段时间内达到一致状态。
- 简单的事务支持：事务支持较弱，部分NoSQL数据库可能不支持事务或只支持简单的事务处理4。
- 灵活的数据模型：可以存储非结构化或半结构化数据，数据结构要求不严格，表结构可变。
- 高可用性：可以方便地实现高可用的架构，例如通过复制模型来实现NoSQL的高可用。
关系型数据库与NoSQL数据库的区别
- 数据模型：关系型数据库基于表结构，而NoSQL数据库支持多种数据模型，如键值对、文档、图形等。
- 扩展性：关系型数据库的扩展性相对较弱，主要通过垂直扩展来提升性能，而NoSQL数据库设计之初就考虑了水平扩展。
- 一致性和事务支持：关系型数据库追求强一致性和完整的事务支持，而NoSQL数据库通常采用最终一致性模型，事务支持较弱。
- 查询能力：关系型数据库提供丰富的查询操作和聚合函数，支持复杂的SQL查询语句，而NoSQL数据库的查询能力相对较弱，通常只支持基本的查询操作。
- 应用场景：关系型数据库适用于需要强一致性、复杂查询和事务处理的应用场景，如银行系统、电商订单管理等；NoSQL数据库适用于需要高扩展性、高性能和高可用性的应用场景，如大数据分析、社交网络、物联网等
redis源码安装
tar zxf redis-7.4.0.tar.gz
dnf install make gcc initscripts -y
[root@redis-node1 redis-7.4.0]#make
[root@redis-node1 redis-7.4.0]# make install
cd redis-7.4.0
cd utils/
vim install_server.sh
注释以下内容
启动redis
vim /etc/redis/6379.conf
配置端口
主从复制
Redis主从复制的原理
Redis主从复制是一种数据复制技术，它允许将主服务器（Master）的数据实时复制到一个或多个从服务器（Slave）。主从复制的主要目的是实现数据的高可用性、读写分离以及数据备份。
主从复制的过程主要包括以下几个步骤：
- 建立连接：从服务器连接到主服务器，并进行身份验证（如果配置了密码）。
- 全量复制：对于初次同步或从服务器数据丢失的情况，主服务器会执行
BGSAVE命令生成RDB快照文件，并将该文件发送给从服务器。同时，主服务器还会记录从当前RDB快照生成后收到的所有写命令到复制缓冲区中。 - 命令传播：全量复制完成后，主服务器会将复制缓冲区中的写命令发送给从服务器，确保主从数据一致性。
- 增量复制：在主从复制环境中，如果从服务器与主服务器的连接中断，从服务器可以在重新连接时请求增量复制。主服务器会根据从服务器的复制偏移量，发送自断开连接以来主服务器执行的写命令，以实现数据的部分同步。
Redis主从复制的作用
Redis主从复制的作用主要包括：
- 数据冗余：通过在不同的服务器上保持数据的副本，提高数据的安全性，防止数据丢失。
- 故障恢复：当主服务器出现故障时，可以迅速切换到从服务器提供服务，实现快速的故障恢复。
- 读写分离：主服务器处理写操作，从服务器处理读操作，可以提高系统的读性能，尤其适用于读操作远多于写操作的场景。
- 高可用基石：主从复制是实现Redis高可用性解决方案（如哨兵模式和集群模式）的基础.
主机配置
vim /etc/redis/6379.conf
从机：
测试
在主机中写入内容并查看
从机上查看
哨兵模式
Redis哨兵模式的原理
Redis哨兵模式（Sentinel）是Redis的高可用性解决方案，它通过一组哨兵进程来监控Redis主从服务器的健康状态。哨兵模式的主要作用是实现对主节点的监控、自动故障转移和通知。哨兵模式不是一个单独的进程，而是由多个哨兵服务组成的分布式系统。
哨兵的工作流程
-
监控：哨兵会周期性地向所有Redis节点发送PING命令，以检查它们是否正常响应。如果哨兵在预定时间内没有收到节点的响应，它会将该节点标记为主观下线（sdown）。
-
客观下线判断：哨兵之间会通过发布/订阅（pub/sub）模式相互发现，并使用投票协议来达成共识，判断主节点是否真的宕机（客观下线，odown）。这需要超过法定人数（quorum）的哨兵同意主节点不可用。
-
选举领导者：在主节点客观下线后，哨兵会选举一个领导者（leader）来执行故障转移。选举过程中，哨兵会投票给得票最多的哨兵，直到有哨兵获得超过半数的投票并满足法定人数的要求。
-
故障转移：领导者选举产生后，它会选择一个合适的从节点作为新的主节点，并指挥其他从节点和哨兵更新配置，将新主节点的信息传播给客户端。
-
通知：哨兵可以通过API向客户端发送通知，告知主节点发生了更换。
-
客户端重定向：客户端在接收到哨兵的通知后，会连接到新的主节点继续操作。
哨兵模式的作用
- 监控：哨兵持续监控Redis主从节点的健康状态。
- 自动故障转移：当主节点发生故障时，哨兵能够自动将一个从节点提升为主节点，确保服务的连续性。
- 通知：哨兵能够通知客户端主节点的变化，帮助客户端及时切换到新的主节点。
- 配置提供：哨兵作为配置中心，可以提供当前主节点和从节点的信息给客户端。
开启哨兵
#编辑配置文件
[root@redis-node1 ~]# cd redis-7.4.0/
[root@redis-node1 redis-7.4.0]# cp sentinel.conf /etc/redis/
[root@redis-node1 redis-7.4.0]# 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分钟
\####复制配置文件到其他阶段
[root@redis-node1 redis-7.4.0]# scp /etc/redis/sentinel.conf
root@172.25.254.201:/etc/redis/
root@172.25.254.201's password:
sentinel.conf
100% 14KB 9.7MB/s 00:00
[root@redis-node1 redis-7.4.0]# scp /etc/redis/sentinel.conf
root@172.25.254.200:/etc/redis/
root@172.25.254.200's password:
sentinel.conf
可以查看主机和从机情况
可以看出20和30是从机，复制的10的内容
停掉10后
20和30中显示10已经宕机了
查看，主机由10变为了30
重启10
显示-sdown
30中从机变为两个
Redis Cluster（无中心化设计）
Redis Cluster采用了无中心化的设计，这意味着集群中没有专门的中心节点来协调其他节点的操作。集群中的每个节点都是平等的，它们之间通过Gossip协议进行通信，以实现节点发现、故障检测和状态信息的交换。集群中的节点负责管理一部分数据，这些数据通过哈希槽（Hash Slot）的方式进行划分，确保数据的分布和冗余。
Redis Cluster的作用和优势
Redis Cluster的主要作用是提供高可用性和水平扩展能力。通过数据分片和主从复制，Redis Cluster能够在节点故障时自动进行故障转移，确保服务的连续性。集群中的每个主节点都可以有一个或多个从节点，从节点在主节点故障时可以被提升为新的主节点。此外，Redis Cluster支持在线扩容，可以通过增加新节点来扩展存储容量和处理能力，而不需要停机
Redis Cluster的优势包括：
- 高可用性：通过主从复制和自动故障转移机制，即使部分节点发生故障，集群也能继续提供服务。
- 水平扩展：集群可以通过增加节点来扩展，提高读写性能和存储能力。
- 数据分片：集群内部将所有的key映射到16384个槽中，每个节点负责一部分槽的读写，实现数据的分布式存储。
- 透明性：客户端可以直接连接集群中的任何节点，集群会自动将请求路由到正确的节点，对外提供统一的接口。
- 无需中间件：客户端与Redis节点的交互不需要通过代理或中间件，简化了架构。
[root@redis-master1 ~]# redis-cli --cluster create -a 123456 \
\> 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
添加集群
查看集群状态
检测集群
[root@redis-master1 ~]# redis-cli -a 123456 --cluster check 172.25.254.10:6379
每个master对应一个slave
无法在maste1上写入数据，被分配到20的hash槽位上，只能在master2上写入数据
扩容集群
添加要扩容的IP
分配槽位
分配的node id 要与上面想要获得槽位的id一致
开始添加槽位
添加salve，master id要与40一致，因为40是新添加的master，slave添加的id是40的id
再次查看集群，四主四从，添加集群成功
clsuter集群维护
移除要下线主机的哈希槽位
redis-cli -a 123456 --cluster reshard 172.25.254.20:6379
正在移除
删除master
删除的主从id得一致
