redis架构的的分析.docxVIP

一、前言因为近期项目中开始使用Redis，为了更好的理解Redis并应用在适合的业务场景，需要对Redis设计与实现深入的理解。我分析流程是按照从main进入，逐步深入分析Redis的启动流程。同时根据Redis初始化的流程，理解Redis各个模块的功能及原理。二、redis启动流程1.初始化server变量，设置redis相关的默认值2.读入配置文件，同时接收命令行中传入的参数，替换服务器设置的默认值3.初始化服务器功能模块。在这一步初始化了包括进程信号处理、客户端链表、共享对象、初始化数据、初始化网络连接等4.从RDB或AOF重载数据5.网络监听服务启动前的准备工作6.开启事件监听，开始接受客户端的请求启动的部分过程通过查看下图，会更直观。下面是针对启动过程中，对各个模块的详细理解。（目前只分析了后台线程系统与慢查询日志系统）三、Redis数据持久化方案在使用redis时不少人都说一个问题，就是说redis宕机了怎么办？会不会数据丢失等等的问题。现在来看看Redis提供的数据持久化解决方案，并通过原理分析优缺点。最终能得出Redis适合使用的应用场景。1.RDB持久化方案在Redis运行时，RDB程序将当前内存中的数据库快照保存到磁盘中，当Redis需要重启时，RDB程序会通过重载RDB文件来还原数据库。从上述描述可以看出，RDB主要包括两个功能：关于rdb的实现可以见src/rdb.ca）保存(rdbSave)rdbSave负责将内存中的数据库数据以RDB格式保存到磁盘中，如果RDB文件已经存在将会替换已有的RDB文件。保存RDB文件期间会阻塞主进程，这段时间期间将不能处理新的客户端请求，直到保存完成为止。为避免主进程阻塞，Redis提供了rdbSaveBackground函数。在新建的子进程中调用rdbSave，保存完成后会向主进程发送信号，同时主进程可以继续处理新的客户端请求。b）读取(rdbLoad)当Redis启动时，会根据配置的持久化模式，决定是否读取RDB文件,并将其中的对象保存到内存中。载入RDB过程中，每载入1000个键就处理一次已经等待处理的客户端请求，但是目前仅处理订阅功能的命令(PUBLISH 、 SUBSCRIBE 、 PSUBSCRIBE 、 UNSUBSCRIBE 、 PUNSUBSCRIBE)，其他一律返回错误信息。因为发布订阅功能是不写入数据库的，也就是不保存在Redis数据库的。RDB的缺点：再说RDB缺点时，需要提到的是RDB有保存点的概念。在默认的redis.conf中可以看到这样的默认配置：[plain]?view plaincopy#save?seconds?changes??[plain]?view plaincopysave?900?1????????#如果15分钟内，有1个键被修改??[plain]?view plaincopysave?300?10??????#如果6分钟内，有10个键被修改??[plain]?view plaincopysave?60?10000??#如果60秒内有10000个键被修改??意思是当满足上面任意一个条件时，将会进行快照保存。为了保证IO读写性能不会成为Redis的瓶颈，一般都会创建一个比较大的值来作为保存点。1.此时如果保存点设置过大，就会导致宕机丢失的数据过多。保存点设置过小，又会造成IO瓶颈2.当对数据进行保存时，可能会由于数据集过大导致操作耗时，这会导致Redis可能在短时间内无法处理客户端请求。2.AOF持久化方案以协议文本的方式，将所有对数据库进行的写入命令记录到AOF文件，达到记录数据库状态的目的。a)保存1.将客户端请求的命令转换为网络协议格式2.将协议内容字符串追加到变量server.aof_buf中3.当AOF系统达到设定的条件时，会调用aof_fsync(文件描述符号)将数据写入磁盘其中第三步提到的设定条件，就是AOF性能的关键点。目前Redis支持三种保存条件机制：1.AOF_FSYNC_NO：不保存此模式下，每执行一条客户端的命令，都会将协议字符串追加到server.aof_buf中，但不会执行写入磁盘。写入只发生在：? ? ?1.Redis被正常关闭?? ? ?2.Aof功能关闭? ? ?3.系统写缓存已满，或后台定时保存操作被执行上面三种情况都会阻塞主进程，导致客户端请求失败。2.AOF_FSYNC_EVERYSECS：每一秒保存一次由后台子进程调用写入保存，不会阻塞主进程。如果发生宕机，那么最大丢失数据会在2s以内的数据。这也是默认的设置选项3.AOF_FSYNC_ALWAYS：每执行一个命令都保存一次这种模式下，可以保证每一条客户端指令都被保存，保证数据不会丢失。但缺点就是性能大大下降，因为每一次操作都是独占