redis为什么这么快 自己总结的几个点
一. 基本常识
-
在计算机中，数据是存储在磁盘中的
磁盘的时间单位
a. 寻址: ms
b. 带宽: G/M内存的时间单位
a. 寻址: ns时间单位组成
秒 > 毫秒 > 微秒 > 纳秒
在寻址上，磁盘比内存慢了10w倍
-
I/O buff：成本问题
关系型数据库随着文件变大，速度变慢，为什么？
硬盘I/O成为瓶颈
磁盘有磁道和扇区，一个扇区512byte，容器小就带来了成本变大：索引
操作系统一次性会读取4k的数据，就算你只要1k，操作系统也会一次性从磁盘读取4k
所以mysql的文件设计的页data page也是4k, 刚好满足操作系统一次读取的大小，但是当文件增大之后，就 会出现很多的data page页，这个时候，查询速度就会变慢，此时就使用了索引 b+树。(为什么使用b+树 等写mysql相关时再说)
-
所以， 当数据库表很大的时候，表文件就会很大，性能下降，下降的原因
- 如果有索引，增删改的时候会维护索引，速度会变慢
- 查询速度
a. 1个或少量查询时依然很快
b. 并发大的时候会受到硬盘带宽的限制影响速度
二. epoll
- IO的发展历程
在操作系统中，每一个I/O都视为一个文件描述符fd
-
BIO
- BIO的流程，大致可以描述为以下场景
- 幼儿园（进程）
- 小朋友(文件描述符fd)
- 老师（线程）
- 每一个小朋友需要配一名老师，每个老师会询问对应的小朋友，要不要上厕所（I/O操作），这种操作造成了系统资源的极大浪费
- jvm：一个线程的成本 1MB
a. 线程多了产生调度成本 cpu不停切换线程浪费
b. 内存成本增大
- BIO的流程，大致可以描述为以下场景
-
NIO
- NIO的流程可以描述成这样
- 幼儿园聘请一个老师，死循环的去询问每一个小朋友（select(Nfd)），要不要上厕所（I/O操作），此时就不会浪费系统资源
- 但此时还是存在一些问题
a. 当小朋友很多的时候，一个老师循环问一遍小朋友就需要花很长的时间
b. 当小朋友要上厕所的时候，需要把小朋友从教室（内核）带到厕所（用户空间） 整体行为=拷贝fd相关数据
-
epoll
- epoll是linux系统中对nio多路复用的优化；
- nio是进程用户态中循环读取所有的文件描述符进行处理，如果文件描述符过多的话，循环遍历的速度会受到限制，并且中间也有从内核中读取的过程；
- epoll使用了一个用户态和内核态的共享空间MMAP，将文件描述符都放在共享空间的红黑树中，如果有某个连接发生事件，就将连接加入到共享空间的链表中,然后由用户态进行操作
-
最终总结
为什么redis快
1. 单线程操作，没有事务
2. 直接操作内存，不受磁盘IO影响
3. 使用了linux中的epoll对网络IO进行优化
