Redis初探笔记

Redis

大数据时代的3V

• 海量Volume
• 多样Variety
• 实时Velocity

互联网需求的3高

• 高并发
• 高可扩
• 高性能

Redis的五大数据类型

--set

set/get/append/strlen

incr/decr/incrby/decrby

getset/setex/setnx

setrange/getrange 设置/获取指定索引位置的字符

setbit/getbit 设置/获取指定位的BIT值，应用场景：考勤打卡

mset/mget/msetnx

--list

• lpush/rpush

  • 从左边、右边插入一个或者多个值

• lpol/rpop

  • 从左边/右边吐出一个值
  • 值在键在,值亡键亡

• rpoplpush

  • 从key1的右边吐出一个插到key2的左边

• lrange

  • 按照索引下标获得元素（从左到右）

• lindex

  • 按照索引下标获得元素（从左到右）

• llen

  • 获得列表的长度

• linsert before|after

  • 在 中的value前或后添加一个新的value

• lrem

  • 从左边删除n个value（从左到右）n可以为正数 负数 0 0为删除所有值为value的值

l

--set

• sadd ....

  • 将一个或者多个memnbet元素啊计入到集合key，已经存在的member元素将会被忽略

• smembers

  • 获取集合的所有值

• sismember

  • 判断集合key是否含有为value的值 有则返回1 没有则返回0

• scard

  • 返回集合的所有元素个数

• srem ...

  • 删除集合中的某个元素

• spop

  • 随即从集合中吐出一个值,会把集合中的该元素删除

• srandmember

  • 随机从该集合中取出n个值
  • 不会从集合中删除这些元素

• sinter

  • 返回两个集合的交集元素

• sunion

  • 返回两个集合的并集元素

• sdiff

  • 返回两个集合的差集元素

--hash

• hset
  • 给集合的field键赋值value
• hmset
  • 批量设置hash值
• hget
  • 获取集合key中键为field的值
• hexists
  • key集合中是否存在field
• hkeys
  • 列出该hash集合的所有field
• hvals
  • 列出该集合的所有value
• hgetall
  • 列出集合的所有键值对 上键下值
• hincrby
  • 为哈希表key中的域field的值加上增量increment(increment可以为负数)
• hsetnx
  • 有field就不赋值 没有就赋值

--zset

有序集合，每一个成员都关联了一个评分score，这个评分被用来按照从最低分到最高分方式排序集合中的成员。

既没有重复元素，还能自动排序

• zadd ..
  • 将一个或者多个member元素及其score值
• zrange [withscores]
  • 返回有序集
  • 带有withscores可以让分数一起和值返回
• zrangebyscore min max [withscores] [limit offset count]
  • 返回key中所有score的值介于[min,max]的的成员,返回值按照score从小到大排列
• zrevrangebyscore key max min [withscore] [limit offset count]
  • 同上改为从大到小排列
• zincrby
  • 为元素的score加上容量
• zrem
  • 删除该集合下,指定值的元素
• zcount
  • 统计该集合,分数区间的元素个数
• zrank
  • 返回该值在集合中的排名 从0开始(获取索引)

Redis的相关配置

tcp-backlog

可以理解是一个请求到达后直到接受进程处理前的队列

backlog队列总和=未完成三次握手队列 + 已完成三次握手队列

高并发环境tcp-backlog 设置值跟超时时限内Redis吞吐量决定

timeout: 一个空闲的客户端维持多少秒会关闭,0为永不关闭

TCP keeoalive:对访问客户端的一种心跳检测,每隔n秒检测一次 官方推荐设置为60秒

daemonize:是否为后台进程

pidfile 存放pid文件的位置,每个实例会产生一个不同的pid文件

loglevel 四个级别根据使用阶段来选择,生产环境选择notice或者warning

logfile:日志文件名称

syslog:是否将Redis日志输送到linux系统日志服务中

syslog-ident:日志的标志

syslog-facility:输出日志的设备

database:设定库的数量 默认16

security:在命令行中设置密码

设置样本数量,LRU算法和最小TTL算法都并非是精确的算法,而是估算值,所以你可以设置样本的大小.

一般设置3到7的数字,数值越小样本越不准确,但是性能消耗也最小

Redis的事务定义

• Redis事务时一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来
  的命令请求所打断
• Redis事务的主要作用就是串联多个命令防止别的命令插队
• Multi：开启事务 Exec：执行事务 Discard： 取消事务
• 从输入Multi开始 ，输入的命令都会依次进入命令执行队列中但不会执行，直到输入Exec以后，Redis会将之前的命令队列中的命令依次执行。
• 组队的过程中可以通过discard放弃组队
• 组队中的某个命令出现了报告错误（拼写错误）编译时异常，执行时整个的所有队列都会被取消
• 执行时异常，只有报错的命令不会被执行，其他的命令都会执行不会回滚

watch key

• 在执行multi之前，先执行warch key （key2 ...）之后，如果在exec之前，这个（或者这些个）key的值发生了变化，那么待执行的事务将被打断

三特性

1. 单独的隔离操作
   • 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求打断
2. 没有隔离级别的概念
   • 队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存“事务内的查询要看到实事务里的更新，在事务外查询不能看到” 这个让人十分头疼的问题
