神器Redis的性能及优化探究

计划本周写完。。。

分析Redis性能主要考虑两个问题：

• 1、Redis为什么这么快（$优化点$）
• 2、Redis怎么用能更快（$注意事项$）

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。

内存及数据结构

• 在数据结构上的优化主要是考虑数据存取的时间复杂度，是一种用空间换时间的做法：
  • 优化点6：以跳表为例：数组方便查找，不利于新增，链表利于新增，不利于查找，于是Redis底层实现了跳表，一种可以折半查找的双向链表，增删改查都快。
    • 注意到：在使用单向链表实现跳表的实践中发现，当数据从小到大排序时，按照从大到小插入，效率极慢，但是如果是双向链表，就可以很好解决这个问题。
• 在内存上：
  • Redis的内存模型
  • Redis内存回收策略

Redis自身做了那些优化

阿里及其他云公司又做了那些优化

Redis用于缓存

防止缓存穿透、缓存击穿、缓存雪崩

冷热数据分离

【彩蛋】

• Redis的监控和故障排查