Redis6
quick way to know Redis6
原子化
redis 是 IO 多路复用模型，即一个线程来处理多个 TCP 连接，这样的好处就是，即使客户端并发请求，也得排队处理，一定程度上解决了多线程模型带的并发问题，所以 redis 是并发安全的？从 redis 本身的架构模式来说，并发是安全的，不存在同时执行两个客户端的命令
所谓原子操作是指不会被线程调度机制打断的操作.
这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。
（1）在单线程中， 能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。
（2）在多线程中，不能被其它进程（线程）打断的操作就叫原子操作。
Redis 单命令的原子性主要得益于 Redis 的单线程。
多样的数据结构存储持久化数据
List 实现按自然时间排序的数据最新(N 个数据)
zset 有序集合(排行榜， Top N)
Expire 过期(时效性的数据，比如手机验证码)
原子性， 自增方法 INCR, DECR (计数器，秒杀)
set 集合(去除大量数据中的重复数据)
无序集合。它底层其实是一个 value 为 null 的 hash 表，所以添加，删除，查找的复杂度都是 O(1)
Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象
key – 序列化的 value 对象
用户 id 姓名数据 . 年龄数据 . 生日数据
每次修改用户的某个属性需要，要先反序列化改好后再序列号回去，开销大
key – value 对象
用户 id+ 姓名标签 姓名数据
用户 id+ 年龄标签 年龄数据
用户 id+ 生日标签 生日数据
用户 ID 数据冗余
用 Hash 方法
key – Hash . field value
. 姓名标签 姓名数据
用户 id 年龄标签 年龄数据
. 生日标签 生日数据
通过 Key + field 就可以操作对应的属性数据，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题
list 集合(构建队列)
List 的数据结构为快速链表 quickList。
首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是 ziplist，也即是压缩列表。
它将所有的元素紧挨着一起存储，分配的是一块连续的内存。
当数据量比较多的时候才会改成 quicklist。
因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是 int 类型的数据，结构上还需要两个额外的指针 prev 和 next。
ziplist <–>ziplist <–>ziplist <–>ziplist <–>ziplist
