transactions

redis的事务并不能回滚,即使执行失败了,后面的命令一样会执行
exec命令触发前面被queue的命令原子执行

最后:transaction最终将被scripts替代,因为它们提供了原子性,原子性可以理解为redis单线程执行命令自带的原子性,并且更快,script命令仍然没有rollback功能
redis官方解释:redis只有在错误的program时才会出现,你应该修改你的bug,而不是rollback

pipeline

redis使用client-server模型,也叫Request/Response protocol
因此一个请求完成需要经历的步骤:

  • client发送请求给server,从socket读取reponse,通常是阻塞的
  • server执行命令并发送reponse给client

RTT(Round Trip Time):包从client发送到server,再从server返回到client的时间
这也意味着,如果RTT为250毫秒,则不管server的性能有多牛逼,client端感知道的ops为:4/s

恰逢你想一次执行多个命令,如果通过普通的串行调用,这个时间耗费就相当高了

此时,你就可以使用pipelining了(注意server端分片的情况,key不同请慎重),它能有效减少RTT
还有需要注意的是:server端将把多个命令的结果放到一个queue里面,这是会产生额外内存消耗的,如果有10k个操作使用pipeline执行,则server端就需要相应结果集对应的内存。

pipeline还减少了read() write()操作的性能损耗,如果请求被挨个发送到server,则相比pipeline,server和client调用read()和write()的次数增加了,这是一个系统方法调用,意味着从用户态到内核态的切换,上下文切换是一个速度上的较大的损害

和script对比,性能可能略低,原因是多个命令,每次执行完上一个命令后,需要将reply放置,才能执行下一个命令,script则没有这个问题。
pipeline也可以和script一起使用,如多次执行eval或evalSha命令

rdb

优点:

  • 一个压缩文件,对应了server某个时间点的数据
  • 容灾恢复,可以传到远程中心
  • 除了bgsave fork一个子进程外,其他的备份操作由子进程完成
  • 大数据量时,使用rdb重启redis,速度快于aof
    缺点
  • 不够实时,如果1小时备份一次,或10000次备份一次,则丢失的数据量可能比较大
  • 大数据量时,fork一个子进程也是相当耗时的,这段时间server将不能响应client的请求

解决办法 控制单个redis的大小,配合aof

过程

  • fork child process
  • child 生成临时dump.rdb
  • child用新的rdb文件去替换老rdb

aof

优点:

  • 可以配置隔多久写一次追加日志,默认为1s,这样丢失的数据就比较少了
  • 它是一个append only file,不怕断电,有机制可以修改写了一半的命令
  • 当aof文件变得很大时,redis会自动BGREWRITEAOF重写aof文件,通过后台重新生成一个当前数据集的文件,生成完成后替换现有的aof文件
  • 容易解析格式,甚至错误的执行了flushAll命令,只要文件没有重写,就可以删除flushAll命令,利用aof文件重启redis来恢复

缺点

  • 通常比rdb大
  • 在每个命令都fsync到文件的模式,性能很差
  • 之前遭遇过一些特殊的bug,仅在某个命令下出现,这一点上,它没有rdb那么健壮

rewrite过程

  • fork child process
  • child向临时文件写new AOF
  • parent把新的更改放在内存缓冲区中,此时老的aof追加过程依旧继续,保证数据安全
  • child rewrite结束后,parent获得信号,将内存缓冲区中的变化追加到child生成的aof文件的尾部
  • 原子的将aof文件的名字改成新的文件名,然后往新的文件append

该怎么使用备份

  • 如果允许数据丢失一段时间,可以直接使用rdb
  • 长久计划中,将统一rdb和aof
  • 用定时任务将rdb文件copy到其他物理机,删除很久以前的rdb
posted on 2018-11-11 20:05  j.liu windliu  阅读(103)  评论(0编辑  收藏  举报