缝合怪&redis

缝合怪&redis

Redis 优势
性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
常用网站
https://www.redis.net.cn/tutorial/3501.html
http://www.redis.cn

Redis协议：RESP

个人感觉这个是非常轻量级的,没有什么多余的数据通信速度快
RESP有五种最小的单元类型，单元结束时统一加上回车换行符号\r\n。

单行字符串 以 + 符号开头。
多行字符串 以 $ 符号开头，后跟字符串长度。
整数值 以 : 符号开头，后跟整数的字符串形式。
错误消息 以 - 符号开头。
数组 以 * 号开头，后跟数组的长度。

如：
单行字符串

+hello world\r\n

错误消息

-WRONGTYPE Operation against a key holding the wrong kind of value\r\n

整数值

:1024\r\n

多行字符串

$11\r\nhello world\r\n

数组[1,2,3]

*3\r\n:1\r\n:2\r\n:3\r\n
//实际效果
*3
:1
:2
:3

客户端->服务端
客户端向服务器发送的指令只有一种格式，多行字符串数组。
比如一个简单的 set 指令set author codehole会被序列化成下面的字符串。

*3\r\n$3\r\nset\r\n$6\r\nauthor\r\n$8\r\ncodehole\r\n
//实际效果
*3
$3
set
$6
author
$8
codehole

其实就是字符串拼接,完全可以拼接字符串的形式发送给redis,完成curd.

10个常见的Redis面试“刁难”问题

Redis有哪些数据结构？

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

如果你是Redis中高级用户，还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。

如果你说还玩过Redis Module，像BloomFilter，RedisSearch，Redis-ML，面试官得眼睛就开始发亮了。

使用过Redis分布式锁么，它是什么回事？

先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。

这时候对方会告诉你说你回答得不错，然后接着问如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？

这时候你要给予惊讶的反馈：唉，是喔，这个锁就永远得不到释放了。紧接着你需要抓一抓自己得脑袋，故作思考片刻，好像接下来的结果是你主动思考出来的，然后回答：我记得set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！对方这时会显露笑容，心里开始默念：摁，这小子还不错。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。

对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

使用过Redis做异步队列么，你是怎么用的？

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

如果对方追问可不可以不用sleep呢？list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。

如果对方追问能不能生产一次消费多次呢？使用pub/sub主题订阅者模式，可以实现1:N的消息队列。

如果对方追问pub/sub有什么缺点？在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。

如果对方追问redis如何实现延时队列？我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话，怎么问的这么详细。但是你很克制，然后神态自若的回答道：使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。

到这里，面试官暗地里已经对你竖起了大拇指。但是他不知道的是此刻你却竖起了中指，在椅子背后。

如果有大量的key需要设置同一时间过期，一般需要注意什么？

如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。

Redis如何做持久化的？

bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，优先使用aof来恢复内存的状态，如果没有aof日志，就会使用rdb文件来恢复。

如果再问aof文件过大恢复时间过长怎么办？你告诉面试官，Redis会定期做aof重写，压缩aof文件日志大小。如果面试官不够满意，再拿出杀手锏答案，Redis4.0之后有了混合持久化的功能，将bgsave的全量和aof的增量做了融合处理，这样既保证了恢复的效率又兼顾了数据的安全性。这个功能甚至很多面试官都不知道，他们肯定会对你刮目相看。

如果对方追问那如果突然机器掉电会怎样？

取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

Pipeline有什么好处，为什么要用pipeline？

可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。

Redis的同步机制了解么？

Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

是否使用过Redis集群，集群的原理是什么？

Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。

=================================================================================

一、为什么使用

解决应用服务器的cpu和内存压力

减少io的读操作，减轻io的压力

关系型数据库的扩展性不强，难以改变表结构

二、优点：

nosql数据库没有关联关系，数据结构简单，拓展表比较容易

nosql读取速度快，对较大数据处理快

三、适用场景：

