[原]Redis使用场景及使用经验

   Redis is an open source (BSD licensed), in-memory data structure store!

  欢迎转载,转载请注明出处

  刚刚结束一个游戏类的活动项目,由于预估的参与人数较多,产生的数据量会很大,为了达到更好的游戏效果,所以决定抛弃之前Mysql为主Redis为辅的存储方式,而是Redis为主,Mysql为辅(负责落地一些重要的用户数据),期间收货了很多。

  一、Redis中的数据结构以及常见的使用场景

  常用的Redis数据结构:

  • String  # 键值对
  • List      # 列表
  • Hash    # 哈希
  • Set      # 集合
  • Sorted Set  # 有序集合

  每种数据结构都有其合适的使用场景,但是谨记 不要手里握着锤子,看什么都是钉子 。另外当存储的数据量较大时,要注意每个操作命令的时间复杂度

1、String

常用命令:  set,get,decr,incr,mget 等。

 应用场景:String类型是最简单也是最常用的redis数据结构,key/value格式完全可以取代Memcached作为缓存服务器,单机的测试效果显示redis的效果更好。

  set、get:最简单的数据缓存

  mset、mget: 批量操作,把数据统一传回客户端,节省网络io时间

  decr、incr:计数器

  append命令:可以作为时间序列,配合getrange、setrange,对字符串进行操作,目前redis还木有修剪操作

  setbit、getbit: 省内存的好命令,可以作为简单的布尔过滤器来判断用户是否执行过某些操作

2、List

常用命令:lpush,rpush,lpop,rpop,lrange等。

应用场景:List的应用场景很多,应用也相当广泛

  lpush、lpop:天然的队列操作,轻松实现队列任务,Celery的存储容器我们选的就是redis

  lpush、ltrim: 显示最新的数据,很好用的!比如:游戏上方的跑马灯,就可以用这两个命令来存储最新的50条记录

  还有一些其他操作:堵塞式的blpop, lrange(O(n)), lindex(O(n)),linsert(O(n)), llen(O(1)),lrem(O(n)),lset(O(n))

3、Hash

常用命令:hget,hset,hgetall 等。

应用场景:以前在memcached中如果保存一个大的数据,经常用序列化之后保存,取出来反序列化后使用,即不经济实惠,在高并发下还存在原子性问题,在redis中, 用哈希实现,so easy啦!

  hget、hset: 实现一个key对应一个数据集集合,数据集集合里包含多个单独的key/value键值对,操作依然是原子性的

  hmget、hmset、hgetall: 批量操作,节省网络io时间哦

  hincrby: 对哈希里域值,进行原子性的加1

  其他操作: hdel(O(n))、 hkeys(O(n))、hexits(O(1))、hvals(O(n))、hscan(O(n))

4、Set

常用命令:
sadd,spop,smembers,sunion 等。

应用场景:set与list类似,只是set是经过去重的集合,需要一个不重复的数据结构,就要考虑考虑set

  sadd: 存储一个不重复数据的数据集合

  sunion、sdiff、sinter: 进行集合处理,例如微博中,将一个用户关注的所有人放入set集合中,通过并集、交集、差集操作,实现`共同关注`、`共同喜好`、`二度好友`等功能

  其他操作:srem、spop、scard、sismember、smove、srandmember

 

5、Sorted Set

常用命令:
zadd,zrange,zrem,zcard等

应用场景:set是无序的,而Sorted set 顾名思义,它是有序的,由key、member和score组成,需要一个有序而且不重复的数据结构,就要考虑考虑sorted set

  zadd:存储一个按照score排序的数据集合,添加时自动排序,例如:优先队列,普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

  zrange、zrangebyscore等等:按照score顺序获取数据集,例如:微博的时间流信息,把发布时间作为score。还可以用来处理过期数据。后台任务使用ZRANGE…SCORES查询排序集合,取出最新的10个项目。如果发现unix时间已经过期,则在数据库中删除条目。

  zrank: 排行榜功能,score作为投票结果

  其他操作:zcard、zcount、zincrby、zrem、zscore,以及set的集合操作

 

Redis命令参考中文版  英文版

 

