标签：car type 元素 ati 情况下 指定端口 and 临时 which
一、redis 五大类型：
redis 键
keys *
exists key的名字，判断某个key 是否存在
move key db 当前数据库就没有了，被移除了
ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期
type key 看看你的key是什么类型
redis 字符串
set、get 、del、append、strlen
incr、decr 、incrby、 decrby
getrange、setrange
setex（set with expire）键秒值、setnx（set if not exist）
mset、 mget 、msetnx
redis list
lpush、rpush、 lrange
lpop、rpop
lindex 按照索引下标获得元素 llen
lrem key 删n个value
ltrim key 开始index 结束index 截取指定范围的值后在赋值给key
rpoplpush 源列表 目的列表
lset key index value
linsert key before/after 值1 值2
redis set
sadd、smembers、 sismember
scard 获取集合里面的元素个数
srem key value 删除集合中元素
srandmember key 某个整数（随机出几个数）
spop key 随机出栈
smove key1 key2 在key1里某个值 作用：将key1里面的某个值 赋值给key2
数字集合类：差集 sdiff ；交集 sinter ； 并集 sunion
redis zset
在set的基础上，加一个score值 之前set是k1 v1 v2 现在zset是k1 score1 v1 score2 v2
zadd、zrange（withscores）
zrangebyscore key 开始score 结束score
zrem key 某score下对应的value值 作用：删除元素
zcard、zcount key score区间、zrank key values值 作用：获得下标值、
zscore key 对应值，获得分
zrevrank key values值，作用是逆序获得下标值
zrevrange
zrevrangebyscore key 结束score 开始score
redis hash
hset、hget 、hmset、hmget 、hgetall、hdel
hlen
hexists key 在key里面的某个值的key
hkeys、hvals
hincrby 、hincrbyfloat
hsetnx
二、redis 持久化
rdb redis database
aof append only file
共存时，先加载aof，后加载rdb
rdb讲解：
rdb ： 在指定的时间间隔内将内存中的数据集写入磁盘,也就是snapshot快照，（rdbsave）
快照恢复是将快照文件直接读到内存里（rdbload）
save 秒钟 写操作次数
触发条件：1分钟内改了1万次；
5分钟内改了10次
15分钟内改了1次
单个save或者bgsave命令 直接备份
save时 只管保存，其他不管，全部阻塞
bgsave:redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，可以通过
lastsave命令获取最后一次成功执行快照的时间
如何恢复： 将备份文件移动到redis安装目录并启动服务（config get dir 获取目录）
优势：适合大规模的数据恢复，对数据的完整性和一致性要求不高
劣势：在一定间隔时间做一次备份，所以redis意外down掉的话，就会丢失最后一次快照后的 所有修改；
fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
如何停止： 动态所有停止rdb保存规则的方法：redis-cli config set save " "
aof讲解：
aof：解决rdb最后一次数据丢失问题
以日志的形式来记录每个写操作，将redis执行过得所有写指令记录下来（读操作不记录）
只允许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之， redis重启的话就根据日志文件的内容将指令从前到后执行一次以完成数据的恢复工作
aof 保存的是appendonly.aof文件
配置：appendonly 、appendfilename、
appendfsync包括三个策略：Always：同步持久化，每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
everysec：出厂默认推荐，异步操作，每秒记录。如果一秒内 宕机，有数据丢失
No
No-appendfsync-on-rewrite：重写时是否可以运用appendfsync，用默认no即可，保证数 据的安全性
Auto-aof-rewrite-min-size：设置重写的基准值
Auto-aof-rewrite-percentage：设置重写的百分比
aof启动、修复、恢复
正常恢复： 启动：设置yes，将有数据的aof文件复制一份保存到对应安装目录
恢复：重启redis然后重新加载
异常恢复：启动：设置yes，备份被写坏的aof文件
修复：redis-check-aof --fix进行修复
恢复：重启redis然后重新加载
rewrite：
aof采用文件追加方式，文件会越来越大为避免出现此种情况，增加了重写机制，当aof文件的大小超过所设定的阙值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
重写原理：
aof文件持续增长而过大时，会fork处一条新进程来将文件重写（也是先写临时文 件最后再rename），遍历新进程的内存中数据，每条记录有一条set语句。重写 aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令 的方式重写一个新的aof文件，和快照有点类似
触发机制：redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大 小的一倍且文件大小是64MB
优势：灵活的配置
劣势：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
which one
rdb持久化方式能够在指定的时间间隔能对你的数据进行快照存储
aof持久化方式记录每次对服务器的写的操作，当服务器重启的时候会执行这些命令来恢复原 始的数据，aof命令以redis协议追加保存每次写的操作到文件末尾，redis还能对aof文件进行 后台重写，使得aof文件的体积不至于过大。
只做缓存：两种都可以不使用
同时开启两种持久化方式：
这种情况下，redis重启的时候会优先载入aof文件来恢复原始数据，因为在通常情况下aof文件保存的数据集要比rdb文件保存的数据集 要完整。
rdb的数据不实时，同时使用两者时服务器重启也只会找aof文件,那 要不要只使用aof文件？建议不要，因为rdb更适合于备份数据库（ aof在不断变化不好备份）两手准备
三、集群
redis 主从复制，读写分离 info replication 查看角色
1配（库）从不配主（库）
2从库配置：slaveof 主库ip 主库端口号（每次与master断开之后，都需要重新连接，除非你 配置进redis.conf文件）
3修改配置文件细节操作：拷贝多个redis.conf文件
开启daemonize yes
pid文件名字
指定端口
log文件名字
dump.rdb名字
4 常用三招:4.1 一主二仆
4.2薪火相传（去中心化，解决主机负担）：
上一个slave可以是下一个slave的 master，slave同样可以接受其他salves的连接和同步请求，那 么该slave作为了链条中下一个的master，可以有效减轻master的 的写压力
中途变更转向：会清除之前的数据，重新建立拷贝最新的 。slaveof 新主库ip 新主库端口号
4.3反客为主：slaveof no one 使当前数据库停止与其他数据库的同步，转成主库
复制原理：
slave启动成功连接到master后会发送一个sync命令，master接到命令启动后台的存盘进程，同时收集所有接受到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步。
全量赋值 增量复制 但只要重连master们就会产生一次完全同步，即全量赋值
哨兵模式：反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
怎么搭建：
配置文件目录下建立sentinel.conf文件，名字决不能错；
配置哨兵，填写内容；
如：sentinel monitor 被监控的数据库名字（自定义）127.0.0.1 1
上面最后一个数字1，标示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机
启动哨兵：redis-sentinel sentinel.conf
windows下启动哨兵服务redis-server.exe sentinel.conf --sentinel
原有的master挂了 投票新选
重新主从继续开工，info replication 查看
如果之前挂了的master重启回来 会变成新master的salve
一组sentinel能同时监控多个master
复制缺点：复制延时
标签：car type 元素 ati 情况下 指定端口 and 临时 which
原文地址：https://www.cnblogs.com/GtShare/p/9547306.html