数据高并发的读写

海量数据的读写

对扩展性要求高的数据

四、不适场景：

需要事务支持（非关系型数据库）

基于sql结构化查询储存，关系复杂

五、Redis结构：

Redis是一个开源的key—value型数据库，支持string、list、set、zset(有序集合)和hash类型数据。对这些数据的操作都是原子性的，redus为了保证效率会定期持久化数据。

六、使用场景：

配合关系型数据库做高速缓存

缓存高频次访问的数据，降低数据库io

分布式架构，做session共享

可以持久化特定数据。

利用zset类型可以存储排行榜

利用list的自然时间排序存储最新n个数据

七、Linux下redis：

redis目录：usr/local/bin

linux下redis常用命令：

redis-benchmark：性能测试工具

redis-server：启动redis服务器

redis-cli：启动redis客户端，操作入口

八、Redis基础知识

端口：6379

默认16个数据库，下标从0开始

单线程：redis是单线程+io多路复用：检查文件描述的就绪状态

redis数据类型：String set list hash zset

Memchached：多线程+锁

九、Redis命令：

key操作

keys *查看当前库所有的键

exists 判断是否存在key

del 删除某个键

expire 设置键过期时间 单位是s秒

ttl 查看还有多少秒过期 -1表示用不过期 -2表示已经过期

move 把键移到另一个库下

dbsize查看数据库key的数量

flushdb清空当前库

flushall通杀所有库

String类型：String是二进制安全的，可以包含任何数据源，最大512m

get 查看对应的键值

set 添加键值对

append 将给定的value 追加到原值的末尾

strlen < key >获取值得长度

setnx 当key 不存在的时候设置key值

incr 将key中储存的数字加1，如果为空，则值为1

decr 将key中储存的数字减1，如果为空，则值为-1

incrby/decrby <步长>将key中的数字增减

String批量处理：

mset 同时设置多个键值对

mget <key 2>同时获得多个值

msetnx 当给定的key都不存在

getrange 类似sunstring

setrange 类似sunstring覆盖原始值

setex <过期时间> 设置键值的同时，给定过期时间

getset 以旧换新，设置了新的值同时得到旧值

List：链表

1、特点：

单键多值

Redis列表是简单的字符串列表，从左或者从右插入

底层是双向链表，对两端的操作性能很高，通过下标查询性能很低

lpush/rpush …从左或从右插入多个值

lpop/rpop 从左边或右边吐出一个值，值光键亡

rpoplpush 从key1 右边吐出一个值到key2的左边

lrange 按照索引下标获取元素 从左到右

lindex 按照索引下标获取元素 从左到右

llen 获取列表长度获取列表长度

linsert before 在key中value前插入newvalue

Set：类似list的无序集合，保证列表中不会有重复数据，底层是一个value为null的hash表

sadd 将多个元素加入到key中，重复值忽略

smembers 取出该集合的所有值

sismember 判断集合key中是否有该value值 有就1 没有0

scard 返回该集合的元素个数

srem 删除集合中的某个元素

spop 随机吐出该集合一个值

srandmember 随机从集合中取出n个值，不会从集合中删除

smove 将key1中的value 移动到key2 中

sinter 返回两个集合的交集元素

sunion 返回两个集合的并集

hash：键值对集合，类似map<String,Object>

hset 给key 集合中的file 键赋值value

hget 从key1 集合file取出value

hmset 批量设置hash的值

hexists 查看key中的field 是否存在

hkeys 列出key中所有的filed

hvals 列出该hash集合中所有的value

zset：与set集合非常相似，每个成员都关联了score，可以用来排序

zadd将一个或多个元素以及score加入zset

zrange withscore返回下标在区间内的集合，带有score

zrangebyscore [withscore] [limit offset count]返回key中 score介于min和max中的成员，升序排列

zrevrangerbyscore [withscore] [limit offset count]降序

zincrby 在key集合中的value上增加increment

