redis 实战：redis需要掌握的点

分布式

 

按照分布式领域的 CAP 理论 Consistency（一致性） 、 Availability（可用性） 、Tolerance to network Partitions(网络分区容忍度 ) 这三 部分在任何系统架构实现时只可能同时满足其中二点，没法三者兼顾）来衡量，传统的关系数据库的 事务管理( ACID) 只满足了 Consistency 、 Availability ，因此在 Partition tolerance（分区容忍 ） 上就很难做得好。 另外传统的关系数据库处理海量数据、分布式架构时候在 Performance（性能） 、Scalability（可伸缩性 ）、 Availability 等方面也存在很大的局限性。

 

而 Key-Value Store 更加注重对海量数据存取的性能、分布式、扩展性支持上，并不需要传统 关系数据库的一些特征，例如：Schema 、事务、完整 SQL 查询支持等等，因此在分布式环 境下的性能相对于传统的关系数据库有较大的提升。

 

 

RDBMS，一般几百个并发的查询就可以让它很吃 力了，而一个 Key-Value Store，可以很轻松的支持上千的并发查询。

 

• Key-value store：一个 key-value 数据存储系统，只支持一些基本操作，如：SET(key, value)和 GET(key) 等；
• 分布式：多台机器（nodes ）同时存储数据和状态，彼此交换消息来保持数据一致，可视为一个完整的存储系统。 
•  
   数据一致：所有机器上的数据都是同步更新的、不用担心得到不一致的结果；
•  
  冗余：所有机器（nodes ）保存相同的数据，整个系统的存储能力取决于单台机器（ node ）的能力；
•  
  容错：如果有少数 nodes 出错，比如重启、当机、断网、网络丢包等各种 fault/fail 都 不影响整个系统的运行；
•  
  高可靠性：容错、冗余等保证了数据库系统的可靠性。

新浪微博 Redis 的部署场景很多，大概分为如下的 2 种 :

第一种是应用程序直接访问 Redis 数据库

第二种是应用程序直接访问 Redis ，只有当 Redis 访问失败时才访问 MySQL

 

redis数据类型

作为 Key-value 型数据库， Redis 也提供了键（ Key ）和键值（ Value ）的映射关系。但是，除 了常规的数值或字符串，Redis 的键值还可以是以下形式之一：

•  Lists （列表）
•  Sets （集合）
•  Sorted sets （有序集合）
•  Hashes （哈希表）

键值的数据类型决定了该键值支持的操作。 Redis 支持诸如列表、集合或有序集合的交集、 并集、查集等高级原子操作；同时，如果键值的类型是普通数字，Redis 则提供自增等原子 操作

 

redis持久化

 

通常， Redis 将数据存储于内存中，或被配置为使用虚拟内存。通过两种方式可以实现数据 持久化：使用截图的方式，将内存中的数据不断写入磁盘；或使用类似 MySQL 的日志方式， 记录每次更新的日志。前者性能较高，但是可能会引起一定程度的数据丢失；后者相反。

 

redis 是一个支持持久化的内存数据库，也就是说 redis 需要经常将内存中的数据同步到磁盘 来保证持久化。redis 支持两种持久化方式，一种是 Snapshotting （快照）也是默认方式，另 一种是 Append-only file （缩写 aof ）的方式。下

 

snapshotting 方式

 

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中 , 默认的文件名为 dump.rdb 。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis 在 n 秒内如果超过 m 个 key 被修改就自动做快照，下面是默认的快照保存配置

 

save 900 1 #900 秒内如果超过 1 个 key 被修改，则发起快照保存
save 300 10 #300 秒内容如超过 10 个 key 被修改，则发起快照保存
save 60 10000

 

client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主线程 中保存快照的，由于 redis 是用一个主线程来处理所有 client 的请求，这种方式会阻塞所有 client 请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整 写入到磁盘一次，并不是增量的只同步变更数据。如果数据量大的话，而且写操作比较多，

必然会引起大量的磁盘 io 操作，可能会严重影响性能

 

