小样！这都不知道？还干程序猿！😁开个玩笑~ 皮一下 很开心🙃🙃
redis确实是单线程。那么为什么这么快呢？
1.所有数据都存储在内存中，所有的运算级别都是内存级别的运算。所以在使用是需要特别注意那些时间复杂度为O(n)的操作。
2.阻塞IO和非阻塞IO:当我们用套接字读写方法时，默认他们是阻塞的。
阻塞IO：调用read方法要传递一个参数n，读取多少个字节后再返回，如果没有线程就会卡在那里。直到有新的数据或者连接关闭。而write方法一般不会阻塞，除非缓冲区已经满了，write就会阻塞。
非阻塞IO:非阻塞IO在套接字读取对象的时候加了一个参数Non_Blocking,当打开这个选项的时候，read方法就不会阻塞，能读多少就会读取到多少！能写多少写多少。
有了非阻塞IO意味着线程就可以去干别的事情了。读写瞬间完成！
3.事件轮询(多路复用)
事件轮询是为了解决非阻塞IO的读写数据问题。线程来读取数据，读取到一部分就返回了，那么线程如何知道何时应该继续下去，当数据来临时，线程如何得到通知。事件轮询就是解决这个问题！最简单的事件轮询API为Select函数，操作系统提供为用户程序的API接口，参数有:read_fds&write_fds timeOut参数。如果没有任何时间的到来，线程处于阻塞状态，一旦有任何事件的到来，就立即执行返回，timeOut时间过了，也没有任何时间的话也立即返回。当拿到时间，挨个处理，处理完了就继续轮询。
Select系统同时调用多个通道描述符的读写事件，我们称为多路复用，多路复用的API不仅仅有Select事件 还有epoll和kqueue,相比而言，epoll和kqueue的性能会好一点。事件轮询API就是java语言里面的NIO技术。
redis如果突然宕机，怎么办，redis的数据全部都在内存里，如果宕机 数据就会丢失，redis提供了两种持久化方式。
redis的持久化
redis提供了两种持久化方式，1.快照 2.aof日志。
快照是一次备份所有数据，Aof是连续增量备份，
快照是存储内存数据的二进制序列化形式，aof是修改内存指令的文本。
redis在请求客户端的请求时，一边还要生成快照，然而生成快照必须要进行IO操作，文件操作是不能进行多路复用的。IO操作是十分消耗时间的操作，文件IO甚至会拖垮整个redis的性能。一边接受客户端请求，一边生成快照。
那么怎么办呢？
redis提供多进程来实现快照的持久化。
redis持久化是调用操作系统的API glibc函数的fork产生一个子进程，生成的子进程处理快照的生成，父进程处理客户端的请求，子进程做数据的持久化，他不会修改数据，所以它只是对数据结构的遍历，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。
子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。
AOF持久化
AOF存储的是对内存数据的顺序指令序列，AOF指令只会记录对内存数据进行修改的指令记录，客户端收到指令，先校验参数，然后将指令存储在Aof文件中，然后在执行，这样如果突然发生宕机，那么redis也会恢复到宕机之前的状态。
Redis的管道
当客户端对redis进行一次操作时，客户端发送给请求到服务器，服务器将结果返回给客户端，这样包含网络的数据包来回的时间。
如果多条指令，那么将会花费更多的时间
客户端是经历了写-读-写-读四个操作才完整地执行了两条指令。
现在如果我们调整读写顺序，改成写—写-读-读，这两个指令同样可以正常完成。
两个连续的写操作和两个连续的读操作总共只会花费一次网络来回，
就好比连续的 write 操作合并了，连续的 read 操作也合并了一样。
redis的管道只是改变了指令的执行顺序，服务器端并没有任何区别对待，还是接受到一条执行一条
redis的事务
redis事务的命令分别是 multi/exec/discard。
multi指示事务的开始。
exec表示事务的执行。
discard表示事务的丢失。
事务的原子性是指要么事务全部成功，要么全部失败。
> multi
OK
> set books iamastring
QUEUED
> incr books
QUEUED
> set poorman iamdesperate
QUEUED
> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
> get books
"iamastring"
> get poorman
"iamdesperate
在上述的例子中，我们不能对一个字符串进行数学运算。事务在遇到失败的指令后，还能继续向后执行。
所以redis的事务不具备原子性，而是简简单单的满足了隔离性。
discard(丢弃):用于丢弃redis指令队列中所有的指令，在exec执行前，
watch命令：Redis 存储了我们的账户余额数据，它是一个整数。现在有两个并发的客户端要对账户余额进行修改操作，这个修改不是一个简单的 incrby 指令，而是要对余额乘以一个倍数。
此时就会出现一个并发操作，因为有多个客户端会进行并发操作，我们可以用分布式锁来解决这个问题，当然分布式锁是一个悲观锁。当然 我们也可以用乐观锁来解决。
Redis提供了watch命令，watch会在事务开始之前，会盯着变量，看他是否有修改，Redis会检查关键变量自watch之后，是否有修改，如果有修改，exec指令就会返回Null
172.31.123.211:9379> set books 2
OK
172.31.123.211:9379> WATCH books
OK
172.31.123.211:9379> incr books
(integer) 3
172.31.123.211:9379> MULTI
OK
172.31.123.211:9379> incr books
QUEUED
172.31.123.211:9379> exec ##执行失败
(nil)
使用watch的注意事项：redis禁止在Multi和exec之间使用，必须在multi事务开始之前顶住关键字。
为什么 Redis 的事务不能支持回滚？
Redis的命令只会因错误的语法而执行失败。或者使用了错误的类型在上面，其从实用性的角度讲，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。
鉴于 没有任何机制能解决这种程序猿自己造成的错误,redis提供了无回滚的方式。
Redis的消息队列Pub/Sub
Redis的发布订阅，不是基于5中基础的数据结构，而是单独是使用了一个模块PublisherSubscriber 即发布/订阅者模型。
###redis 订阅
172.31.123.211:9379> SUBSCRIBE code.img code.text code.blog
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "code.img"
3) (integer) 1
1) "subscribe"
2) "code.text"
3) (integer) 2
1) "subscribe"
2) "code.blog"
3) (integer) 3
###redis发布
> PUBLISH code.img www.baidu.com
(integer) 1
> PUBLISH code.text "你好，?欢迎"
(integer) 1
> publish code.blog "ss"
(integer) 1
Redis PubSub 的生产者和消费者是不同的连接，也就是上面这个例子实际上使用了两个 Redis 的连接。这是必须的，因为 Redis 不允许连接在 subscribe 等待消息时还要进行其它的操作。
redis多模式订阅
在上述中我们案例中我们订阅了code.img code.text code.blog，订阅是基于名称的，消费者必须明确的制定主题的名称。如果我们想订阅多个消息，那就SUBSCRIBE，多个名称。
为了简化订阅的繁琐，redis 提供了模式订阅功能Pattern Subscribe。
>psubscribe code.* //用模式匹配一次订阅多个主题，主题以code开头，
redis的pub/sub的缺点:pub/sub的消息是不会持久化的，那么说吗redis的停机重启，或者宕机，那么所有的消息都会被丢掉
redis5.0版本新增了stream结构，这个功能增加了redis带来的持久化消息队列。
Redis的内存回收机制：
Redis 并不总是可以将空闲内存立即归还给操作系统，举个栗子。
如果当前 Redis 内存有 10G，当你删除了 1GB 的 key 后，再去观察内存，你会发现内存变化不会太大。原因是操作系统回收内存是以页为单位，如果这个页上只要有一个 key 还在使用，那么它就不能被回收。Redis 虽然删除了 1GB 的 key，但是这些 key 分散到了很多页面中，每个页面都还有其它 key 存在，这就导致了内存不会立即被回收。
不过当你执行了flushDb,然后观察内存会被立即回收，原因则是所有的key都被干掉了，大部分的页都干净了，操作系统会立即回收，
Redis的内存分配算法:
redis使用了jemallo 算法，给redis分配内存。通过info memory指令可以看到 Redis 的mem_allocator使用了 jemalloc。
>info memory
used_memory:2125232
used_memory_human:2.03M
used_memory_rss:12144640
used_memory_rss_human:11.58M
used_memory_peak:2187520
used_memory_peak_human:2.09M
used_memory_peak_perc:97.15%
mem_allocator:jemalloc-4.0.3
Redis主从同步
Redis同步支持主从同步，从从同步，
增量同步：
redis同步的是指令流，主节点会将那些对自己状态有修改的指令记录在本地Buffer中，然后异步的将buffer中的指令同步到从节点，一边同步状态，一边反馈同步到哪里了。
本地buffer的数据结构是一个定长的循环数组，当满了之后，会覆盖开头的数据。如果因为网络不好，主从节点无法同步，当网络恢复后，开头节点的数据以及被覆盖，那么从节点无法直接通过指令流来进行同步。那么就要进行快照同步。
快照同步：
需要在主库上进行一次bgsave操作，将当前存储的数据全部快照到磁盘文件中，然后将快照文件全部传送到从节点。。从节点将快照文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。
本地buffer太小 会造成快照的死循环，导致指令集被覆盖，然后再次发其快照同步，那么就会陷入死循环。所以务必配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。
