redis以及BIO NIO IO多路复用

redis6以前单线程，6之后对于异步删除操作引入多线程，来完善自己，但是对于大部分命令，依旧是原子的。
redis压测
redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t set 并发50 连接数10000
redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -q

大概写8w，读10wqps

点赞多线程的话 LongAdder redis incr

redis为什么快
1.高效的八大数据结构，基本上都是kv键值对，查询高效
2.基于内存实现
3.使用了合适的线程模型 IO多路复用，同时监听多客户端连接，利用epoll来实现IO多路复用

redis单线程为什么快
多线程在执行过程中需要cpu的上下文切换，这个操作比较耗时。redis又是基于内存实现的，对于内存来说，没有上下文切换，效率高。
redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，一次放到文件事件分派器，事件分派器将事件分发给事件处理器；

BIO缺点：accept和read方法都会阻塞，如果客户端迟迟不发数据，进程就会一直堵塞在read方法上，这样其他客户端就迟迟不能操作，也就是一次只能处理一个客户端，对客户很不友好
NIO：accept是非阻塞的，如果没有客户端连接，就返回error
read方法是非阻塞的，如果读取不到数据就返回error，如果读取到数据，只阻塞读数据的时间

NIO模式中，只有一个线程：
当一个客户端与服务端进行连接，这个socket就会加入到一个数组中，隔一段时间遍历一次，看这个socket的read方法能否读取到数据，这样一个县城就能处理多个客户端的连接和读取了；

NIO成功解决了BIO中需要开启多线程的问题，一个线程就能解决多个客户端的连接，但是还是有问题
这个模型在客户端少的时候很好用，如果客户端很多，而只有很少的客户端在发送数据，那么还是需要遍历所有客户端
遍历的过程还是在用户态进行的，用户态判断socket是否有数据还是调用内核的read方法，这就涉及到用户态和内核态的切换，每遍历一个就要切换一次，开销很大，因为这些问题的存在，IO多路复用应运而生；
IO多路复用将上述工作直接放入linux内核，不再两态转换，而是从内核获得结果，因为内核是非阻塞的。
优点：不会阻塞在内核的等待数据过程，每次发起的IO请求可以立即返回，不用阻塞等待，实时性较好；
缺点：轮询将会不断地询问内核，这将占用大量的cpu时间，系统资源利用率较低，所以一般web服务器不使用这种IO模型；
事件驱动机制 select poll epoll