• 欢迎来到本博客,希望可以y一起学习与分享

Redis高级特性及应用场景

综合 benz 3年前 (2018-03-29) 136次浏览 0个评论 扫描二维码
文章目录[隐藏]

redis中键的生存时间(expire)

redis中可以使用expire命令设置一个键的生存时间,到时间后redis会自动删除它。

  • 过期时间可以设置为秒或者毫秒精度。
  • 过期时间分辨率总是 1 毫秒。
  • 过期信息被复制和持久化到磁盘,当 Redis 停止时时间仍然在计算 (也就是说 Redis 保存了过期时间)。

expire 设置生存时间(单位/秒)

ttl 查看键的剩余生存时间

persist 取消生存时间

expireat [key] unix时间戳1351858600

示例:

应用场景:

  • 限时的优惠活动信息
  • 网站数据缓存(对于一些需要定时更新的数据,例如:积分排行榜)
  • 手机验证码
  • 限制网站访客访问频率(例如:1分钟最多访问10次)

redis的事务(transaction)

redis中的事务是一组命令的集合。事务同命令一样都是redis的最小执行单元。一组事务中的命令要么都执行,要么都不执行。(例如:转账)

原理:

先将属于一个事务的命令发送给redis进行缓存,最后再让redis依次执行这些命令。

应用场景:

  • 一组命令必须同时都执行,或者都不执行。
  • 我们想要保证一组命令在执行的过程之中不被其它命令插入。

命令:

错误处理

  • 1:语法错误:致命的错误,事务中的所有命令都不会执行
  • 2:运行错误:不会影响事务中其他命令的执行

Redis 不支持回滚(roll back)

正因为redis不支持回滚功能,才使得redis在事务上可以保持简洁和快速。

watch命令

作用:监控一个或者多个键,当被监控的键值被修改后阻止之后的一个事务的执行。

但是不能保证其它客户端不修改这一键值,所以我们需要在事务执行失败后重新执行事务中的命令。

注意:执行完事务的exec命令之后,watch就会取消对所有键值的监控

unwatch:取消监控

操作图示:

redis中数据的排序(sort)

sort命令可以对列表类型,集合类型和有序集合类型进行排序。

by 参考键(参考键可以是字符串类型或者是hash类型的某个字段,hash类型的格式为:键名->字段名)

  • 如果参考键中不带*号则不排序
  • 如果某个元素的参考键不存在,则默认参考键的值为0

扩展 get参数

  • get参数的规则和by参数的规则一样
  • get # (返回元素本身的值)

扩展 store参数

使用store 参数可以把sort的排序结果保存到指定的列表中

性能优化

  • 1:尽可能减少待排序键中元素的数量
  • 2:使用limit参数只获取需要的数据
  • 3:如果要排序的数据数量很大,尽可能使用store参数将结果缓存。

操作图示:

“发布/订阅”模式

发布:publish

订阅:subscribe

取消订阅:unsubscribe

按照规则订阅:psubscribe

按照规则取消订阅:punsubscribe

注意:使用punsubscribe命令只能退订通过psubscribe 订阅的频道。

操作图示:(订阅频道后,频道每发布一条消息,都能动态显示出来)

订阅:

redis任务队列

任务队列:使用lpush和rpop(brpop)可以实现普通的任务队列。

brpop是列表的阻塞式(blocking)弹出原语。

它是 RPOP命令的阻塞版本,当给定列表内没有任何元素可供弹出的时候,连接将被 BRPOP命令阻塞,直到等待超时或发现可弹出元素为止。

当给定多个 key 参数时,按参数 key 的先后顺序依次检查各个列表,弹出第一个非空列表的尾部元素。

优先级队列:

操作图示:

redis管道(pipeline)

redis的pipeline(管道)功能在命令行中没有,但是redis是支持管道的,在java的客户端(jedis)中是可以使用的。

测试发现:

1:不使用管道方式,插入1000条数据耗时328毫秒

2:使用管道方式,插入1000条数据耗时37毫秒

在插入更多数据的时候,管道的优势更加明显:测试10万条数据的时候,不使用管道要40秒,实用管道378毫秒。

redis持久化(persistence)

redis支持两种方式的持久化,可以单独使用或者结合起来使用。

