美文网首页
第二章:API 的理解和使用-键管理及数据库管理

第二章:API 的理解和使用-键管理及数据库管理

作者: super_pcm | 来源:发表于2019-07-31 22:31 被阅读0次

    2.7 键管理

    本节将按照单个键、遍历键、数据库管理三个维度对一些通用命令进行介绍。

    2.7.1 单个键管理

    1. 键重命名

    rename key newkey
    

    如果在rename之前,目标键已经存在,那么它的值也将被覆盖。为了防止被强行rename,Redis提供了renamenx命令,确保只有newKey不存在时候才被覆盖。
    由于重命名键期间会执行del命令删除旧的键,如果键对应的值比较大,会存在阻塞Redis的可能性,这点不要忽视。

    2. 随机返回一个键

    randomkey
    

    3. 键过期

    2.1节简单介绍键过期功能,它可以自动将带有过期时间的键删除,在许多应用场景都非常有帮助。除了expire、ttl命令以外,Redis还提供了expireat、pexpire、pexpireat、pttl、persist等一系列命令,下面分别进行说明:

    • expire key seconds:键在seconds秒后过期。
    • expireat key timestamp:键在秒级时间戳timestamp后过期。
      ttl命令和pttl都可以查询键的剩余过期时间,但是pttl精度更高可以达到毫秒级别
      在使用Redis相关过期命令时,需要注意以下几点。
    • 如果expire key的键不存在,返回结果为0:
    • 如果过期时间为负值,键会立即被删除,犹如使用del命令一样:
    • persist命令可以将键的过期时间清除:
    • 对于字符串类型键,执行set命令会去掉过期时间,这个问题很容易在开发中被忽视。
    • Redis不支持二级数据结构(例如哈希、列表)内部元素的过期功能,例如不能对列表类型的一个元素做过期时间设置。
    • setex命令作为set+expire的组合,不但是原子执行,同时减少了一次网络通讯的时间。

    4. 迁移键

    迁移键功能非常重要,因为有时候我们只想把部分数据由一个Redis迁移到另一个Redis(例如从生产环境迁移到测试环境),Redis发展历程中提供了move、dump+restore、migrate三组迁移键的方法,它们的实现方式以及使用的场景不太相同,下面分别介绍。

    • move
    move key db
    

    move命令用于在Redis内部进行数据迁移,Redis内部可以有多个数据库,由于多个数据库功能后面会进行介绍,这里只需要知道Redis内部可以有多个数据库,彼此在数据上是相互隔离的,move key db就是把指定的键从源数据库移动到目标数据库中.Redis的多数据库本来就不大实用,所以move方法了解即可。

    • dump+restore
    dump key
    restore key ttl value
    

    dump+restore可以实现在不同的Redis实例之间进行数据迁移的功能,整个迁移的过程分为两步:
    1)在源Redis上,dump命令会将键值序列化,格式采用的是RDB格式。
    2)在目标Redis上,restore命令将上面序列化的值进行复原,其中ttl参数代表过期时间,如果ttl=0代表没有过期时间。
    有关dump+restore有两点需要注意:第一,整个迁移过程并非原子性的,而是通过客户端分步完成的。第二,迁移过程是开启了两个客户端连接,所以dump的结果不是在源Redis和目标Redis之间进行传输。

    • migrate
    migrate host port key|"" destination-db timeout [copy] [replace] [keys key [key
    

    migrate命令也是用于在Redis实例间进行数据迁移的,实际上migrate命令就是将dump、restore、del三个命令进行组合,从而简化了操作流程。migrate命令具有原子性,而且从Redis3.0.6版本以后已经支持迁移多个键的功能,有效地提高了迁移效率,migrate在10.4节水平扩容中起到重要作用。
    migrate实现过程和dump+restore基本类似,但是有3点不太相同:第一,整个过程是原子执行的,不需要在多个Redis实例上开启客户端的,只需要在源Redis上执行migrate命令即可。第二,migrate命令的数据传输直接在源Redis和目标Redis上完成的。第三,目标Redis完成restore后会发送OK给源Redis,源Redis接收后会根据migrate对应的选项来决定是否在源Redis上删除对应的键。

    2.7.2 遍历键

    1. 全量遍历键

    keys pattern
    

    本章的一开始就介绍过keys ,实际上keys后面除了可以接之外,还可以其他的通配符。

    2. 渐进式遍历

    Redis从2.8版本后,提供了一个新的命令scan,它能有效的解决keys命令存在的问题。和keys命令执行时会遍历所有键不同,scan采用渐进式遍历的方式来解决keys命令可能带来的阻塞问题,每次scan命令的时间复杂度是O(1),但是要真正实现keys的功能,需要执行多次scan。Redis存储键值对实际使用的是hashtable的数据结构,其简化模型如图所示。


    hashtable示意图

    那么每次执行scan,可以想象成只扫描一个字典中的一部分键,直到将字典中的所有键遍历完毕。scan的使用方法如下:

    scan cursor [match pattern] [count number]
    
    • cursor是必需参数,实际上cursor是一个游标,第一次遍历从0开始,每次scan遍历完都会返回当前游标的值,直到游标值为0,表示遍历结束。
    • match pattern是可选参数,它的作用的是做模式的匹配,这点和keys的模式匹配很像。
    • count number是可选参数,它的作用是表明每次要遍历的键个数,默认值是10,此参数可以适当增大。
      除了scan以外,Redis提供了面向哈希类型、集合类型、有序集合的扫描遍历命令,解决诸如hgetall、smembers、zrange可能产生的阻塞问题,对应的命令分别是hscan、sscan、zscan,它们的用法和scan基本类似.
      渐进式遍历可以有效的解决keys命令可能产生的阻塞问题,但是scan并非完美无瑕,如果在scan的过程中如果有键的变化(增加、删除、修改),那么遍历效果可能会碰到如下问题:新增的键可能没有遍历到,遍历出了重复的键等情况,也就是说scan并不能保证完整的遍历出来所有的键,这些是我们在开发时需要考虑的。

    2.7.3 数据库管理

    Redis提供了几个面向Redis数据库的操作,它们分别是dbsize、select、flushdb/flushall命令,本节将通过具体的使用场景介绍这些命令。

    1. 切换数据库

    select dbIndex
    

    许多关系型数据库,例如MySQL支持在一个实例下有多个数据库存在的,但是与关系型数据库用字符来区分不同数据库名不同,Redis只是用数字作为多个数据库的实现。Redis默认配置中是有16个数据库.
    那么能不能像使用测试数据库和正式数据库一样,把正式的数据放在0号数据库,测试的数据库放在1号数据库,那么两者在数据上就不会彼此受影响了。事实真有那么好吗?
    Redis3.0中已经逐渐弱化这个功能,例如Redis的分布式实现RedisCluster只允许使用0号数据库,只不过为了向下兼容老版本的数据库功能,该功能没有完全废弃掉,下面分析一下为什么要废弃掉这个“优秀”的功能呢?总结起来有三点:

    • Redis是单线程的。如果使用多个数据库,那么这些数据库仍然是使用一个CPU,彼此之间还是会受到影响的。
    • 多数据库的使用方式,会让调试和运维不同业务的数据库变的困难,假如有一个慢查询存在,依然会影响其他数据库,这样会使得别的业务方定位问题非常的困难。
    • 部分Redis的客户端根本就不支持这种方式。即使支持,在开发的时候来回切换数字形式的数据库,很容易弄乱。
      笔者建议如果要使用多个数据库功能,完全可以在一台机器上部署多个Redis实例,彼此用端口来做区分,因为现代计算机或者服务器通常是有多个CPU的。这样既保证了业务之间不会受到影响,又合理地使用了CPU资源.

    2. flushdb/flushall

    flushdb/flushall命令用于清除数据库,两者的区别的是flushdb只清除当前数据库,flushall会清除所有数据库。
    flushdb/flushall命令可以非常方便的清理数据,但是也带来两个问题:

    • flushdb/flushall命令会将所有数据清除,一旦误操作后果不堪设想,第12章会介绍rename-command配置规避这个问题,以及如何在误操作后快速恢复数据。
    • 如果当前数据库键值数量比较多,flushdb/flushall存在阻塞Redis的可能性。

    相关文章

      网友评论

          本文标题:第二章:API 的理解和使用-键管理及数据库管理

          本文链接:https://www.haomeiwen.com/subject/ebwxdctx.html