zrem 删除key集合下的指定元素

zcount 统计 区间内的元素个数

zcord 获取集合中的元素个数

zrank 查询value在key中的排名，从0开始

十一、Redis事务：

输入multi，输入的命令都会依次进入到队列中，但不会执行，直到输入exec，redis会将之前命令队列中的命令依次执行，通过discard可以放弃组队。

主要作用：序列化操作，串联多个命令防止别的命令插队

悲观锁：每次拿到数据的时候都会上锁，或者等待别人处理完再去拿锁，传统的关系型数据库里边很多用到了这种锁机制，比如行锁、表锁、读锁、写锁

乐观锁：每次拿数据的时候总认为别人不会修改数据，所以不会上锁。但是更新的时候回去判断别人有没有更改数据，使用版本号机制。乐观锁适用于多读的应用类型，可以提高吞吐量。

Redis使用乐观锁：redis就是利用check-and-set机制实现事务

三大特性：

单独的隔离操作：事务中的所有命令都会序列化，按顺序执行。不会被其他客户端打断

没有隔离级别概念：队列中的命令没有提交之前不会被执行，事务外不能查看事务内的更新

不能保证原子性：跳过错误，依旧执行，没有回滚

十二、Redis订阅/发布：

是进程中的一种消息通信模式，发送者pub发送消息，订阅者sub接收消息 剩下的略。。。

十三、Redis主从复制：

是什么：主从复制就是主机数据更新后根据配置和策略，自动同步到备份机的master/slaver机制，master写为主，slave读为主

用处：

读写分离，性能拓展。

容灾快速恢复

配置服务器（配从不配主）：

拷贝多个redis.conf文件

开启daemonize yes

Pid文件名字

指定端口

Log文件名字

Dump.rdb名字

Appendonly 关掉或者换名字

十四、Jedis：

所需jar包：

common-pool-1.6jar包

jedis-2.1

获取jedis对象：Jedis jedis = new Jedis（“ip” ，端口号）；

十五、集群分布：

实现对redis的水平拓展，启动n’的redis节点，将整个数据分布在这n个节点中

配置conf文件：

拷贝多个redis.conf文件

开启daemonize yes

Pid文件名字

指定端口

Log文件名字

Dump.rdb名字

Appendonly 关掉或者换名字

配置cluster文件：

cluster-enable yes 打开集群模式

cluster-config-file xxx.conf 设置生成的节点配置文件名

cluster-node-timeout 15000设置节点失联时间，超多该时间（毫秒），集群自动进入主从切换

====================================================================================

Redis过期键的删除策略

对于过期键一般有三种删除策略

https://www.cnblogs.com/lukexwang/p/4694094.html

定时删除：在设置键的过期时间的同时，创建一个定时器(timer)，让定时器在键的过期时间来临时，立即执行对键的删除操作；

惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，那就返回该键；

定期删除：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于删除多少过期键，以及要检查多少个数据库，则由算法决定。

下面我们来看看三种策略的优缺比较：

定时删除策略对内存是最友好的：

通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存；但另一方面，定时删除策略的缺点是，他对CPU是最不友好的：在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间，在内存不紧张但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响；

惰性删除策略对CPU时间来说是最友好的：

程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行；惰性删除策略的缺点是，它对内存是最不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放；

定时删除占用太多CPU时间，影响服务器的响应时间和吞吐量；

惰性删除浪费太多内存，有内存泄漏的危险。

定期删除策略是前两种策略的一种整合和折中：定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响；通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存浪费；定期删除策略的难点是确定删除操作执行的时长和频率。

Redis的过期键删除策略：Redis服务器实际使用的是惰性删除和定期删除两种策略。

redis6.0新版本特性 多线程