第一种:RDB方式(redis默认的持久化方式)

第二种:AOF方式

redis持久化之RDB

rdb方式的持久化是通过快照完成的,当符合一定条件时redis会自动将内存中的所有数据执行快照操作并存储到硬盘上。默认存储在dump.rdb文件中。(文件名在配置文件中dbfilename)

redis进行快照的时机(在配置文件redis.conf中)

Redis自动实现快照的过程

  • 1、redis使用fork函数复制一份当前进程的副本(子进程)
  • 2、父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件
  • 3、当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此,一次快照操作完成。

注意:redis在进行快照的过程中不会修改RDB文件,只有快照结束后才会将旧的文件替换成新的,也就是说任何时候RDB文件都是完整的。

这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份

RDB文件是经过压缩的二进制文件,占用的空间会小于内存中的数据,更加利于传输。

手动执行save或者bgsave命令让redis执行快照。

两个命令的区别在于,save是由主进程进行快照操作,会阻塞其它请求。bgsave是由redis执行fork函数复制出一个子进程来进行快照操作。

文件修复:

rdb的优缺点

优点:由于存储的有数据快照文件,恢复数据很方便。

缺点:会丢失最后一次快照以后更改的所有数据。

redis持久化之AOF

aof方式的持久化是通过日志文件的方式。默认情况下redis没有开启aof,可以通过参数appendonly参数开启。

aof文件的保存位置和rdb文件的位置相同,都是dir参数设置的,默认的文件名是appendonly.aof,可以通过appendfilename参数修改

redis写命令同步的时机

aof日志文件重写

手动执行bgrewriteaof进行重写

重写的过程只和内存中的数据有关,和之前的aof文件无关。

所谓的“重写”其实是一个有歧义的词语, 实际上, AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取, 它针对的是数据库中键的当前值。

文件修复:

动态切换redis持久方式,从 RDB 切换到 AOF(支持Redis 2.2及以上)

注意:

1、当redis启动时,如果rdb持久化和aof持久化都打开了,那么程序会优先使用aof方式来恢复数据集,因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了,则启动之后数据库内容为空。

2、如果想把正在运行的redis数据库,从RDB切换到AOF,建议先使用动态切换方式,再修改配置文件,重启数据库。(不能自己修改配置文件,重启数据库,否则数据库中数据就为空了。)

redis中的config命令

使用config set可以动态设置参数信息,服务器重启之后就失效了。

使用config get可以查看所有可以使用config set命令设置的参数

使用config rewrite命令对启动 Redis 服务器时所指定的 redis.conf 文件进行改写(Redis 2.8 及以上版本才可以使用),主要是把使用config set动态指定的命令保存到配置文件中。

注意:config rewrite命令对 redis.conf 文件的重写是原子性的, 并且是一致的: 如果重写出错或重写期间服务器崩溃, 那么重写失败, 原有 redis.conf 文件不会被修改。 如果重写成功, 那么 redis.conf 文件为重写后的新文件。

redis的安全策略

设置数据库密码

修改配置

验证密码

bind参数(可以让数据库只能在指定IP下访问)

命令重命名

修改命令的名称

禁用命令

redis info命令

以一种易于解释(parse)且易于阅读的格式,返回关于 Redis 服务器的各种信息和统计数值。

通过给定可选的参数 section ,可以让命令只返回某一部分的信息:

内容过多,详细参考

http://redisdoc.com/server/info.html

redis内存占用情况

测试情况:

100万个键值对(键是0到999999值是字符串“hello world”)在32位操作系统的笔记本上 用了100MB

使用64位的操作系统的话,相对来说占用的内存会多一点,这是因为64位的系统里指针占用了8个字节,但是64位系统也能支持更大的内存,所以运行大型的redis服务还是建议使用64位服务器

Redis实例最多存keys数

理论上Redis可以处理多达2的32次方的keys,并且在实际中进行了测试,每个实例至少存放了2亿5千万的keys

也可以说Redis的存储极限是系统中的可用内存值。

优化

redis优化1

精简键名和键值

键名:尽量精简,但是也不能单纯为了节约空间而使用不易理解的键名。

键值:对于键值的数量固定的话可以使用0和1这样的数字来表示,(例如:male/female、right/wrong)