aof 方式

 

aof 比快照方式有更好的持久化性，是由于在使用 aof 持久化方式时 ,redis 会将每一个收到 的写命令都通过 write 函数追加到文件中 ( 默认是 appendonly.aof) 。当 redis 重启时会通过重 新执行文件中保存的写命令来在内存中重建整个数据库的内容。

appendonly yes //启用 aof 持久化方式
# appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
# appendfsync no //完全依赖 os，性能最好,持久化没保证

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test 命令 100 次，文件中必须保存全部的 100 条命令，其实有 99 条都是多余的。因为要恢复数 据库的状态其实文件中保存一条 set test 100 就够了。为了压缩 aof 的持久化文件。 redis 提 供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照类似的方式将内存中的数据以命令 的方式保存到临时文件中，最后替换原来的文件。

 

配置 Redis

通过redis 下 redis.conf 文件配置，Redis 支持很多的参数，但都有默认值。

• daemonize: 默认情况下，redis 不是在后台运行的，如果需要在后台运行，把该项的值更改为 yes
•  pidfile 当 Redis 在后台运行的时候，Redis 默认会把 pid 文件放在/var/run/redis.pid，你可以配置到其他地址。当运行多个 redis 服务时，需要指定不同的 pid 文件和端口
•  bind 指定 Redis 只接收来自于该 IP 地址的请求，如果不进行设置，那么将处理所有请求，在 生产环境中最好设置该项
•  port 监听端口，默认为 6379
•  timeout 设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令， 那么关闭该连接
•  loglevel log 等级分为 4 级，debug, verbose, notice, 和 warning。生产环境下一般开启 notice
•  logfile 配置 log 文件地址，默认使用标准输出，即打印在命令行终端的窗口上
•  databases 设置数据库的个数，可以使用 SELECT <dbid>命令来切换数据库。默认使用的数据库是 0
•  save 设置 Redis 进行数据库镜像的频率。
• if(在 60 秒之内有 10000 个 keys 发生变化时){
• 进行镜像备份
• }else if(在 300 秒之内有 10 个 keys 发生了变化){
• 进行镜像备份
• }else if(在 900 秒之内有 1 个 keys 发生了变化){
• 进行镜像备份
• }
•  rdbcompression 在进行镜像备份时，是否进行压缩
•  dbfilename 镜像备份文件的文件名
•  dir 数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为 Redis 在进 行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该该 临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放 在这个指定的路径当中
•  slaveof 设置该数据库为其他数据库的从数据库
•  masterauth 当主数据库连接需要密码验证时，在这里指定
•  requirepass 设置客户端连接后进行任何其他指定前需要使用的密码。警告：因为 redis 速度相当快， 所以在一台比较好的服务器下，一个外部的用户可以在一秒钟进行 150K 次的密码尝试， 这意味着你需要指定非常非常强大的密码来防止暴力破解。
•  maxclients 限制同时连接的客户数量。当连接数超过这个值时，redis 将不再接收其他连接请求， 客户端尝试连接时将收到 error 信息。
•  maxmemory 设置 redis 能够使用的最大内存。当内存满了的时候，如果还接收到 set 命令，redis 将 先尝试剔除设置过 expire 信息的 key，而不管该 key 的过期时间还没有到达。在删除时， 将按照过期时间进行删除，最早将要被过期的 key 将最先被删除。如果带有 expire 信息 的 key 都删光了，那么将返回错误。这样，redis 将不再接收写请求，只接收 get 请求。 maxmemory 的设置比较适合于把 redis 当作于类似 memcached 的缓存来使用。
•  appendonly 默认情况下，redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时 的，而且备份也不能很频繁，如果发生诸如拉闸限电、拔插头等状况，那么将造成比较 大范围的数据丢失。所以 redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。 开启 append only 模式之后，redis 会把所接收到的每一次写操作请求都追加到 appendonly.aof 文件中，当 redis 重新启动时，会从该文件恢复出之前的状态。但是这样 会造成 appendonly.aof 文件过大，所以 redis 还支持了 BGREWRITEAOF 指令，对 appendonly.aof 进行重新整理。所以我认为推荐生产环境下的做法为关闭镜像，开启 appendonly.aof，同时可以选择在访问较少的时间每天对 appendonly.aof 进行重写一次。
•  appendfsync 设置对 appendonly.aof 文件进行同步的频率。always 表示每次有写操作都进行同步， everysec 表示对写操作进行累积，每秒同步一次。这个需要根据实际业务场景进行配置
•  vm-enabled 是否开启虚拟内存支持。因为 redis 是一个内存数据库，而且当内存满的时候，无法接 收新的写请求，所以在 redis 2.0 中，提供了虚拟内存的支持。但是需要注意的是，redis 中，所有的 key 都会放在内存中，在内存不够时，只会把 value 值放入交换区。这样保 证了虽然使用虚拟内存，但性能基本不受影响，同时，你需要注意的是你要把 vm-max-memory 设置到足够来放下你的所有的 key
•  vm-swap-file 设置虚拟内存的交换文件路径
•  vm-max-memory 里设置开启虚拟内存之后，redis 将使用的最大物理内存的大小。默认为 0，redis 将 把他所有的能放到交换文件的都放到交换文件中，以尽量少的使用物理内存。在生产环 境下，需要根据实际情况设置该值，最好不要使用默认的 0 
•  vm-page-size 设置虚拟内存的页大小，如果你的 value 值比较大，比如说你要在 value 中放置博客、 新闻之类的所有文章内容，就设大一点，如果要放置的都是很小的内容，那就设小一点。
•  vm-pages 设置交换文件的总的 page 数量，需要注意的是，page table 信息会放在物理内存中，每 8 个 page 就会占据 RAM 中的 1 个 byte。总的虚拟内存大小 ＝ vm-page-size * vm-pages
•  vm-max-threads 设置 VM IO 同时使用的线程数量。因为在进行内存交换时，对数据有编码和解码的过 程，所以尽管 IO 设备在硬件上本上不能支持很多的并发读写，但是还是如果你所保存 的 vlaue 值比较大，将该值设大一些，还是能够提升性能的
•  glueoutputbuf 把小的输出缓存放在一起，以便能够在一个 TCP packet 中为客户端发送多个响应，具体 原理和真实效果我不是很清楚。所以根据注释，你不是很确定的时候就设置成 yes
•  hash-max-zipmap-entries 在 redis 2.0 中引入了 hash 数据结构。当 hash 中包含超过指定元素个数并且最大的元素 没有超过临界时，hash 将以一种特殊的编码方式（大大减少内存使用）来存储，这里 可以设置这两个临界值
•  activerehashing 开启之后，redis 将在每 100 毫秒时使用 1 毫秒的 CPU 时间来对 redis 的 hash 表进行重 新 hash，可以降低内存的使用。当你的使用场景中，有非常严格的实时性需要，不能 够接受 Redis 时不时的对请求有 2 毫秒的延迟的话，把这项配置为 no。如果没有这么严 格的实时性要求，可以设置为 yes，以便能够尽可能快的释放内存

