Redis学习笔记

Redis

常用命令

client list：查看已连接的客户端列表，keys *：查看redis里所有的key，info：查看redis服务的信息

数据类型与应用场景

String：单值缓存，对象缓存（value为json），分布式锁（setnx product:1001 true ex 10 nx），计数器（incr article:readcount:{文章id}），分布式session，分布式全局序列号
Hash：对象缓存，购物车（用户id为key，商品ID为field，商品数量为value）
List：栈（LPUSH+LPOP），队列（LPUSH+RPOP），阻塞队列（LPUSH+BRPOP），微博和微信公众号消息流
SET：微信抽奖小程序（参与抽奖：SADD key userid，查看参与人：SMEMBERS key，可重复参与抽奖：SRANDMEMBER key 10，不可重复参与抽奖：SPOP key 10），微信微博点赞收藏标签，集合操作（交，并，差），微博微信关注模型，电商商品筛选
ZSET：集合操作实现排行榜

核心原理

Redis单线程为什么还这么快

1.数据都存储在内存里，运算也是在内存里，2.单线程，避免了线程上下文切换带来的损耗，因为是单线程所以，耗时的指令要慎用，例如keys

单线程为什么能处理大量的并发客户端连接

IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。Nginx也是采用IO多路复用原理解决C10K问题 ,epoll关键点：文件系统，红黑树存储socket，回调函数通知有数据从网卡接收到，list存放有数据到达的socket，相对于select的优点：减少了用户态和内核态的文件句柄拷贝，减少了对可读可写文件句柄的遍历，IO性能不会随着监听的文件描述的数量增长而下降

分布式锁

续命，自旋，可重入

缓存的四大问题

缓存穿透

布隆过滤器或者缓存空对象

缓存击穿

使用互斥锁，同时只有一个线程能够去查询数据库和更新缓存

缓存雪崩

缓存过期时间分散开，另外保证redis集群高可用

缓存一致性

先更新数据库再删除缓存（因为写数据库一般比读数据库的时间长，所以数据更新完之后，再删除缓存，下一个请求过来发现没有数据就会去读数据库，再更新缓存到redis，高并发写入的场景另说），如果缓存删除失败发一条消息到mq，然后自己消费，可以保证最终一致性

调优操作

基础原则

确保没有让Redis执行耗时长的命令、
使用pipelining将连续执行的命令组合执行、
检查数据持久化策略、
考虑引入读写分离机制、
不要把List当做列表使用，仅当做队列来使用、
通过机制严格控制Hash、Set、Sorted Set的大小、
可能的话，将排序，并集，交集等操作放在客户端执行、
绝对禁止使用KEYS命令、
避免一次性遍历集合类型的所有成员，而应使用SCAN类的命令进行分批的，游标式的遍历、

慢查询

slowlog-log-slower-than xxxms #执行时间慢于xxx毫秒的命令计入Slow Log
slowlog-max-len xxx #Slow Log的长度，即最大纪录多少条Slow Log
SLOWLOG len获取当前记录的slowlog的条数
使用SLOWLOG GET [number]命令，可以输出最近进入Slow Log的number条命令。
使用SLOWLOG RESET命令，可以重置Slow Log

固有延迟

如果在虚拟机中运行Redis，可能天然就有虚拟机环境带来的固有延迟。可以通过./redis-cli –intrinsic-latency 100命令查看固有延迟。同时如果对Redis的性能有较高要求的话，应尽可能在物理机上直接部署Redis。

选择合适的持久化策略

RDB持久化性能好，恢复快，AOF持久化数据丢失少，恢复慢

修改linux中TCP监听的数值

设置未连接队列大小限制：echo 2048>/proc/sys/net/ipv4/tcp_max_syn_backlog
中每一个端口最大的监听队列的长度：echo 256>/proc/sys/net/core/somaxconn

操作系统的Transparent huge pages功能必须关闭

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Swap引发的延迟

当Linux将Redis所用的内存分页移至swap空间时，将会阻塞Redis进程，导致Redis出现不正常的延迟。Swap通常在物理内存不足或一些进程在进行大量I/O操作时发生，应尽可能避免上述两种情况的出现。
/proc//smaps文件中会保存进程的swap记录，通过查看这个文件，能够判断Redis的延迟是否由Swap产生。如果这个文件中记录了较大的Swap size，则说明延迟很有可能是Swap造成的。

数据淘汰引发的延迟

当同一秒内有大量key过期时，也会引发Redis的延迟。在使用时应尽量将key的失效时间错开。

引入读写分离机制

Redis的主从复制能力可以实现一主多从的多节点架构，在这一架构下，主节点接收所有写请求，并将数据同步给多个从节点。
在这一基础上，我们可以让从节点提供对实时性要求不高的读请求服务，以减小主节点的压力。
尤其是针对一些使用了长耗时命令的统计类任务，完全可以指定在一个或多个从节点上执行，避免这些长耗时命令影响其他请求的响应。

网络引发的延迟

尽可能使用长连接或连接池，避免频繁创建销毁连接的压力，尤其是针对一些使用了长耗时命令的统计类任务，完全可以指定在一个或多个从节点上执行，避免这些长耗时命令影响其他请求的响应。
客户端进行的批量数据操作，应使用Pipeline特性在一次交互中完成。