当业务场景不需要数据持久化时,关闭所有的持久化方式可以获得最佳的性能

内部编码优化(大家可以自己了解)

redis为每种数据类型都提供了两种内部编码方式,在不同的情况下redis会自动调整合适的编码方式。(如图所示)

SLOWLOG [get/reset/len]

当发现redis性能下降的时候可以查看下是哪些命令导致的

redis优化2

修改linux内核内存分配策略

原因:

redis在运行过程中可能会出现下面问题

错误日志:

redis在备份数据的时候,会fork出一个子进程,理论上child进程所占用的内存和parent是一样的,比如parent占用的内存为8G,这个时候也要同样分配8G的内存给child,如果内存无法负担,往往会造成redis服务器的down机或者IO负载过高,效率下降。所以内存分配策略应该设置为 1(表示内核允许分配所有的物理内存,而不管当前的内存状态如何)。

内存分配策略有三种

可选值:0、1、2。

0, 表示内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存,内存申请允许;否则,内存申请失败,并把错误返回给应用进程。

1, 不管需要多少内存,都允许申请。

2, 只允许分配物理内存和交换内存的大小。(交换内存一般是物理内存的一半)

向/etc/sysctl.conf添加

或者执行

问题图示:

redis优化3

关闭Transparent Huge Pages(THP)

THP会造成内存锁影响redis性能,建议关闭

使用root用户执行下面命令

把这条命令添加到这个文件中/etc/rc.local

redis优化4

修改linux中TCP 监听的最大容纳数量

在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核默默地将这个值减小到/proc/sys/net/core/somaxconn的值,所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。

注意:这个参数并不是限制redis的最大链接数。如果想限制redis的最大连接数需要修改maxclients,默认最大连接数为10000。

redis优化5

限制redis的内存大小

通过redis的info命令查看内存使用情况

如果不设置maxmemory或者设置为0,64位系统不限制内存,32位系统最多使用3GB内存。

修改配置文件中的maxmemory和maxmemory-policy

如果可以确定数据总量不大,并且内存足够的情况下不需要限制redis使用的内存大小。如果数据量不可预估,并且内存也有限的话,尽量限制下redis使用的内存大小,这样可以避免redis使用swap分区或者出现OOM错误。

注意:如果不限制内存,当物理内存使用完之后,会使用swap分区,这样性能较低,如果限制了内存,当到达指定内存之后就不能添加数据了,否则会报OOM错误。可以设置maxmemory-policy,内存不足时删除数据。

拓展

used_memory是Redis使用的内存总量,它包含了实际缓存占用的内存和Redis自身运行所占用的内存(以字节(byte)为单位,其中used_memory_human上的数据和used_memory是一样的值,它以M为单位显示,仅为了方便阅读)。

如果一个Redis实例的内存使用率超过可用最大内存(used_memory >可用最大内存),那么操作系统开始进行内存与swap空间交换,把内存中旧的或不再使用的内容写入硬盘上(硬盘上的这块空间叫Swap分区),以便腾出新的物理内存给新页或活动页(page)使用。

在硬盘上进行读写操作要比在内存上进行读写操作,时间上慢了近5个数量级,内存是0.1us(微秒)、而硬盘是10ms(毫秒)。如果Redis进程上发生内存交换,那么Redis和依赖Redis上数据的应用会受到严重的性能影响。 通过查看used_memory指标可知道Redis正在使用的内存情况,如果used_memory>可用最大内存,那就说明Redis实例正在进行内存交换或者已经内存交换完毕。管理员根据这个情况,执行相对应的应急措施。

排查方案:

若是在使用Redis期间没有开启rdb快照或aof持久化策略,那么缓存数据在Redis崩溃时就有丢失的危险。因为当Redis内存使用率超过可用内存的95%时,部分数据开始在内存与swap空间来回交换,这时就可能有丢失数据的危险。

当开启并触发快照功能时,Redis会fork一个子进程把当前内存中的数据完全复制一份写入到硬盘上。因此若是当前使用内存超过可用内存的45%时触发快照功能,那么此时进行的内存交换会变的非常危险(可能会丢失数据)。 倘若在这个时候实例上有大量频繁的更新操作,问题会变得更加严重。

