缓存技术在分布式中的实践与原理(二.redis、memcached网络IO模型分析)

引言

上一节简单介绍了redis的安装与使用,与redis一样的缓存组件还有memcached,大体接入方式类似,这里就不重复介绍了,大家可以google具体memcached安装以及使用方式。那么这一节将围绕redis以及memcached两大分布式最常用的缓存组件,对它们各自使用的网络IO模型进行分析。

简介

本篇博客主要针对redis的单线程模型,epoll事件驱动。以及memcached多线程模型,libevent事件驱动进行对比分析,了解他们各自的设计思想与应用层的利弊。

目录:1.redis的单线程模型

           2.memcached的多线程模型

正文

引用一段CSDN博主对于redis架构的描述:

Redis单线程架构

1 单线程模型(linux只有轻量级进程,ps命令也会出线程,由于博主不搞底层开发,就把模拟进程称为线程)

Redis客户端对服务端的每次调用都经历了发送命令,执行命令,返回结果三个过程。其中执行命令阶段,由于Redis是单线程来处理命令的,所有每一条到达服务端的命令不会立刻执行,所有的命令都会进入一个队列中,然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行,不会产生并发问题,这就是Redis的单线程基本模型。

2 单线程模型每秒万级别处理能力的原因

(1)纯内存访问。数据存放在内存中,内存的响应时间大约是100纳秒,这是Redis每秒万级别访问的重要基础。

(2)非阻塞I/O,Redis采用epoll做为I/O多路复用技术的实现,再加上Redis自身的事件处理模型将epoll中的连接,读写,关闭都转换为了时间,不在I/O上浪费过多的时间。

(3)单线程避免了线程切换和竞态产生的消耗。

(4)Redis采用单线程模型,每条命令执行如果占用大量时间,会造成其他线程阻塞,对于Redis这种高性能服务是致命的,所以Redis是面向高速执行的数据库。

ok,看完了以上描述,我的总结是:

总体来说:

1)绝大部分请求是纯粹的内存操作(非常快速) 

2)采用单线程,避免了不必要的上下文切换和竞争条件 

3)非阻塞IO 、epoll event loop。

Redis的单线程的行为主要是对内存的读写,这些操作其实用不了多少时间,因此瓶颈在网络I/O上面,我们一般提供较好的网络环境就可以提升Redis的吞吐量,比如提高网络带宽,除此之外还可以通过合并命令提交批处理请求(pipeline)来代替单条命令一次次请求从而减少网络开销,提高吞吐量。

我们来进一步研究redis的网络模型,redis是封装了下图几种多路复用器实现的EventLoop事件轮训,redis没有采用memcached采用的Libevent,Libevent为了迎合通用性造成代码庞大及牺牲了在特定平台的不少性能。Redis一直坚持设计小巧并去依赖库的思路,提供Socket句柄事件的多路复用器,这部分分别对于不同平台提供了不同的实现,比如epoll和select可以用于linux平台、kqueue可以用于苹果平台、evpoll可以用于Solaris平台,这里并没有看到iocp,也就是Redis对于Windows支持并不是很好。


缓存技术在分布式中的实践与原理(二.redis、memcached网络IO模型分析)_第1张图片

什么是多路I/O复用?

(1) 网络IO都是通过Socket实现,Server在某一个端口持续监听,客户端通过Socket(IP+Port)与服务器建立连接(ServerSocket.accept),成功建立连接之后,就可以使用Socket中封装的InputStream和OutputStream进行IO交互了。针对每个客户端,Server都会创建一个新线程专门用于处理 

(2) 默认情况下,网络IO是阻塞模式,即服务器线程在数据到来之前处于【阻塞】状态,等到数据到达,会自动唤醒服务器线程,着手进行处理。阻塞模式下,一个线程只能处理一个流的IO事件 

(3) 为了提升服务器线程处理效率,有以下三种思路

(1)非阻塞【忙轮询】:采用死循环方式轮询每一个流,如果有IO事件就处理,这样可以使得一个线程可以处理多个流,但是效率不高,容易导致CPU空转

(2)Select代理(无差别轮询):可以观察多个流的IO事件,如果所有流都没有IO事件,则将线程进入阻塞状态,如果有一个或多个发生了IO事件,则唤醒线程去处理。但是还是得遍历所有的流,才能找出哪些流需要处理。

(3)Epoll代理:Select代理有一个缺点,线程在被唤醒后轮询所有的Stream,还是存在无效操作。 Epoll会哪个流发生了怎样的I/O事件通知处理线程,因此对这些流的操作都是有意义的。

Linux下epoll属于IO多路复用,但他实际应用必须搭配no-blocking io ,执行epoll和具体业务都是在同个主进程中执行。虽然纯内存的业务操作很快,但在执行业务时,有新的请求到来那么kernel中发现readylist正在被使用时,会把就绪事件放在ovflist中当处理完readylist后,会检查ovflist是否有事件。

首先,Redis服务器中有两类事件,文件事件和时间事件。

文件事件(file event):Redis客户端通过socket与Redis服务器连接,而文件事件就是服务器对套接字操作的抽象。例如,客户端发了一个GET命令请求,对于Redis服务器来说就是一个文件事件。

时间事件(time event):服务器定时或周期性执行的事件。例如,定期执行RDB持久化。

在这里我们主要关注Redis处理文件事件的模型:Reactor模型


缓存技术在分布式中的实践与原理(二.redis、memcached网络IO模型分析)_第2张图片

Handles :表示操作系统管理的资源,我们可以理解为fd。

Synchronous Event Demultiplexer :同步事件分离器,阻塞等待Handles中的事件发生。

Initiation Dispatcher :初始分派器,作用为添加Event handler(事件处理器)、删除Event handler以及分派事件给Event handler。也就是说,Synchronous Event Demultiplexer负责等待新事件发生,事件发生时通知Initiation Dispatcher,然后Initiation Dispatcher调用event handler处理事件。

Event Handler :事件处理器的接口

Concrete Event Handler :事件处理器的实际实现,而且绑定了一个Handle。因为在实际情况中,我们往往不止一种事件处理器,因此这里将事件处理器接口和实现分开,与C++、Java这些高级语言中的多态类似。


2.memcached网络IO模型


缓存技术在分布式中的实践与原理(二.redis、memcached网络IO模型分析)_第3张图片

Memcached是多线程,非阻塞IO复用的网络模型,分为监听主线程和worker子线程,监听线程监听网络连接,接受请求后,将连接描述字pipe 传递给worker线程,进行读写IO, 网络层使用libevent封装的事件库,多线程模型可以发挥多核作用,但是引入了cache coherency和锁的问题,比如,Memcached最常用的stats 命令,实际Memcached所有操作都要对这个全局变量加锁,进行计数等工作,带来了性能损耗。

Libevent应该算是包含了上述一些功能,总体来说也是走事件驱动+no blocking io。会有一个fd和event的mapping关系,至于linux内核对于唤醒的细节就没有多研究了,那总体对比下来,io层面的话,redis有单线程的优势、批量pipeline的优势,memcached有多核优势,但是多了一些同步的损耗,但是在内存管理方面以及集群方面,redis是动态分配,memcached是分配比较固定的chunk,那对于某些字节比chunk小的情况,就有浪费的空间,集群方面memcached服务端是没有分布式的,redis在3.0提供了cluster,这个后续讨论,具体性能对比还需要区分数据量 数据格式 集群方案等,下篇文章主要分析两者在内存管理上的区别。

你可能感兴趣的:(缓存技术在分布式中的实践与原理(二.redis、memcached网络IO模型分析))