关于redis:Redis系列之初识Redis

本文将大略介绍Redis的一些个性、应用场景。

个性

1. Redis是始终基于键值对的NoSQL数据库；
2. Redis反对5种次要数据结构：string、hash、list、set、zset以及bitmaps、hyperLoglog、GEO等特化的数据结构；
3. Redis是内存数据库，因而它有足够好的读写性能；
4. Redis反对长久化，redis反对AOF和RDB两种长久化形式，确保了内存中的数据不会“失落”；
5. Redis的sentinel和复制性能保障了Redis的高可用；
6. Redis反对key维度的数据过期；

7. Redis反对公布订阅、“事务”、pipeline、Lua脚本等附加性能。

   应用场景

   Redis 适宜做什么

8. 缓存，Redis自身是内存数据库，注定有极高的读写速度和吞吐，加上数据过期性能以及欠缺的数据淘汰策略使得Redis领有与生俱来的缓存潜质。
9. 排行榜零碎，Redis提供了zset、list等简单数据结构，以及极佳的性能，能够做出工夫、数量等各种维度的排行榜零碎。
10. 计数器零碎，对于视频（音乐）网站的视频播放量、网页浏览量等高频操作，传统的关系型数据库不可能满足需要，Redis自身晓得incr、incrby等命令很好的反对了这计数性能。
11. 社交网络，Redis反对多种简单数据结构，比方一个用户有本人的粉丝，同时也会关注其他人，这些多能够应用set来存储，如果须要有序，能够应用zset来存储，这些简单的数据结构传统的关系型数据库并不能很好的反对，同时，因为社交网络网站自身访问量比拟大，传统数据在性能上也是不可能满足的。
12. 音讯队列，Redis提供了音讯队列性能，可能满足个别的音讯队列需要。

13. 分布式锁，Redis提供了SET key value [EX seconds] [PX milliseconds] [NX|XX]命令，以及Lua脚本性能，基于此可能很好的实现分布式锁性能。

    Redis 不适宜做什么

    每种产品都有本人的特定的应用领域。Redis也不是万能的。

14. Redis是内存数据库，相比磁盘类型的数据库老本要高不少，注定了Redis不能用于存储大规模的数据（土豪疏忽）。
15. Redis有足够高的性能，因而对于热数据可能很好满足需要，但如果冷数据存在Redis里未免过于节约（土豪疏忽）。
16. Redis数据存储在内存中，对于可用性要求极高，且须要永恒保留的数据不倡议放在Redis中，尽管Redis提供长久化、复制等性能保证数据落盘，但长久化、复制等也存在时间差，这段时间的数据也不是可能齐全保障不失落的。

17. Redis是单线程的，对于数据比拟大的数据的读写操作会阻塞整个数据库，因而Redis不适宜存储单个value比拟大的数据。

    深探入微

    作为最佳实际本章将会把次要的关注点放和在Redis用户相干的一些Redis基本知识，这部分常识是Redis用户须要理解并在理论应用Redis过程中要思考的。比方，如果不思考Redis单线程的个性可能会遇到申请阻塞导致性能急剧下降的问题；不理解Redis的数据结构，可能导致应用存储收缩、大value、热key的问题等等。

    单线程

    不论是单线程或者多线程都是为了晋升Redis的性能，Redis作为一个基于内存的数据库，不仅仅须要进行数据的读写操作，还要解决大量的内部的网络申请，这就不可避免的要进行屡次IO。Redis抉择了IO多路复用+单线程的架构来解决申请。简略说：

18. 应用 I/O 多路复用机制同时监听多个文件描述符的可读和可写状态。