通过减少Redis的内存占用率,来避免这样的问题,或者使用下面的技巧来避免内存交换发生:

  • 1、尽可能的使用Hash数据结构。因为Redis在储存小于100个字段的Hash结构上,其存储效率是非常高的。所以在不需要集合(set)操作或list的push/pop操作的时候,尽可能的使用Hash结构。比如,在一个web应用程序中,需要存储一个对象表示用户信息,使用单个key表示一个用户,其每个属性存储在Hash的字段里,这样要比给每个属性单独设置一个key-value要高效的多。 通常情况下倘若有数据使用string结构,用多个key存储时,那么应该转换成单key多字段的Hash结构。 如上述例子中介绍的Hash结构应包含,单个对象的属性或者单个用户各种各样的资料。Hash结构的操作命令是HSET(key, fields, value)和HGET(key, field),使用它可以存储或从Hash中取出指定的字段。
  • 2、设置key的过期时间。一个减少内存使用率的简单方法就是,每当存储对象时确保设置key的过期时间。倘若key在明确的时间周期内使用或者旧key不大可能被使用时,就可以用Redis过期时间命令(expire,expireat, pexpire, pexpireat)去设置过期时间,这样Redis会在key过期时自动删除key。 假如你知道每秒钟有多少个新key-value被创建,那可以调整key的存活时间,并指定阀值去限制Redis使用的最大内存。
  • 3、回收key。在Redis配置文件中(一般叫Redis.conf),通过设置“maxmemory”属性的值可以限制Redis最大使用的内存,修改后重启实例生效。也可以使用客户端命令config set maxmemory 去修改值,这个命令是立即生效的,但会在重启后会失效,需要使用config rewrite命令去刷新配置文件。 若是启用了Redis快照功能,应该设置“maxmemory”值为系统可使用内存的45%,因为快照时需要一倍的内存来复制整个数据集,也就是说如果当前已使用45%,在快照期间会变成95%(45%+45%+5%),其中5%是预留给其他的开销。 如果没开启快照功能,maxmemory最高能设置为系统可用内存的95%。

当内存使用达到设置的最大阀值时,需要选择一种key的回收策略,可在Redis.conf配置文件中修改“maxmemory-policy”属性值。 若是Redis数据集中的key都设置了过期时间,那么“volatile-ttl”策略是比较好的选择。但如果key在达到最大内存限制时没能够迅速过期,或者根本没有设置过期时间。那么设置为“allkeys-lru”值比较合适,它允许Redis从整个数据集中挑选最近最少使用的key进行删除(LRU淘汰算法)。Redis还提供了一些其他淘汰策略,如下:

通过设置maxmemory为系统可用内存的45%或95%(取决于持久化策略)和设置“maxmemory-policy”为“volatile-ttl”或“allkeys-lru”(取决于过期设置),可以比较准确的限制Redis最大内存使用率,在绝大多数场景下使用这2种方式可确保Redis不会进行内存交换。倘若你担心由于限制了内存使用率导致丢失数据的话,可以设置noneviction值禁止淘汰数据。

redis优化6

Redis是个单线程模型,客户端过来的命令是按照顺序执行的,所以想要一次添加多条数据的时候可以使用管道,或者使用一次可以添加多条数据的命令,例如:

Redis应用场景

发布与订阅

在更新中保持用户对数据的映射是系统中的一个普遍任务。Redis的pub/sub功能使用了SUBSCRIBE、UNSUBSCRIBE和PUBLISH命令,让这个变得更加容易。

代码示例:

打印结果:

限制网站访客访问频率

进行各种数据统计的用途是非常广泛的,比如想知道什么时候封锁一个IP地址。INCRBY命令让这些变得很容易,通过原子递增保持计数;GETSET用来重置计数器;过期属性expire用来确认一个关键字什么时候应该删除。

代码示例:

打印结果:

监控变量在事务执行时是否被修改

代码示例:

打印结果:

变量a没有被修改时:

变量a被修改时:

各种计数

商品维度计数(喜欢数,评论数,鉴定数,浏览数,etc)

采用Redis 的类型: Hash. 如果你对redis数据类型不太熟悉,可以参考 http://redis.io/topics/data-types-intro

为product定义个key product:,为每种数值定义hashkey, 譬如喜欢数xihuan