2019年的 RedisConf 比以往时候来的更早一些，今年会议时间是4月1-3号，仍然是在旧金山鱼人码头Pier 27。恰逢今年是 Redis 第10周年，规模也比以往大一些，注册人数超过1600人，总共有80个议题，除了RedisLabs外还有很多云厂商和Redis用户带来分享。Redis 作者 antirez 在 RedisConf 2019 做了分享，其中一段展示了 Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上。

无独有偶，在之前 antirez 的博客上，我们已经提前知道了这个消息：

多线程实现
目前对于单线程 Redis 来说，性能瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:

提高网络 IO 性能，典型的实现像使用 DPDK 来替代内核网络栈的方式
使用多线程充分利用多核，典型的实现像 Memcached
多线程特性在社区也被反复提了很久后，Redis作者antirez终于在 Redis 6 加入多线程。

因为读写网络的read/write系统调用在Redis执行期间占用了大部分CPU时间，如果把网络读写做成多线程的方式对性能会有很大提升。现在已经实现了第一版，write side即回复客户端这部分已经完成了，并且去掉了主线程和IO线程之间的互斥锁，采用busy loop的形式来等待io线程工作结束，这部分能够有50%的性能提升，架构图如下：

Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想 Redis 因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。

多线程 IO 的读(请求)和写(响应)在实现流程是一样的，只是执行读还是写操作的差异。同时这些 IO 线程在同一时刻全部是读或者写，不会部分读或部分写的情况，所以下面以读流程作为例子。分析过程中只会覆盖核心逻辑而不是全部细节。如果想完全理解细节，建议看完之后再次看一次源码实现。

加入多线程 IO 之后，整体的读流程如下:

主线程负责接收建连请求，读事件到来(收到请求)则放到一个全局等待读处理队列
主线程处理完读事件之后，通过 RR(Round Robin) 将这些连接分配给这些 IO 线程，然后主线程忙等待(spinlock 的效果)状态
IO 线程将请求数据读取并解析完成(这里只是读数据和解析并不执行)
主线程执行所有命令并清空整个请求等待读处理队列(执行部分串行)
上面的这个过程是完全无锁的，因为在 IO 线程处理的时主线程会等待全部的 IO 线程完成，所以不会出现data race的场景。

性能对比
压测配置：

Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 内存，主机型号 ecs.ic5.2xlarge
Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 内存，主机型号 ecs.ic5.2xlarge

多线程 IO 版本刚合并到 unstable 分支一段时间，所以只能使用 unstable 分支来测试多线程 IO，单线程版本是 Redis 5.0.5。多线程 IO 版本需要新增以下配置:

io-threads 4 # 开启 4 个 IO 线程
io-threads-do-reads yes # 请求解析也是用 IO 线程

压测命令:

redis-benchmark -h 192.168.0.49 -a foobared -t set,get -n 1000000 -r 100000000 --threads 4 -d ${datasize} -c 256

从上面可以看到 GET/SET 命令在 4 线程 IO 时性能相比单线程是几乎是翻倍了。另外，这些数据只是为了简单验证多线程 IO 是否真正带来性能优化，并没有针对严谨的延时控制和不同并发的场景进行压测。数据仅供验证参考而不能作为线上指标，且只是目前的 unstble分支的性能，不排除后续发布的正式版本的性能会更好。


总结
Redis 6.0 预计会在 2019 年底发布，将在性能、协议以及权限控制都会有很大的改进。antirez 今年全身心投入在优化 Redis 和集群的功能，特别值得期待。另外，今年年底社区也会同时发布第一个版本 redis cluster proxy 来解决多语言 SDK 兼容的问题，期待在具备 proxy 功能之后 cluster 能在国内有更加广泛的应用。

转载的网站:
https://ask.qcloudimg.com/http-save/yehe-4752702/tqqzco5cqu.png?imageView2/2/w/1620
https://www.iteye.com/blog/uule-2144221
https://www.redis.net.cn/tutorial/3501.html
http://www.redis.cn/commands.html
https://www.jianshu.com/p/4e6b7809e10a
https://www.cnblogs.com/weswes/p/10019498.html