你的位置:首页 > 数据库

[数据库]redis 基础


一 redis数据类型
redis支持5种类型的数据类型,它描述如下的:
1. 字符串
  Redis字符串是字节序列。Redis字符串是二进制安全的,这意味着他们有一个已知的长度没有任何特殊字符终止,所以你可以存储任何东西,512兆为上限。
2. 哈希
  Redis的哈希是键值对的集合。 Redis的哈希值是字符串字段和字符串值之间的映射,因此它们被用来表示对象.
3. 列表
  Redis的列表是简单的字符串列表,排序插入顺序。您可以添加元素到Redis的列表的头部或尾部。
  列表的最大长度为 232 - 1 元素(4294967295,每个列表中可容纳超过4十亿的元素)。
4. 集合
  Redis的集合是字符串的无序集合。在Redis您可以添加,删除和测试文件是否存在,在成员O(1)的时间复杂度。
  集合中的元素最大数量为 232 - 1 (4294967295,可容纳超过4十亿元素)。
5. 有序集合
  Redis的有序集合类似于Redis的集合,字符串不重复的集合。不同的是,一个有序集合的每个成员用分数,以便采取有序set命令,从最小的到最大的成员分数有关。虽然成员具有唯一性,但分数可能会重复。

二 Redis 文件说明

$ find . -type f -executable./redis-benchmark // 用于进行redis性能测试的工具./redis-check-dump // 用于修复出问题的dump.rdb文件./redis-cli // redis的客户端./redis-server // redis的服务端./redis-check-aof // 用于修复出问题的AOF文件./redis-sentinel // 用于集群管理

 

三 Redis 管理

  • 服务启动:./redis-server ../redis.conf 端口默认为6379
  • 使用客户端:./redis-cli
  • 通过客户端来关闭redis服务端 127.0.0.1:6379> shutdown
  •  一些注意:

    1. key不要太长,尽量不要超过1024字节,这不仅消耗内存,而且会降低查找的效率;
    2. key也不要太短,太短的话,key的可读性会降低;
    3. 在一个项目中,key最好使用统一的命名模式,例如user:10000:passwd。
    4. 字符串类型的用法就是这么简单,因为是二进制安全的,所以你完全可以把一个图片文件的内容作为字符串来存储。

 

四 redis 持久化

  •  Redis提供了两种持久化的方式,分别是RDB(Redis DataBase)和AOF(Append Only File)。
  • RDB,简而言之,就是在不同的时间点,将redis存储的数据生成快照并存储到磁盘等介质上;
  • AOF,则是换了一个角度来实现持久化,那就是将redis执行过的所有写指令记录下来.
  • 在下次redis重新启动时,只要把这些写指令从前到后再重复执行一遍,就可以实现数据恢复了。
  • 其实RDB和AOF两种方式也可以同时使用,在这种情况下,如果redis重启的话,则会优先采用AOF方式来进行数据恢复,这是因为AOF方式的数据恢复完整度更高。
  • 如果你没有数据持久化的需求,也完全可以关闭RDB和AOF方式,这样的话,redis将变成一个纯内存数据库,就像memcache一样。
  • 两种方式是可以同时使用的。


五 redis持久化 – RDB

  •  Redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件。正是这种特性,让我们可以随时来进行备份,因为快照文件总是完整可用的。
  • 对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而主进程是不会进行任何IO操作的,这样就确保了redis极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。

 