Redis 常用命令

keys

返回满足给定 pattern 的所有 key

redis 127.0.0.1:6379> keys my*

redis 127.0.0.1:6379> keys *

exists

确认一个 key 是否存在,0表示不存在

redis 127.0.0.1:6379> exists name

del

删除一个 key

redis 127.0.0.1:6379> del name

expire

设置一个 key 的过期时间 ( 单位 : 秒 )

redis 127.0.0.1:6379> expire addr 10

move

将当前数据库中的 key 转移到其它数据库中,1表示要移动的数据库，redis数据库编号从0到15

redis 127.0.0.1:6379> move age 1

persist

移除给定 key 的过期时间

redis 127.0.0.1:6379[1]> persist age

randomkey

随机返回 key 空间的一个 key

redis 127.0.0.1:6379> randomkey

rename

重命名 key

redis 127.0.0.1:6379[1]> rename age age_new

type

返回值的类型

redis 127.0.0.1:6379> type addr

redis 服务器相关命令

 

ping

测试连接是否存活

redis 127.0.0.1:6379> ping

echo

在命令行打印一些内容

redis 127.0.0.1:6379> echo name

select

选择数据库。 Redis 数据库编号从 0~15 ，我们可以选择任意一个数据库来进行数据的存取。

redis 127.0.0.1:6379> select 1

