1、消息订阅与发布
subscribe my1 订阅频道
psubscribe my1* 批量订阅频道，订阅以my1开头的所有频道
publish my1 hello 在指定频道中发布消息，返回值为接受到信息的用户数
类似于桌面右下角的小广告
->所以这里的频道没有创建这一说
2、多数据库
redis默认有16个数据库，0, 1, 2....15
默认所有的数据操作，都是在0号数据库上操作的
切换数据库：select 数据库名
把某个键值对进行数据库移植：move key 数据库名，在当前数据库该键值对就不存在了
清空当前数据库：flushdb
清空服务器-所有数据库：flushall
3、事务
mysql事务：目的是为了保证数据完整性，安全
redis事务：目的是为了进行redis语句的批量化执行
multi 开启事务
exec 提交事务
discard 事务回滚
->当事务中某几个语句出错，程序不会自动进行事务回滚，其他语句正常执行
4、基础命令
ping 如果返回PONG，代表连接成功，否则会返回no connected
quit 退出客户端，和ctrl+c一致
dbsize 返回当前数据库中的key数量
info 可以看到服务器和连接客户端的详细详细
5、持久化
持久化：把数据保存在硬盘上
关系型数据库 mysql，任何增删改语句，都是在硬盘上做的操作
内存（兔子）：高效，断电数据就会消失
硬盘（乌龟）：读写速度慢于内存，断电数据依旧存在
非关系型数据库redis：
默认情况下，所有的增删改，数据都是在内存中进行操作
断电以后，redis的部分数据会丢失，丢失的数据就是保存在内存中的数据
6、redis的两种持久化策略，RDB
这是默认的策略，照快照，保存的是一种状态
20G数据 ---> 几kb快照
优点：
1）快照保存数据速度极快，还原也快
2）适用与灾难备份，例如redis服务器所在机房失火，我要赶紧儿将redis数据备份
缺点：
1）小内存机器不适合使用
RDB机制符合要求就会照快照。（随时随地启动），会占用一部分系统资源，
例如我有1G的数据，他会先将1G的数据先复制过来（此时内存就被占用2G了），进行压缩、备份、运算-->转化成dump.rdb文件
这个动作是突然的
Linux 4G
3G数据，这时进行rdb机制，很有可能因为内存不足直接宕机（宕机后，服务器会关闭，属于非正常关闭）
使用场景：内存比较充裕的计算机
->在安装目录下默认有dump.rdb
RDB何时进行照快照：
服务器正常关闭时，照快照；redis-cli shutdown
key满足一定条件时，照快照；
save 900 1
save 300 10
save 60 10000
每15分钟至少有1个key发生变化，则照快照保存
7、redis的两种持久化策略，AOF
这是使用日志功能保存数据操作
1）同步规则：
每秒同步：安全性低，比较节省系统资源->怎么个理解法
每修改同步：只要有key变化语句，就进行AOF保存数据，比较安全，但是极为浪费效率
不同步（默认）：不安全
2）AOF操作：只会保存导致key发生变化的语句
3）AOF配置：
3.1）将appendonly no 改成 appendonly yes，这一步时开启AOF机制；
3.2）策略的选择：将appendfsync always的注释去掉，每次key变化就进行保存
优点：
持续性占用极少量的内存空间，只有--KB，会专门开辟一个AOF日志程序；性价比很高哟
缺点：
1）日志文件会特别大，不适用于灾难备份；最终数据不多，但是过程语句复杂；
例子：1G数据，由10G的语句生成
2）恢复效率远远低于RDB
适用场景：内存比较小的计算机，所以大公司会选择用默认RDB的方式