【尚硅谷】Redis 6 入门到精通 超详细 教程
数据库事务必备特性（ACID）
原子性(Atomicity)：指事务的不可分割性，一个事务的所有操作要么不间断地全部被执行，要么全都不执行。
一致性(Consistency)：事务前后数据的完整性必须保持一致。
隔离性(Isolation)：事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性(Durability)：持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。
注意：
redis支持一致性和隔离性，但无法保证持久性，支持部分的原子性（如果事务中使用的命令和操作的数据类型不匹配的时候不保证原子性）
redis是单线程加IO多路复用模式，IO多路复用大大的提高了CPU的利用率，极大提升了并发性能。
redis安装在linux中
首先选择opt文件解压redis，编译后再安装redis，会默认安装在usr/local/bin目录中。有如下默认安装目录：
启动redis，先执行(后台启动，加了后续/etc/redis.conf，前台启动就不需要加)
redis-server /etc/redis.conf
命令启动redis，再执行
redis-cli
命令进入客户端。输入
ping
命令用来测试是否联通redis
在默认安装的bin目录中启动redis，推荐使用后台启动，好处就是即使把终端窗口关闭还是可以继续使用。注意：使用后台启动要先将redis.conf文件复制一份到其他目录(我复制在etc目录下)。
关闭redis用
shutdown
命令可以，也可以用
kill -9 端口号
关闭。
事务：redis事务是一个单独的隔离操作，无隔离级别，事务中的命令都会序列化、按顺序执行，其主要作用是串联多个命令防止别的命令插队。
- mutil开启事务，exec执行，执行之后表示事务结束。也可以不执行，discard直接结束.
queue：排队(v)、队列(n)
- 事务出错
1，组队时出错，最终都不会执行
2，组队时成功，执行时谁有错误谁就不执行，没错误的才能执行。
Redis持久化：
Redis持久化，由于redis是内存数据库，如果不将内存中的数据保存至硬盘的话，那么服务器一旦退出，服务器中的数据就会消失。所以Redis有RDB和AOF两个持久化的方式
RDB(Redis DataBase)，是redis的默认存储方式，是通过快照(snapshot)完成的。
触发快照的方式
1. 符合自定义配置的快照规则；
2. 执行save或者bgsave命令；
3. 执行flushall命令；
4. 执行主从复制操作 (第一次)。
执行机制：redis父进程首先判断是否在执行保存操作，如果在执行则父进程只是fork操作创建子进程，然后子进程创建RDB文件，生成临时快照文件，然后对原有RDB文件进行原子性替换(持久化操作)，完成后替换原来的快照文件，然后发送给父进程，子进程退出。整个过程主进程不进行任何io操作，确保了极高的性能
优点：1，适合大规模的数据恢复，rdb文件是唯一的且是数据的快照，不用重新读取再西俄如内存
2，主进程fork子进程，可以最大化Redis性能
3，体积小，因为rdb为二进制压缩文件
缺点：1，不能保证数据完整性
2，需要一定时间间隔操作，如果redis发生宕机，则最后一次修改的数据就没有了
3，如果数据集较大，父进程fork子进程时可能会造成阻塞
AOF(Append Only File)，与快照持久化相比，AOF持久化的实时性更好，因此已成为主流的持久化方案。其是把用户执行的每个“写”指令(添加/修改/删除)都备份到文件中，还原数据的时候就是执行具体写指令而已。开启AOF持久化会会清空redis内部的数据，故最好在redis使用之前就开启它。默认情况下Redis没有开启AOF方式的持久化，可以通过appendonly参数开启。开启后重启redis就会有一个appendonly.aof文件。
执行机制：开启AOF后，父进程fork一个子进程，然后子进程会将所有执行过的命令写入aof文件中（读操作不记录，只记录写的记录，因为只有写的操作才会对数据库产生影响），如果该文件有错误，redis就启动不了，可通过redis-check-aof工具(redis-check-aof --fix)去修复。当子进程完成AOF重写后会像父进程发送完成信号，然后覆盖旧的AOF文件。
优点：1，每一次修改都同步，文件的完整性会更好
2，如果不开启同步时间，效率最高。（默认每秒同步一次）
缺点：1，aof文件远远大于rdb文件，故修复速度慢
2，aof运行效率比rdb慢，所以redis默认的配置是rdb持久化
Redis主从复制：从机连主机
1，在计算机中创建一个myredis文件夹
2，复制redis.conf文件到myredis
3，分别命名redis6380.conf等等多个从机
4，开启三个redis的服务
5，分别在不同的xshell窗口连接redis窗口
6，通过slaveof连接(slaveof +master服务器ip（我们一台服务器，即是本机ip：127.0.0.1）+master服务器端口)
7，可通过info replication命令来查看是否连接从机和当前端口的信息。
薪火相传：从机连从机，即是说假如我们现在有20个从机，那么我们可以让主机跟其中三个直接对接，再让这三个每个跟另外3个对接，以此类推。好处就是减轻了主机的负担，坏处就是前面的服务器宕机了后面的就无法跟主机同步数据
反客为主：主从复制中，即使主机发生宕机，从机也不会做任何操作，一旦主机上线，从机依然跟着主机。反客为主就是当主机宕机后，从机晋升为主机。通过在从机中执行命令slave no one即可。
哨兵模式：反客为主的自动版，能够后台监控主机是否故障，然后根据选举（筛选➕排序）将从机转为主机。即使主机重新连线，也是作为新主机的从机。
筛选机制：筛选所有处于下线的从机，筛选所有没有在规定时间响应哨兵的info命令的从机，筛选所有数据比较旧(通过设置down-after-milliseconds的值筛选)的从机。
哨兵模型选择选择新主机的机制(排序机制)为：
1、优先级靠前的（redis.conf中replica-priority 的值越小，优先级越高）
2、同样位置，则偏移量最大的（获得原主机数据最全的）
3、既同样位置又同样的偏移量，则runid最小的（每个redis实例启动后都会随机生成一个40位的runid）
实现哨兵模式：在我们的 myredis 目录下新建一个文件 sentinel.conf，必须为这个名字，不能自定义。文件中填写：
sentinel monitor mymaster 127.0.0.1 6379 1
(哨兵监控我的主机 主机服务器ip 同意数量)
其中：mymaster是为监控对象起的服务器的名称，1是指至少有多少个哨兵同意就可以迁移（从机代替主机）的数量。
通过 redis-sentinel sentinel.conf命令启动哨兵，哨兵的默认端口是26379
缺点：
1，复制延迟，由于所有的写操作都是在主机写然后同步更新到从机上，所以从主机到从机会有一定的延迟，和网络和从机数量也有关系。
2，sentinel选举新主机时是没办法访问redis的，存在访问瞬断的情况，可能损失数据。
3，主机压力大，因为只有主机可以进行写操作。
redis6加入了多线程，但不是普遍意义上的多线程，redis的多线程部分只是用来处理网络数据的读写和协议，执行命令任然是单线程的。