quit

退出连接。

redis 127.0.0.1:6379> quit

dbsize

返回当前数据库中 key 的数目。

redis 127.0.0.1:6379> dbsize

info

获取服务器的信息和统计。

redis 127.0.0.1:6379> info

config get

获取服务器配置信息。

redis 127.0.0.1:6379> config get dir

flushdb

删除当前选择数据库中的所有 key 。

redis 127.0.0.1:6379> flushdb

flushall

删除所有数据库中的所有 key 。

redis 127.0.0.1:6379> flushall

redis 主从复制

redis 主从复制配置和使用都非常简单。通过主从复制可以允许多个 slave server 拥有和 master server 相同的数据库副本。

 

配置 slave 服务器很简单，只需要在 slave 的配置文件中加入如下配置,通过info命令查看配置是否成功

slaveof 192.168.1.1 6379 #指定 master 的 ip 和端口

redis 事物

redis 对事务的支持目前还比较简单。 redis 只能保证一个 client 发起的事务中的命令可以连 续的执行，而中间不会插入其他 client 的命令。 由于 redis 是单线程来处理所有 client 的请 求的所以做到这点是很容易的。一般情况下 redis 在接受到一个 client 发来的命令后会立即 处理并 返回处理结果，但是当一个 client 在一个连接中发出 multi 命令有，这个连接会进入 一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一个队列中。当从此连接 受到 exec 命令后， redis 会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到 一起返回给 client. 然后此连接就 结束事务上下文

 

redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set age 10
QUEUED
redis 127.0.0.1:6379> set age 20
QUEUED
redis 127.0.0.1:6379> exec

也可以调用discard 命令来取消一个事务，让事务回滚。

乐观锁复杂事务控制

 

乐观锁： 大多数是基于数据版本（ version ）的记录机制实现的。何谓数据版本？即为数据增 加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个 “version ”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加 1 。 此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版 本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

 

 

watch 命令会监视给定的 key, 当 exec 时候如果监视的 key 从调用 watch 后发生过变化，则整 个事务会失败。也可以调用 watch 多次监视多个 key. 这 样就可以对指定的 key 加乐观锁了。 注意 watch 的 key 是对整个连接有效的，事务也一样。如果连接断开，监视和事务都会被自 动清除。当然了 exec,discard,unwatch 命令都会清除连接中的所有监视。

 

redis 127.0.0.1:6379> get age
"10"
redis 127.0.0.1:6379> watch age
OK
redis 127.0.0.1:6379> multi

redis 的事务实现是如此简单，当然会存在一些问题。第一个问题是 redis 只能保证事务的每 个命令连续执行，但是如果事务中的一个命令失败了，并不回滚其他命令，比如使用的命令 类型不匹配。

redis 127.0.0.1:6379> get age
"30"
redis 127.0.0.1:6379> get name
"HongWan"
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> incr age
QUEUED
redis 127.0.0.1:6379> incr name
QUEUED
redis 127.0.0.1:6379> exec
1) (integer) 31
2) (error) ERR value is not an integer or out of range
redis 127.0.0.1:6379> get age
"31"
redis 127.0.0.1:6379> get name
"HongWan"
redis 127.0.0.1:6379>

从这个例子中可以看到， age 由于是个数字，那么它可以有自增运算，但是 name 是个字符 串，无法对其进行自增运算，所以会报错，如果按传统关系型数据库的思路来讲，整个事务 都会回滚，但是我们看到 redis 却是将可以执行的命令提交了，所以这个现象对于习惯于关 系型数据库操作的朋友来说是很别扭的，这一点也是 redis 今天需要改进的地方。