19. 一旦受到网络申请就会在内存中疾速解决，因为绝大多数的操作都是纯内存的，所以解决的速度会十分地快。
    总之，单线程模式下，即便连贯的网络解决很多，因为有IO多路复用，仍然能够在高速的内存解决中失去疏忽，所以抉择Redis抉择单线程的架构。
    当然，Redis在6.0之后退出了多线程，因为读写网络的read/write零碎调用在Redis执行期间占用了大部分CPU工夫，如果把网络读写做成多线程的形式对性能会有很大晋升。

    数据结构

    相比其余KV数据库，Redis提供了丰盛的数据结构来满足用户的不同需要。同时，能够说Redis在内存应用是斤斤计较。为了最大可能的节约内存，Redis的每一种数据结构都领有2~3种（截止Redis6.0，后续可能会更多）的底层实现。比方，在list、hash、set、zset等简单数据结构在数据量较小的状况下都会应用ziplist这种数据结构等，因为ziplist是间断空间，不影响指针等附加耗费，在数据量较小的时候读写速度劣势也并不显著，然而能够节约不少存储，尤其是在理论应用场景种往往小数据占比拟大的状况下内存节约更为显著。
    表-1 Redis数据结构与编码

    类型	编码	决定条件	阐明
    string	int	8 个字节的带符号长整型（2^63-1）	整数编码
    string	embstr	小于等于 44 个字节的字符串，3.0.0 是 39 个字节	优化内存调配的字符串编码，和StringObject间断，一起调配一起开释，别离缩小一次内存操作
    string	raw	大于 44 个字节的字符串	动静字符串编码
    list	ziplist	value最大字节数 <= list-max-ziplist-value 且 链表长度 <= list-max-ziplist-entries
    list	linkedlist	value最大字节数 > list-max-ziplist-value 或者 链表长度 > list-max-ziplist-entries
    list	quicklist	3.2版本之后新增。废除list-max-ziplist-value 和 list-max-ziplist-value。应用新配置项：list-max-ziplist-size示意最大压缩空间或者ziplist长度，取值范畴为-5, -1默认是-2（8kb）；list-compress-depth 示意压缩深度，默认是0，不压缩	思考到链表附加空间绝对太高，应用quicklist代替ziplist 和 linklist
    hash	ziplist	value最大字节数 <= hash-max-ziplist-value 且 field个数 <= hash-max-ziplist-entries
    hash	hashtable	value最大字节数 > hash-max-ziplist-value 或者 field个数 > hash-max-ziplist-entries
    set	intset	元素必须是整型，且汇合长度<=set-max-inset-entries
    set	hashtable	汇合长度>set-max-inset-entries
    zset	ziplist	value最大字节数 <= zset-max-ziplist-value 且 链表长度 <= zset-max-ziplist-entries
    zset	skiplist	value最大字节数 > zset-max-ziplist-value 或者 链表长度 > zset-max-ziplist-entries
    stream	rax + listpack		listpack 是 ziplist 优化版本，目前（Redis 5.0.0）只应用在 stream 中

    表1 Redis数据结构外部实现

    长久化

    Redis反对RDB和AOF两种长久化机制。长久化性能可能无效的防止Redis服务异样退出导致数据齐全失落的状况。当重启Redis服务会主动加载长久化文件即可实现数据恢复。

    RDB

    RDB长久化是将以后Redis过程数据快照保留到硬盘的过程，触发RDB生成有两种形式：手动触发和主动触发。

20. 手动触发：对应save和bgsave两个命令，其中save是阻塞的，已逐渐淘汰。
21. 主动触发：主动触发大略有四种场景
22. 1. 应用save相干配置，如save m n,示意m秒内数据产生了n次批改，则字段执行bgsave;
23. 2. 从节点执行全量复制操作，主节点字主动执行bgsave生成RDB文件并发送给从节点。
24. 3. 执行 debug reload命令从新加载Redis，会触发save操作（留神，这里是save）。
25. 4. 默认执行shutdown命令，如果没有开启AOF长久化也会主动执行bgsave。
       RDB是一个紧凑压缩的二进制文件（Redis默认应用LZF压缩算法对RDB进行压缩），是Redis在某一时刻的数据快照，有如下长处：
26. 适宜全量复制、和冷备。
27. Redis加载RDB复原数据速度远快于AOF形式。
    同样，RDB长久化形式也有诸多毛病：
28. RDB长久化形式无奈做到实时长久化。执行bgsave都执行fork操作创立子过程，属于重量级操作，老本较高。

29. RDB格局不兼容。Redis倒退过程种有多个格局RDB版本，存在老版本Redis不兼容新格局RDB文件的问题。

    AOF

    AOF（append only file）长久化是以日志的形式记录每次写操作命令。重启Redis时，会通过从新执行这些命令的形式来复原数据。AOF长久化有三点须要阐明：

30. AOF间接应用文本协定格局。
31. AOF长久化首先会将写操作命令写入aof_buf，而后通过提供的不同策略（always、everysec、no）来将aof_buf中的数据同步到磁盘上。

32. AOF反对从新机制以压缩文件体积，AOF文件从新逻辑是将Redis过程内的数据转换成写操作命令同步到AOF文件中。

    复制

    为了解决分布式系统中服务单点问题，Redis引入了复制机制，实现主从架构以满足容灾和负载平衡等问题。复制实质上是数据同步的过程，Redis反对两种数据同步形式：

33. 全量同步，Redis最早只反对全量同步，全量同步顾名思义，会将主节点的所有数据一次性的同步给从节点，这样会导致主从之间的带宽耗费累赘减轻。

34. 局部同步，为了解决全量复制存在的问题，Redis提供了局部复制的机制，当主从断开连接，再次建设连贯，只须要同步断开连接期间的数据。
    当主节点把以后数据同步给从节点过后，就将复制流程建设起来了，后续主节点将会继续的把写操作命令发送给从节点，从而保障主从节点数据一致性。

    reference

Redis官网

Redis开发与运维

How Twitter Uses Redis To Scale - 105TB RAM, 39MM QPS, 10,000+ Instances

Latency Numbers Every Programmer Should Know