redis 持久化场景
RDB RDB持久化就是指的讲当前进程的数据生成快照存入到磁盘中
1. 手动触发RDB
"save"命令，但是"save"命令将会阻塞我们的Redis服务器直到RDB完成，所以真实的环境中一般不会使用该命令。
"bgsave"命令，使用该命令Redis会fork一个子进程来负责RDB持久化，完成持久化后自动结束子进程，所以阻塞只发生在fork的阶段。
2. 自动触发RDB
自动触发RDB只要在redis的conf 配置文件中配置 save相关的配置即可，如 "save m n"，这就代表在m秒内我们的数据发生了n次修改就会使用“bgsave”命令自动触发RDB
AOF
AOF持久化是以独立的日志记录每次写命令，重启Redis的时候再重新执行AOF文件中命令以达到恢复数据，所以AOF主要就是解决持久化的实时性。
1、AOF原理
1)、所有的写入的命令都会被追加到aof_buf这么一个缓冲区中
2)、接着AOF缓冲区根据对应的同步策略向磁盘做同步的操作，这里说一下同步策略，同步策略可以通过修改redis配置文件中的参数"appendfsync"进行配置。
3)、随着AOF文件变大，定期对文件进行重写操作来压缩文件
4)、Redis服务器重启的时候就会加载AOF文件用来恢复数据
---------------------
作者：nuomizhende45
来源：CSDN
原文：https://blog.csdn.net/nuomizhende45/article/details/82556829
版权声明：本文为博主原创文章，转载请附上博文链接！
三、RDB与AOF优劣势分析
1.RDB优劣势
优势：
RDB只代表某个时间点上的数据快照，所以适用于备份与全量复制，如一天进行备份一次。
Redis再加载RDB文件恢复数据远快于AOF文件
性能上考虑RDB优于AOF，因为我们保存RDB文件只需fork一次子进程进行保存操作，父进程没有对磁盘I/O
劣势：
RDB没办法做到实时的持久化数据，因为fork是重量级别的操作，频繁执行成本过高
RDB需要经常fork子进程来保存数据集到磁盘，当数据集比较大额时候，fork的过程是比较耗时的，可能会导致redis在一些毫秒级不能响应客服端请求
老版本的Redis无法兼容新版本的RDB文件
2.AOF优劣势
优势：
通过配置同步策略基本能够达到实时持久化数据，如配置为everysec，则每秒同步一次AOF文件，也就是说最多丢失一秒钟的数据，兼顾了性能与数据的安全性
AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。
劣势：
对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
与AOF相比，在恢复大的数据时候，RDB方式更快一些
---------------------
作者：nuomizhende45
来源：CSDN
原文：https://blog.csdn.net/nuomizhende45/article/details/82556829
版权声明：本文为博主原创文章，转载请附上博文链接！
基本的数据类型 https://www.jianshu.com/p/d645cebff386
String: 字符串
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象。一个键最大能存储512MB
Hash: 散列
ziplist和hashtable
Hash是一个健值对集合，是一个String类型的key与value的映射表，特别适合用于存储对象。
使用场景：存储、读取、修改用户属性
List: 列表
使用的是双向链表
排序、消息队列
Set: 集合
集合是通过整数集合和字典实现的，所以添加，删除，查找的复杂度都是O(1)
使用场景：1.共同好友、二度好友 2.利用唯一性，可以统计访问网站的所有独立 IP 3.好友推荐的时候，根据 tag 求交集，大于某个 threshold 就可以推荐
Sorted Set: 有序集合
有序集合需要同时使用跳跃表和字典来实现
使用场景：1.带有权重的元素，比如一个游戏的用户得分排行榜 2.比较复杂的数据结构，一般用到的场景不算太多
Redis和memcache的区别
网络IO模型
数据支持类型
内存管理机制
数据存储机持久化
数据一致性问题
集群管理不同