用户维度计数(动态数、关注数、粉丝数、喜欢商品数、发帖数 等)

用户维度计数同商品维度计数都采用 Hash. 为User定义个key user:,为每种数值定义hashkey, 譬如关注数follow

存储社交关系

譬如将用戶的好友/粉丝/关注,可以存在一个sorted set中,score可以是timestamp,这样求两个人的共同好友的操作,可能就只需要用求交集命令即可。

用作缓存代替memcached

缓存内容示例:(商品列表,评论列表,@提示列表,etc)

相对memcached 简单的key-value存储来说,redis众多的数据结构(list,set,sorted set,hash, etc)可以更方便cache各种业务数据,性能也不亚于memcached。

例如:

反spam系统

例如:(评论,发布商品,论坛发贴,etc)

作为一个电商网站被各种spam攻击是少不免(垃圾评论、发布垃圾商品、广告、刷自家商品排名等),针对这些spam制定一系列anti-spam规则,其中有些规则可以利用redis做实时分析,譬如:1分钟评论不得超过2次、5分钟评论少于5次等(更多机制/规则需要结合drools )。 采用sorted set将最近一天用户操作记录起来(为什么不全部记录?节省memory,全部操作会记录到log,后续利用hadoop进行更全面分析统计),通过

打印结果:

用户Timeline/Feeds

在逛有个类似微博的栏目我关注,里面包括关注的人、主题、品牌的动态。redis在这边主要当作cache使用。

最新列表&排行榜

这里采用Redis的List数据结构或sorted set 结构, 方便实现最新列表or排行榜 等业务场景。

消息通知

其实这业务场景也可以算在计数上,也是采用Hash。如下:

消息队列

当在集群环境时候,java ConcurrentLinkedQueue 就无法满足我们需求,此时可以采用Redis的List数据结构实现分布式的消息队列。

显示最新的项目列表

Redis使用的是常驻内存的缓存,速度非常快。LPUSH用来插入一个内容ID,作为关键字存储在列表头部。LTRIM用来限制列表中的项目数最多为5000。如果用户需要的检索的数据量超越这个缓存容量,这时才需要把请求发送到数据库。

删除和过滤。

如果一篇文章被删除,可以使用LREM从缓存中彻底清除掉。

排行榜及相关问题

排行榜(leader board)按照得分进行排序。ZADD命令可以直接实现这个功能,而ZREVRANGE命令可以用来按照得分来获取前100名的用户,ZRANK可以用来获取用户排名,非常直接而且操作容易。

按照用户投票和时间排序

这就像Reddit的排行榜,得分会随着时间变化。LPUSH和LTRIM命令结合运用,把文章添加到一个列表中。一项后台任务用来获取列表,并重新计算列表的排序,ZADD命令用来按照新的顺序填充生成列表。列表可以实现非常快速的检索,即使是负载很重的站点。

过期项目处理

使用unix时间作为关键字,用来保持列表能够按时间排序。对current_time和time_to_live进行检索,完成查找过期项目的艰巨任务。另一项后台任务使用ZRANGE…WITHSCORES进行查询,删除过期的条目。

特定时间内的特定项目

这是特定访问者的问题,可以通过给每次页面浏览使用SADD命令来解决。SADD不会将已经存在的成员添加到一个集合。

实时分析

使用Redis原语命令,更容易实施垃圾邮件过滤系统或其他实时跟踪系统。

队列

在当前的编程中队列随处可见。除了push和pop类型的命令之外,Redis还有阻塞队列的命令,能够让一个程序在执行时被另一个程序添加到队列。你也可以做些更有趣的事情,比如一个旋转更新的RSS feed队列。

缓存

Redis缓存使用的方式与memcache相同。

网络应用不能无休止地进行模型的战争,看看这些Redis的原语命令,尽管简单但功能强大,把它们加以组合,所能完成的就更无法想象。当然,你可以专门编写代码来完成所有这些操作,但Redis实现起来显然更为轻松。

手机验证码

使用expire设置验证码失效时间

redis既可以作为数据库来用,也可以作为缓存系统来用


文章 Redis高级特性及应用场景 转载需要注明出处
喜欢 (0)

您必须 登录 才能发表评论!