直播类app开发，有必要了解Redis相关知识

Redis单线程原理

Redis作为现在直播类app开发中必不可少的组件，在缓存、分布式锁、session共享等等场景中被大量使用。熟练使用之余，更需要了解一下其原理。

Redis快的原因

1. Redis中的大量操作都在内存中完成（部分操作，例如持久化，会与磁盘打交道），众所周知，内存的速度与磁盘的速度不是一个数量级；
2. 并且Redis是单线程操作（6.0版本之前），减少了不必要的上下文切换，并且不用考虑各种锁的问题，不存在加锁或释放锁操作，更不会因为死锁而导致性能消耗；
3. Redis使用I/O多路复用技术，可以处理并发的连接。

 注释：

file descriptor 文件描述符。Linux系统中，把一切都看做是文件，当进程打开现有文件或创建文件时，内核向进程返回一个文件描述符(fd)。可以把fd看做是一个索引，这样要操作文件的时候，我们直接找到索引就可以对其进行操作。

I/O多路复用

因为Redis是单线程，所有的操作都是按照顺序线性操作的，由于读写操作等待用户输入或者输出都是阻塞的，所以I/O操作在正常情况下往往不能直接返回，这就会导致文件的I/O阻塞。一共就这么一个线程，阻塞之后直播类app开发便无法对外提供服务。现在使用I/O多路复用便可以解决这个问题，又保留了单线程的一些优势。

对上图Redis的I/O多路复用模型进行一下描述：

1. 一个socket客户端与服务端连接时，会生成对应一个fd
2. 当多个直播类app开发的客户端与服务端连接时，Redis使用I/O多路复用程序将客户端socket对应的fd注册到监听列表中，并监听多个fd的读写情况。当客户端执行read、write等操作命令时，I/O多路复用程序会将命令封装成一个事件绑定到对应的fd上。
3. 当socket有文件事件产生时，I/O多路复用模块就会将那些产生了事件的套接字fd传送给文件事件分派器
4. 文件事件分派其接收到I/O多路复用程序传来的套接字fd后，并根据套接字产生的事件类型，将套接字分给响应的事件处理器进行处理命令
5. 整个文件事件处理器是在单线程上运行的，但是通过I/O多路复用模块的引入，实现了同时对多个fd读写的监控，当其中一个client端达到读写状态，文件事件处理器就马上执行，从而不会出现I/O阻塞的问题

例如：以Redis的I/O多路复用程序epoll函数为例，当多个直播类app开发的客户端连接服务器时，Redis会将客户端socket对应的fd注册进epoll中，然后epoll同时监听多个fd是否有数据到来，如果有数据来了就通知事件处理器处理命令，这样就不会存在服务端一直等待某个客户端给数据的场景。

多唠两句

• I/O多路复用程序有多种实现方式，例如有select、poll、kqueue、epoll，redis默认使用epoll

• epoll不负责不传递数据，只负责通知，这点很重要

• 既然Redis默认使用epoll，那肯定是有原因的，epoll的优点：

  1. epoll没有最大并发连接，效率提升
  2. epoll只管“活跃”的连接
  3. 共享内存，省去了拷贝过程

• 如果使用select/poll，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时消耗很大。而epoll直接使用共享内存，不用在用户态和内核态之间来回拷贝

• Redis6.0版本之后，在处理网络数据的读写和协议解析时可以使用多线程（默认仍然是单线程，可以设置为多线程），执行命令仍然是单线程。

以上内容仅作为直播类app开发的学习记录，如有错误请留言指正，谢谢。

声明：本文由云豹科技转发自红酒博客，如有侵权请联系作者删除