六 Redis持久化 - AOF

  •  AOF,英文是Append Only File,即只允许追加不允许改写的文件。
  •  通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作(如SET等),redis就会被追加到AOF文件的末尾。
  •  默认的AOF持久化策略是每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中).因为在这种情况下,redis仍然可以保持很好的处理性能,即使redis故障,也只会丢失最近1秒钟的数据。
  • 如果在追加日志时,恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整,也没有关系,redis提供了redis-check-aof工具,可以用来进行日志修复。
  • AOF文件会变得越来越大,为此,redis提供了AOF文件重写(rewrite)机制,即当AOF文件的大小超过所设定的阈值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。
  • 在进行AOF重写时,仍然是采用先写临时文件,全部完成后再替换的流程,所以断电、磁盘满等问题都不会影响AOF文件的可用性.
  • AOF的一个好处场景再现,如果有人不小心清了数据库。在AOF文件还没没被重写的情况下, 可以通过停掉Redis修改AOF文件,去掉误操作的语句。重启Redis恢复数据。
  • 如果出现AOF文件被写坏的情况。可按如下步骤修复:

     a.备份被写坏的AOF文件
   b.运行redis-check-aof –fix进行修复
   c.用diff -u来看下两个文件的差异,确认问题点
   d.重启redis,加载修复后的AOF文件

 

七 Redis 主从同步

  • redis的主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低redis的处理性能。
  • 主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,这样可以提高主服务器的处理性能。
  • 在主从架构中,从服务器通常被设置为只读模式,这样可以避免从服务器的数据被误修改。
  • 但是从服务器仍然可以接受CONFIG等指令,所以还是不应该将从服务器直接暴露到不安全的网络环境中。
  • 如果必须如此,那可以考虑给重要指令进行重命名,来避免命令被外人误执行。
  • 重命名指定可以参考另一篇blog

 

八 Redis 同步

  • 从服务器会向主服务器发出SYNC指令,当主服务器接到此命令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作,也就是将主服务器的数据写入RDB文件中。
  • 在数据持久化期间,主服务器将执行的写指令都缓存在内存中。
  • 在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接到此文件后会将其存储到磁盘上,然后再将其读取到内存中。
  • 这个动作完成后,主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

 

九 redis 事务

  • 事务是指“一个完整的动作,要么全部执行,要么什么也没有做”。
  • 四个redis指令,即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础。
  • MULTI用来组装一个事务;
  • EXEC用来执行一个事务;
  • DISCARD用来取消一个事务;
  • WATCH用来监视一些key,一旦这些key在事务执行之前被改变,则取消事务的执行。

  例子:

redis> MULTI //标记事务开始 OKredis> INCR user_id //多条命令按顺序入队QUEUEDredis> INCR user_idQUEUEDredis> INCR user_idQUEUEDredis> PINGQUEUEDredis> EXEC //执行1) (integer) 12) (integer) 23) (integer) 34) PONG

  • QUEUED的字样,这表示我们在用MULTI组装事务时,每一个命令都会进入到内存队列中缓存起来,如果出现QUEUED则表示我们这个命令成功插入了缓存队列,在将来执行EXEC时,这些被QUEUED的命令都会被组装成一个事务来执行.
  • 对于事务的执行来说,如果redis开启了AOF持久化的话,那么一旦事务被成功执行,事务中的命令就会通过write命令一次性写到磁盘中去。
  • 如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题,那么就可能出现只有部分命令进行了AOF持久化,这时AOF文件就会出现不完整的情况。这时,我们可以使用redis-check-aof工具来修复这一问题,这个工具会将AOF文件中不完整的信息移除,确保AOF文件完整可用。

    两类错误:

  • 调用EXEC之前的错误。
  • 有可能是由于语法有误导致的,也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况,redis都会进行记录,在客户端调用EXEC时,redis会拒绝执行这一事务。
  • 调用EXEC之后的错误。
  • Redis则采取了完全不同的策略,即redis不会理睬这些错误,而是继续向下执行事务中的其他命令。这是因为,对于应用层面的错误,并不是redis自身需要考虑和处理的问题,所以一个事务中如果某一条命令执行失败,并不会影响接下来的其他命令的执行。
  • WATCH本身的作用是“监视key是否被改动过”,而且支持同时监视多个key,只要还没真正触发事务,WATCH都会尽职尽责的监视,一旦发现某个key被修改了,在执行EXEC时就会返回nil,表示事务无法触发。