3. 不保证原子性
   • Redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis持久化

Redis提供了两个不同形式的持久化方式：RDB（Redis DataBase）AOF（Append Of File）

1、RDB

• 在指定的时间间隔内将内存中的数据写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
• 执行过程

RDB方式存的是数据

• RDB的保存文件： 在redis.conf中配置文件名称 默认为dump.rdb
  • 保存的路径： dir （你要保存的位置）
  • 保存的策略save
  • save 在多少秒内做出了多少次改变就会引起保存
  • 手动保存快照的命令 save bgsave (一般不用)
• shutdown正常关闭也会触发保存
• stop-writes-on-bgsave-error yes
  • 当Redis无法写入磁盘的话,直接关掉Redis的写操作
• rdbcompression yes
  • 进行rdb保存时, 将文件压缩
• rdbchecksum yes
  • 在存储快照以后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能功耗,如果
• rdb的恢复
  • 关闭redis
  • 先把备份的文件拷贝到工作目录下
  • 启动Redis，备份数据会直接加载
• rdb的优点
  • 节省磁盘空间
  • 回复速度快
• rdb的缺点
  • 虽然redis在fork时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能
  • 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后所有修改

2、AOF

• AOF默认不开启，需要手动在文件中配置

• 可以在redis.conf中配置文件名称,默认为appendonly.aof

• AOF文件的保存路径,同RDB的路径一致

• AOF只记录写操作,不记录读操作

• 如果RDB和AOF同时开启 Redis取AOF的数据

• AOF同步频率设置:

  • 始终同步 每次写都同步
  • 每秒同步 每秒记录一次如果宕机 本秒的数据可能丢失
  • 不主动进行同步,把同步时机交给操作系统

• AOF采用文件追加方式,文件会越来越大,为了避免出现这种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的的最小指令集.可以使用命令bgrewriteaof

• 当AOF文件持续增长过大时,会fork出一条新进程来将文件重写(先写临时文件最后在rename),遍历新进程的内存中的数据,每条记录有一条set语句.重写AOF文件的操作,并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件,这点和快照有点类似

• 何时重写:

  • 系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size,如果Redis的AOF当前大小>=base_size+base_size*100%(默认)且当前大小>=64mb的情况下,Redis才会对AOF进行重写

• AOF的优点

  • 备份机制更稳健,丢失数据的概率更低
  • 刻度的日志文本,通过操作AOF文件,可以处理误操作

• AOF的缺点

  • 比起RDB占用更多的磁盘空间
  • 恢复备份速度更慢
  • 每次读写都同步的话,有一定的性能压力
  • 存在个别bug,造成恢复不能

Redis主从复制

是什么

• 主从复制就是主机数据更新后根据配置和策略,自动同步到备机的master/slave机制,Master以写为主,Slave以读为主

用处

• 读写分离 性能扩展
• 容灾快速恢复

配置方法 : 配从不配主

1. 拷贝多个redis.conf文件include
2. 开启daemonize yes
3. pid文件名字pidfile
4. 指定端口port
5. log文件名字
6. Dump.rdb名字dbfilename
7. Appendonly关掉或者换名字
8. • info replication
     • 打印主从复制的相关信息
   • slaveof
     • 成为某个实例的从服务器
9. 复制原理：
   1. 每次从机联通以后，都会给主机发送sync指令
   2. 主机立即进行存盘操作，发送RDB文件，给从机
   3. 从机收到RDB文件以后，进行全盘加载
   4. 之后每次主机的写操作，都会立刻发送给从机，从机执行相同的命令
   5. 主服务器宕机 从机原地待命

薪火相传

• 上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力，去中心化降低风险
• 用slaveof
• 中途变更转向:会清除之前的数据,重新简历拷贝最新的
• 风险是一旦某个slave宕机,后面的slave都无法备份
• 反客为主: 用slaveof no one 把从机变为主机

哨兵模式

• 反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将库转化为主库
• 新主登基
  • 从下线的主服务器所有的从服务器里面挑选一个从服务,将其转成主服务
    • 1. 选择优先级靠前的 ->优先级在redis.com中slave-priority 100
      2. 选择偏移量最大的 ->偏移量是指获得原主数据最多的
      3. 选择runid最小的 -> 每个redis实例启动后都会随机生成一个40位的runid
• 群仆俯首
  • 挑选出新的主服务以后,sentinel向主服务的从服务slaveof新主服务的命令
• 旧主俯首

Redis集群

• Redis集群实现了对Redis的水平扩容,即启动N个redis节点,讲整个数据库分布存储在N个节点中,每个节点存储总数居的1/N
• Redis集群通过分区(partition)来提供一定程度的可用性(avaliavility):即使集群中有一部分节点失效或无法进行通讯,集群也可以继续处理命令请求
• 一个集群至少要有三个主节点
• 不在一个slot下的键值,是不能使用mget,mset查询和设置
  • 可以通过 { } 来定义组的概念,从而 使key中{}相同的内容的键值对放在一个slot中
• 查询集群中的值
• 如果主节点下线从节点能否自动升级为主节点? 新主登基
• 主节点恢复之后,主从关系该如何? 旧主俯首
• 如果所有某一段插槽的主节点都down掉,Redis服务能否继续 ? 能