计划本周写完。。。
分析Redis性能主要考虑两个问题:
- 1、Redis为什么这么快( 优 化 点 \color{red}{优化点} 优化点)
- 2、Redis怎么用能更快( 注 意 事 项 \color{red}{注意事项} 注意事项)
1、分析Redis为什么这么快,我们从以下几方面去分析:
- 网络层和操作系统层
- 内存及数据结构
- Redis自身做了那些优化
- 阿里及其他云公司又做了那些优化
2、分析Redis怎么用能更快,我们从以下几方面去分析:
- Redis用于缓存
- 防止缓存穿透、缓存击穿、缓存雪崩
- 冷热数据分离
网络层和操作系统层
-
在网络层,Redis选取了一种比较优秀的IO模型:epoll,其相对于之前的select模型、poll模型,多出来三个优点,具体见博客:IO多路复用的三种机制Select,Poll,Epoll:
- 优化点1:使用红黑树结构,一来句柄的最大限制没有了,二来方便了句柄新增、查找和删除。
- 优化点2:操作方式由遍历转换成回调,极大的提升了IO效率。
- 优化点3:回调方式新增边缘触发,可以理解为优先级高的触发方式,
- 优化点4:fd拷贝问题由每次询问就全量复制,修改为增量拷贝。
-
在操作系统层:
- 优化点5:Redis使用单线程,避免了多线程切换导致的资源和时间消耗,但是这一点不完全属于优化点,针对整个消息流而言,瓶颈并不在CPU,就好像自来水流量小(网络IO),增加接水的人(线程)并不能增大水量,另外要注意两点:
- 整个Redis运行过程中不止一个线程,仅仅是用于IO的是单线程,后续6.0页增加了多线程。
- 即使是单线程的Redis,也可以通过多起Redis服务,搭建主从、读写分离等方式充分利用多核CPU。
- 优化点5:Redis使用单线程,避免了多线程切换导致的资源和时间消耗,但是这一点不完全属于优化点,针对整个消息流而言,瓶颈并不在CPU,就好像自来水流量小(网络IO),增加接水的人(线程)并不能增大水量,另外要注意两点:
内存及数据结构
- 在数据结构上的优化主要是考虑数据存取的时间复杂度,是一种用空间换时间的做法:
- 优化点6:以跳表为例:数组方便查找,不利于新增,链表利于新增,不利于查找,于是Redis底层实现了跳表,一种可以折半查找的双向链表,增删改查都快。
- 注意到:在使用单向链表实现跳表的实践中发现,当数据从小到大排序时,按照从大到小插入,效率极慢,但是如果是双向链表,就可以很好解决这个问题。
- 优化点6:以跳表为例:数组方便查找,不利于新增,链表利于新增,不利于查找,于是Redis底层实现了跳表,一种可以折半查找的双向链表,增删改查都快。
- 在内存上:
- Redis的内存模型
- Redis内存回收策略
Redis自身做了那些优化
阿里及其他云公司又做了那些优化
Redis用于缓存
防止缓存穿透、缓存击穿、缓存雪崩
冷热数据分离
【彩蛋】
- Redis的监控和故障排查