Redis学习总结

NoSQL数据库分类

KV键值对：Redis
文档型数据库：MongoDB
列存储数据库：HBase
全文搜索引擎：Elasticsearch

Redis

概述

Redis：Remote dictionary server（远程字典服务器）
Redis对比Memcache：
- Redis特点：
  1. 支持数据持久化
  2. 支持的数据类型丰富，kv、list、se、zset、hash
  3. 支持数据备份，即master-slave模式的数据备份
  4. 单进程
- Memcache特点：
  1. 高性能，可达几十万QPS
- 区别：Memcache性能更好，Redis一专多能
Redis默认端口为：6379
新浪微博的数据特别适合用Redis来存储

redis的数据结构

key:value形式
其中key为String类型，value有5种数据结构：

字符串类型 string
哈希类型　hash　：　map格式
列表形式　list　：　linkedlist格式
集合类型　set　（不能有重复元素）
有序集合类型 sortedset (有序且不能有重复元素)

命令操作

字符串类型 string
1. 存储：set key value
2. 获取：get key
3. 获取子串：getrange key start end
4. 删除：del key
5. 自增（只适用于数字）：incr[by] key [number]
6. 自减（只适用于数字）：decr[by key [number]
7. 批量set：mset k1 v1 k2 v2 k3 v3
8. 批量get：mget k1 k2 k3
9. 不存在才set：setnx key value
哈希类型 hash
1. 存储：hset key field value
2. 批量存储：hmset key f1 v1 f2 v2
3. 获取：
  - hget key field: 获取指定的field对应的值
  - hgetall key: 获取所有的field和value
4. 批量获取：hmget key f1 f2
5. 获取所有field：hkeys key
6. 获取所有value：hvals key
7. 获取所有field和value：hgetall key
8. 删除：hdel key field
9. value自增：hincrby[float] key field 自增量
10. 仅不存在时存储：hsetnx key field value
列表类型 list
1. list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。
2. 添加：
  - lpush key value: 将元素加入列表左边
  - rpush key value: 将元素加入列表右边
3. 获取：lrange key start end
4. 查询某个位置的值：lindex key index
5. 获取list长度：llen
6. 删除：
  - lpop key: 删除列表最左边的元素，并将元素返回
  - rpop key: 删除列表最右边的元素，并将元素返回
集合类型 set ：不允许重复元素
1. 存储：sadd key value
2. 获取：smembers key 获取set集合中所有元素
3. 删除：srem key value 删除set集合中的某个元素
4. 获取元素个数：scard set01
有序集合类型 sortedset : 不允许重复元素
1. 存储：zadd key score value
2. 获取：zrange key start end
3. 删除：zrem key value

通用命令

Redis默认有16个数据库，切换数据库: select 数据库id
查看当前数据库有多少键值对：dbsize
keys * : 查询所有的键
type key : 获取键对应的value的类型
del key : 删除指定的 key value
清空缓存：flushdb（当前数据库）flushall（所有数据库）
查找指定的key： keys n???（查找n开头的四字key）
判断某个key是否存在：exists key
给指定的key设置过期时间：expire key 秒数
查看key还有多少秒过期：ttl key （-1不是永不过期，-2表示已过期）

Redis过期删除、数据淘汰

过期数据删除
- 定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！
- 惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，也是够懒的哈！
数据淘汰策略：如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了。怎么解决这个问题呢？ redis 内存淘汰机制。
1. volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！
0版本后增加以下两种：
1. volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
2. allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

Redis配置

修改 /usr/src/redis-2.8.17/redis.conf文件

Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
daemonize no
当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
pidfile /var/run/redis.pid
指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
port 6379
绑定的主机地址
bind 127.0.0.1
当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
timeout 300
指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
loglevel verbose
日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
logfile stdout
设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
databases 16</dbid>
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
save <seconds> <changes>
Redis默认配置文件中提供了三个条件：
save 900 1
save 300 10
save 60 10000
分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。</changes></seconds>
指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
rdbcompression yes
指定本地数据库文件名，默认值为dump.rdb
dbfilename dump.rdb
指定本地数据库存放目录
dir ./
设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
slaveof <masterip> </masterip>
当master服务设置了密码保护时，slav服务连接master的密码
masterauth
设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
requirepass foobared</password>
设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxclients 128
指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理
后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
maxmemory
指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no
指定更新日志文件名，默认为appendonly.aof
appendfilename appendonly.aof
指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘（快）
always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表示每秒同步一次（折衷，默认值）
appendfsync everysec
指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
vm-enabled no
虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
vm-swap-file /tmp/redis.swap
将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
vm-max-memory 0
Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不确定，就使用默认值
vm-page-size 32
设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
vm-pages 134217728
设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
vm-max-threads 4
设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
glueoutputbuf yes
指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
activerehashing yes
指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
include /path/to/local.conf

持久化

持久化机制
1. RDB（Redis DataBase）：默认方式，不需要进行配置。在一定时间间隔内，检测key的变化，然后持久化数据
  1. 编辑redis.windows.conf文件
    save 60 10000（代表60秒内有10000次key改变则持久化）
  2. 用命令行方式重启Redis服务器，并指定配置文件
    redis-server.exe redis.windows.conf
    1. 优缺点：
2. AOF（Append Only File）：日志记录的方式记录每个写操作
  1. 编辑redis.windows.conf文件
    appendonly no --> appendonly yes
    appendfsync always : 每次操作都进行持久化
    appendfsync everysec: 每隔一秒进行一次持久化
    appendfsync no　　: 不进行持久化
    1. aof文件损坏，修复文件：redis-check-aof --fix appendonly.aof
    2. aof文件越来越大，采用Rewrite机制：bgrewriteaof
    3. 优缺点：
    4. RDB和AOF可以同时使用

事务

常用命令：
1. 开启事务：multi
2. 提交事务：exec
3. 撤销事务：discard
执行流程
1. 开启事务
2. 命令入队
3. 执行事务
Redis事务的5种执行情况
1. 正常执行
2. 放弃事务（discard）
3. 全体连坐：一个命令出错（比如命令写错了），全部命令执行失败
4. 冤头债主：命令运行时异常（比如非数字自增），只有异常的命令执行失败，其他成功
5. watch监控：监控一个（多个）key，如果在事务执行前这些key被其他命令所改动，则事务被打断
  - 悲观锁/乐观锁/CAS（Check And Set）
    
    悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
    乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，乐观锁策略:提交版本必须大于记录当前版本才能执行更新
  - unwatch：取消watch对所有key的监控
  - Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
  - 通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败
Redis事务特性
1. 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
3. 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