二、Redis使用经验

  先贴出来国内外三家重度使用redis的公司的使用经验,猛戳这里

  一、Redis部署

  本司由于平时的数据量不大,一直使用的三台redis实例,一主两从,三个哨兵sentinel分别监视三个redis实例作为高可用性的保障,这次活动的预估参与人数以及请求并发量很大,所以为了保证高可用性,在部署时做了一下变更方案:

  • 更换SSD硬盘,并增加内存至128G (简单粗暴,效果显著)
  • 双机房两组Redis实例,一组对外服务,另一组作为热备份,不提供服务并定时备份,服务中的实例出现故障,立即切换备份实例为服务实例
  • OS参数:vm.over_commit_memory配置  默认为0,改为1

   Redis的快照、AOF文件重写、主备同步等功 能都依赖于fork系统调用,以快照(bgsave/save)为例,Redis会fork一个子进程出来,由子进程来将当前的数据存储为一个RDB文件。

    vm.over_commit_memory会影响到内存分配,其值可以是:

      • 0: 表示内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存,内存申请允许;否则,内存申请失败,并把错误返回给应用进程。
      • 1: 表示内核允许分配所有的物理内存,而不管当前的内存状态如何。
      • 2: 表示内核允许分配超过所有物理内存和交换空间总和的内存。

    vm.over_commit_memory默认值为0,在该配置下,当Redis执行fork时,服务器可用内存必须大于Redis当前使用内存2倍时,fork才能成功。

    而实际上Linux在fork时,使用COW(copy-on-write)技术,子进程共享父进程的地址空间,只有共享地址空间发生改变时,才需要复制改变部分的内存;大部分情况下,fork子进程并不会导致内存使用翻倍,为fork预留一倍的内存是完全没有必要的,Redis启动时也会建议使用者将vm.over_commit_memory设置为1。

  • OS参数:vm.swapiness设置为0

   Redis是全内存的KV数据库,当服务器内存不足时,OS的swap机制可能会把Redis的部分数据换出到磁盘,访问Redis时,如果被访问的数据刚好不在内存里,则会产生缺页中断,从磁盘读取数据,这种行为会极大的影响Redis服务的性能。

 

     为保证Redis服务的性能,应该尽量避免发生swap,将vm.swapiness设置为0(该参数可在0-100之间取值,默认为60,越高使用swap空间的可能性越大)。

  • OS参数:transparent hugepage

   Linux-2.6.38内核引入透明大内存页的支持,这个参数对Redis有利有弊。

    • 好处在于:大内存页意味着更小的页表,fork的开销会降低不少
    • 坏处在于:大内存页,意味着页被修改的几率更大,COW时拷贝成本更高

    仅供参考,目前未使用该特性。

  我的Redis的配置文件, 内容如下:(配置文件详细介绍请点这里

daemonize yes
pidfile "./redis.pid"
port 6379
timeout 0
tcp-keepalive 60
loglevel notice
logfile "./redis.log"
databases 16
save 900 1
save 300 10
save 60 10000
tcp-backlog 511
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "redis.rdb"
dir "./redis"
slave-serve-stale-data yes
slave-read-only yes
repl-disable-tcp-nodelay no
slave-priority 100
maxclients 20000
maxmemory 60gb
maxmemory-policy noeviction
appendonly no  # 可以忍受一小段时间内的数据丢失,所以关闭了aof持久化
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
hash-max-ziplist-entries 512
hash-max-ziplist-value 512
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
# Generated by CONFIG REWRITE  # 由sentinel自动故障转移生成的
#slaveof 10.181.60.113 6382
slaveof 10.181.254.157 6379

 

 

二、压测过程中遇到的问题及解决方案

   保证服务可靠性,对主要单接口压测,以及复合场景下的多接口压测,观察接口的响应时间以及服务的吞吐量,还有对突发情况下的Redis机器故障转移,如机房断电,主redis挂掉等情况。

   问题:

    • 业务逻辑复杂,频繁访问redis,接口响应时间有提升空间
    • 线上要清空一个db的数据,执行flushdb后,数据依然存在(原因:该db内数据量大,清空操作超过3秒,sentinel发现3秒内,master无正确响应,就将slave拉起作为master,从进行同步,陷入循环。。。)
    • Redis目前的主从同步机制,主从连接断开后,如果从落后的数据超过1M(可配置,越大内存开销越大),则需要重新全量同步一次,一次全量同步会产生极大的内存、磁盘、CPU及网络开销。主从全量同步过程中,如果写入比较多,主从同步缓冲区就会不断累积写入的数据,当累积的数据超出限制时,主从连接就会断开,此时从又必须重新向主请求全量同步,如此往复… 导致同步一直不能成功
    • 数据量很大时,redis的bgsave操作,虽然是子进程操作,但是也会阻塞redis,导致超时

   方案:

    • mysql读写分离,并分库,分表
    • redis数据分片,把重要、不重要的数据分开到两个redis实例分别存放
    • 代码中减少redis网络IO请求,多用mget、hmget、pipeline等一次性读多条数据命令
    • 代码中考虑用更合适的redis数据结构以及时间复杂度少的命令。 Instagram公司优化Redis使用内存案例
    • 设计数据结构时,尽量减小单个key的value大小,如果单例redis中数据量过大,故障恢复或者同步过程会很慢。单例redis最大使用内存一定要小于机器最大内存的一半。
    • 清空一个数据量很大的db前,先调大sentinel的自动故障转移时间,清空后再设置回来。
    • 适当扩大client-output-buffer-limit slave 256mb 64mb 60 的配置值
    • 一定要设置限流,运维层限制一道,代码层限制一道,保证整体服务器不宕机。

  备选方案:

    • 复杂的redis操作,可以考虑用短小的lua脚本执行,用eval和evalsha命令执行(优点:充分利用CPU,减少网络IO时间。缺点:不方便维护,要保证脚本不阻塞)
    • 传统的一主多从A–B&C 当把B拉起为master时,C仍然会清空自身数据来同步B,psync的断点续传对此无作用,所以考虑改为变为A–B–C同步结构
    • redis集群(时间紧,考虑但是暂时不会采用)
    • 采用主不开持久化,从开持久化,不会出现数据量大,bgsave导致的连接超时情况(缺点:A–B&C模式下,A故障并自动拉起或者由sentinel把B被拉起为master,中间的心跳检测过程中,还是会有一个间隔,导致从同步主,发现A没有数据,会清空自身的数据,很危险!)

 

    原文作者:redis
    原文地址: https://www.cnblogs.com/titanjf/p/redis.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