Redis使用场景及策略

使用场景

序号场景推荐数据类型
1共享数据银行交易的token,5分钟更新一次String
2自增流水号代替原oracle的sequenceString
3计数器访问量。INCRString
4session缓存登录用户session信息Hash
5排行榜top排名Sorted Set
6分布式锁 String
7过载保护流控String
8缓存热数据kv数据字典String,Hash...
9短期临时数据短信验证码,黑白名单String,Hash...
10秒杀系统 String,Hash...

  • 共享数据
    常见于大型分布式系统的场景。如多个银行前置程序共享一个银行交易token,交易token每5分钟需要更新一次。如下图:当前银行交易token为1234...

banktoken.png


  • 自增流水

基于redis的单线程特征,生成自增流水号,代替原oracle的sequence。命令:INCR。

正例:32位流水号生成规则。yyyymmddhhmmssSSS+5位随机数+10位redis自增流水号-->20180417175634239501290000000001


  • 分布式锁
  1. SETNX key val
    当且仅当key不存在时,set一个key为val的字符串,返回1;若key存在,则什么都不做,返回0。

  2. expire key timeout
    为key设置一个超时时间,单位为second,超过这个时间锁会自动释放,避免死锁。

  3. delete key
    删除key

-- 获取锁的时候,使用setnx加锁,并使用expire命令为锁添加一个超时时间,超过该时间则自动释放锁,锁的value值为一个随机生成的UUID,通过此在释放锁的时候进行判断。

--获取锁的时候还设置一个获取的超时时间,若超过这个时间则放弃获取锁。

--释放锁的时候,通过UUID判断是不是该锁,若是该锁,则执行delete进行锁释放。


  • 过载保护
  1. 调用前,incr指定key,自增后返回key当前值,判断当前值是否为1,为1则设置过期时间,不为1则判断当前值是否大于设置阈值,大于则拒绝。

  2. 调用完成后,decr指定key。


  • 缓存热数据

热点数据(经常会被查询,但是不经常被修改或者删除的数据)。如:银行字典,城市列表,卡bin数据。


  • 秒杀系统

基于redis的单线程特征,防止超发现象和数据库访问量激增。秒杀期间,在redis内处理商品数量逻辑,后期再与数据库同步。


部署策略

  • 为了减少Redis集群故障影响扩大化,建议每个业务领域(或组织)使用独立的redis集群。

  • 由专职的运维组织统一管理各领域的redis集群。

  • redis集群服务端禁止keys,flushall、flushdb命令。

开发规约

键值设计

1.key名设计

1)【建议】: 可读性和可管理性

以{系统简称}:{子系统简称}:{word1}:{…}{wordN}为前缀(防止key冲突),用冒号分隔。

正例:groupmall:order:123

2)【建议】:简洁性

保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视。

3)【强制】:不要包含特殊字符

反例:包含空格、换行、单双引号以及其他转义字符

2.value设计

1)【强制】:拒绝bigkey(防止慢查询)

string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。

反例:一个包含200万个元素的list。

非字符串的bigkey,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,会触发del操作,造成阻塞,而且该操作不会不出现在慢查询中(latency可查)),查找方法和删除方法。

2)【推荐】:选择适合的数据类型。

例如:实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist,但也要注意节省内存和性能之间的平衡)

反例:

set user:1:name tomset user:1:age 19set user:1:favor football

正例:

hmset user:1 name tom age 19 favor football

3)【强制】:控制key的生命周期,redis不是垃圾桶。

建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期),不过期的数据重点关注idletime。


命令使用

1)【推荐】 O(N)命令关注N的数量

例如hgetall、lrange、smembers、zrange、sinter等并非不能使用,但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。

2)【强制】:禁用命令

禁止线上使用keys、flushall、flushdb等,通过redis的rename机制禁掉命令,或者使用scan的方式渐进式处理。

3)【推荐】合理使用select

redis的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还是单线程处理,会有干扰。

4)【推荐】使用批量操作提高效率

原生命令:例如mget、mset。非原生命令:可以使用pipeline提高效率。

但要注意控制一次批量操作的元素个数(例如500以内,实际也和元素字节数有关)。

注意两者不同:

  • 原生是原子操作,pipeline是非原子操作。

  • pipeline可以打包不同的命令,原生做不到

  • pipeline需要客户端和服务端同时支持。

5)【强制】禁止使用Redis事务

6)【建议】Redis集群版本在使用Lua上有特殊要求:

  • 所有key都应该由 KEYS 数组来传递,redis.call/pcall 里面调用的redis命令,key的位置,必须是KEYS array, 否则直接返回error,"-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS arrayrn"

  • 所有key,必须在1个slot上,否则直接返回error, "-ERR eval/evalsha command keys must in same slotrn"

7)【建议】必要情况下使用monitor命令时,要注意不要长时间使用。


客户端使用

1)【推荐】避免多个应用使用一个Redis实例

正例:不相干的业务拆分,公共数据做服务化。

2)【推荐】

使用带有连接池的数据库,可以有效控制连接,同时提高效率,标准使用方式。

3)【建议】

高并发下建议客户端添加熔断功能。

4)【强制】

必须设置访问密码

5)【建议】

根据自身业务类型,选好maxmemory-policy(最大内存淘汰策略),设置好过期时间。

默认策略是volatile-lru,即超过最大内存后,在过期键中使用lru算法进行key的剔除,保证不过期数据不被删除,但是可能会出现OOM问题。

其他策略如下:

  • allkeys-lru:根据LRU算法删除键,不管数据有没有设置超时属性,直到腾出足够空间为止。

  • allkeys-random:随机删除所有键,直到腾出足够空间为止。

  • volatile-random:随机删除过期键,直到腾出足够空间为止。

  • volatile-ttl:根据键值对象的ttl属性,删除最近将要过期数据。如果没有,回退到noeviction策略。

  • noeviction:不会剔除任何数据,拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory",此时Redis只响应读操作。



作者:fantuanjiaozi
链接:https://www.jianshu.com/p/f6bc000c4daf
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值