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
