常识
- 磁盘
- 寻址：ms
- 带宽：G/M
- 内存
- 寻址：ns
- 带宽：很大？
秒>毫秒>微秒>纳秒 磁盘比内存在寻址慢10w倍
I/O buffer：成本问题
磁盘与磁道：扇区，一扇区512Byte带来成本变大；
索引4k 操作系统，无论读多少，都是最小4k从磁盘拿
数据库
如果表有索引
增删改变慢：维护索引慢
查询速度？1.一个或少量查询依然很快 2.并发大的时候回受硬盘带宽影响速度
缓存
2个基础设施制约，导致redis：冯诺依曼体系的硬件（如果量子计算机出现、IO带宽问题解决就不会有redis）、以太网tcp/ip网络(不稳定，数据不一致双写)
Memcached和Redis：Memcached仅支持k、v，而Redis的v支持多种类型数据结构（String、hashes、lists、sets、sorted sets）从而Redis Server对每种类型有自己的方法【计算向数据移动】
IO
BIO
socket是阻塞的，有数据就处理，没数据就阻塞着，只能抛出更多线程，如此当只有一个cpu的情况下某一个时间只有一个线程在处理。所以需要内核的跃迁（变成非阻塞IO）
待解决的问题：
- 阻塞，线程太多（每个成本是1M，且消耗CPU）
命令：
- cd /proc/<pid>/fd && ll: 查看文件描述符
- man 2 read: 查看文件
NIO
改进点：socket是nonblock，这样就不用多个线程，同步（一个线程）非阻塞（内核）
待解决问题：如果有1000个文件描述符，要进行1000次系统调用，若要减少调用次数，用户无法解决，故需要内核的再次跃迁（轮询从用户空间改成内核空间）
命令：
- $ man ls 表示怎么使用的，是一类文档（8类）
- $ man 2 read (2类是系统调用)
注意，此时系统调用仍然是read，只是内核升级成了非阻塞 - man 2 socket
多路复用NIO
系统调用改成了select，由用户传入所有的fd（文件描述符），让内核去监控所有的fd然后再在有fd有输入时返回fd给用户，然后用户再对这些fd进行针对性read
待解决问题：用户需要传入fds，需要在用户态和内核态之间返回传递
命令：
- man 2 select：系统调用改成了select，轮询变成了内核在完成，也就是一个program同时监控多个文件描述符；
epoll
mmap系统调用用于在用户态和内核态共享空间，内部是红黑树和链表；用户态将fd放如红黑树，内核态检测到数据到达则将对应fd放入链表，由用户态在链表中fd进行read
用户空间可以create,当有连接进来就将该fd给epfd（增删改内核完成，查询两边都可以），ctl调用（add del socket fd），wait（等待事件，事件驱动）
与多路复用NIO区别：多路复用是每次都要压所有fd给内核
命令：
- man 2 mmap：用户态和内核态共享空间，避免fd的来回传
- man epoll：epoll_creata、epoll_ctl、epoll_wait
与零拷贝区别：
- man 2 sendfile：out_fd, in_fd, offset, count;
- 在此之前是通过read到用户态然后write回内核态
- 现在内核缓冲区直接读入和写出，就不需要和程序进行拷贝
引申：kafka（sendfile+mmap）
Mmap：进来的数据，由于jvm mmap直接挂载到文件或db，所以直接进入到文件，减少文件传输的时间
sendfile：出去的数据，使用了零拷贝，outfd是文件，in是消费者
引申：nginx
类似Redis
回到Redis
- 首先会有很多客户端/socket连接进来，例如一个tomcat里的线程池或者几台机器分布式去连Redis，在Redis来看很多socket均打到了内核
- Redis服务端进程，调用epoll遍历寻找哪个客户端信息发送过来
- Redis单进程处理用户对数据的请求
- 注意：
- Redis的顺序仅仅是对于任意一个client连接内的事务，对于多个client要自行做好负载，否则同一个资源（key）要放在同一个client里
