导航:首页 > 源码编译 > epoll源码原理

③ 关于Linux下的select/epoll

select这个系统调用的原型如下

第一个参数nfds用来告诉内核 要扫描的socket fd的数量+1 ，select系统调用最大接收的数量是1024，但是如果每次都去扫描1024，实际上的数量并不多，则效率太低，这里可以指定需要扫描的数量。 最大数量为1024，如果需要修改这个数量，则需要重新编译Linux内核源码。
第2、3、4个参数分别是readfds、writefds、exceptfds，传递的参数应该是fd_set 类型的引用，内核会检测每个socket的fd， 如果没有读事件，就将对应的fd从第二个参数传入的fd_set中移除，如果没有写事件，就将对应的fd从第二个参数的fd_set中移除，如果没有异常事件，就将对应的fd从第三个参数的fd_set中移除 。这里我们应该 要将实际的readfds、writefds、exceptfds拷贝一份副本传进去，而不是传入原引用，因为如果传递的是原引用，某些socket可能就已经丢失 。
最后一个参数是等待时间， 传入0表示非阻塞，传入>0表示等待一定时间，传入NULL表示阻塞，直到等到某个socket就绪 。

FD_ZERO()这个函数将fd_set中的所有bit清0，一般用来进行初始化等。
FD_CLR()这个函数用来将bitmap(fd_set )中的某个bit清0，在客户端异常退出时就会用到这个函数，将fd从fd_set中删除。
FD_ISSET()用来判断某个bit是否被置1了，也就是判断某个fd是否在fd_set中。
FD_SET()这个函数用来将某个fd加入fd_set中，当客户端新加入连接时就会使用到这个函数。

epoll_create系统调用用来创建epfd，会在开辟一块内存空间(epoll的结构空间)。size为epoll上能关注的最大描述符数，不够会进行扩展，size只要＞0就行，早期的设计size是固定大小，但是现在size参数没什么用，会自动扩展。
返回值是epfd，如果为-1则说明创建epoll对象失败 。

第一个参数epfd传入的就是epoll_create返回的epfd。
第二个参数传入对应操作的宏，包括 增删改(EPOLL_CTL_ADD、EPOLL_CTL_DEL、EPOLL_CTL_MOD) 。
第三个参数传入的是 需要增删改的socket的fd 。
第四个参数传入的是 需要操作的fd的哪些事件 ，具体的事件可以看后续。
返回值是一个int类型，如果为-1则说明操作失败 。

第一个参数是epfd，也就是epoll_create的返回值。
第二个参数是一个epoll_event类型的指针，也就是传入的是一个数组指针。 内核会将就绪的socket的事件拷贝到这个数组中，用户可以根据这个数组拿到事件和消息等 。
第三个参数是maxevents，传入的是 第二个参数的数组的容量 。
第四个参数是timeout， 如果设为-1一直阻塞直到有就绪数据为止，如果设为0立即返回，如果＞0那么阻塞一段时间 。
返回值是一个int类型，也就是就绪的socket的事件的数量(内核拷贝给用户的events的元素的数量)，通过这个数量可以进行遍历处理每个事件 。

一般需要传入 ev.data.fd 和 ev.events ，也就是fd和需要监控的fd的事件。事件如果需要传入多个，可以通过按位与来连接，比如需要监控读写事件，只需要像如下这样操作即可： ev.events=EPOLLIN | EPOLLOUT 。

LT(水平触发)， 默认 的工作模式， 事件就绪后用户可以选择处理和不处理，如果用户不处理，内核会对这部分数据进行维护，那么下次调用epoll_wait()时仍旧会打包出来 。
ET(边缘触发)，事件就绪之后， 用户必须进行处理 ，因为内核把事件打包出来之后就把对应的就绪事件给清掉了， 如果不处理那么就绪事件就没了 。ET可以减少epoll事件被重复触发的次数，效率比LT高。
如果需要设置为边缘触发只需要设置事件为类似 ev.events=EPOLLIN | EPOLLET 即可 。

select/poll/epoll是nio多路复用技术， 传统的bio无法实现C10K/C100K ，也就是无法满足1w/10w的并发量，在这么高的并发量下，在进行上下文切换就很容易将服务器的负载拉飞。

1.将fd_set从用户态拷贝到内核态
2.根据fd_set扫描内存中的socket的fd的状态，时间复杂度为O(n)
3.检查fd_set，如果有已经就绪的socket，就给对应的socket的fd打标记，那么就return 就绪socket的数量并唤醒当前线程，如果没有就绪的socket就继续阻塞当前线程直到有socket就绪才将当前线程唤醒。
4.如果想要获取当前已经就绪的socket列表，则还需要进行一次系统调用，使用O(n)的时间去扫描socket的fd列表，将已经打上标记的socket的fd返回。

CPU在同一个时刻只能执行一个程序，通过RR时间片轮转去切换执行各个程序。没有被挂起的进程(线程)则在工作队列中排队等待CPU的执行，将进程(线程)从工作队列中移除就是挂起，反映到Java层面的就是线程的阻塞。

什么是中断？当我们使用键盘、鼠标等IO设备的时候，会给主板一个电流信号，这个电流信号就给CPU一个中断信号，CPU执行完当前的指令便会保存现场，然后执行键盘/鼠标等设备的中断程序，让中断程序获取CPU的使用权，在中断程序后又将现场恢复，继续执行之前的进程。

如果第一次没检测到就绪的socket，就要将其进程(线程)从工作队列中移除，并加入到socket的等待队列中。

socket包含读缓冲区+写缓冲区+等待队列(放线程或eventpoll对象)

当从客户端往服务器端发送数据时，使用TCP/IP协议将通过物理链路、网线发给服务器的网卡设备，网卡的DMA设备将接收到的的数据写入到内存中的一块区域(网卡缓冲区)，然后会给CPU发出一个中断信号，CPU执行完当前指令则会保存现场，然后网卡的中断程序就获得了CPU的使用权，然后CPU便开始执行网卡的中断程序，将内存中的缓存区中的数据包拿出，判断端口号便可以判断它是哪个socket的数据，将数据包写入对应的socket的读(输入)缓冲区，去检查对应的socket的等待队列有没有等待着的进程(线程)，如果有就将该线程(进程)从socket的等待队列中移除，将其加入工作队列，这时候该进程(线程)就再次拥有了CPU的使用权限，到这里中断程序就结束了。

之后这个进程(线程)就执行select函数再次去检查fd_set就能发现有socket缓冲区中有数据了，就将该socket的fd打标记，这个时候select函数就执行完了，这时候就会给上层返回一个int类型的数值，表示已经就绪的socket的数量或者是发生了错误。这个时候就再进行内核态到用户态的切换，对已经打标记的socket的fd进行处理。

将原本1024bit长度的bitmap(fd_set)换成了数组的方式传入 ，可以 解决原本1024个不够用的情况 ，因为传入的是数组，长度可以不止是1024了，因此socket数量可以更多，在Kernel底层会将数组转换成链表。

在十多年前，linux2.6之前，不支持epoll，当时可能会选择用Windows/Unix用作服务器，而不会去选择Linux，因为select/poll会随着并发量的上升，性能变得越来越低，每次都得检查所有的Socket列表。

1.select/poll每次调用都必须根据提供所有的socket集合，然后就 会涉及到将这个集合从用户空间拷贝到内核空间，在这个过程中很耗费性能 。但是 其实每次的socket集合的变化也许并不大，也许就1-2个socket ，但是它会全部进行拷贝，全部进行遍历一一判断是否就绪。

2.select/poll的返回类型是int，只能代表当前的就绪的socket的数量/发生了错误， 如果还需要知道是哪些socket就绪了，则还需要再次使用系统调用去检查哪些socket是就绪的，又是一次O(n)的操作，很耗费性能 。

1.epoll在Kernel内核中存储了对应的数据结构(eventpoll)。我们可以 使用epoll_create()这个系统调用去创建一个eventpoll对象 ，并返回eventpoll的对象id(epfd)，eventpoll对象主要包括三个部分：需要处理的正在监听的socket_fd列表(红黑树结构)、socket就绪列表以及等待队列(线程)。

2.我们可以使用epoll_ctl()这个系统调用对socket_fd列表进行CRUD操作，因为可能频繁地进行CRUD，因此 socket_fd使用的是红黑树的结构 ，让其效率能更高。epoll_ctl()传递的参数主要是epfd(eventpoll对象id)。

3.epoll_wait()这个系统调用默认会 将当前进程(线程)阻塞，加入到eventpoll对象的等待队列中，直到socket就绪列表中有socket，才会将该进程(线程)重新加入工作队列 ，并返回就绪队列中的socket的数量。

socket包含读缓冲区、写缓冲区和等待队列。当使用epoll_ctl()系统调用将socket新加入socket_fd列表时，就会将eventpoll对象引用加到socket的等待队列中， 当网卡的中断程序发现socket的等待队列中不是一个进程(线程)，而是一个eventpoll对象的引用，就将socket引用追加到eventpoll对象的就绪列表的尾部 。而eventpoll对象中的等待队列存放的就是调用了epoll_wait()的进程(线程)，网卡的中断程序执行会将等待队列中的进程(线程)重新加入工作队列，让其拥有占用CPU执行的资格。epoll_wait()的返回值是int类型，返回的是就绪的socket的数量/发生错误，-1表示发生错误。

epoll的参数有传入一个epoll_event的数组指针(作为输出参数)，在调用epoll_wait()返回的同时，Kernel内核还会将就绪的socket列表添加到epoll_event类型的数组当中。

④ Redis和Memcached的区别

Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较：

1、Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。

2、内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。

3、性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。

具体为什么会出现上面的结论，以下为收集到的资料：

1、数据类型支持不同

与Memcached仅支持简单的key-value结构的数据记录不同，Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set。Redis内部使用一个redisObject对象来表示所有的key和value。redisObject最主要的信息如图所示：

type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int，如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:”123″ “456”这样的字符串。只有打开了Redis的虚拟内存功能，vm字段字段才会真正的分配内存，该功能默认是关闭状态的。

1）String

• 常用命令：set/get/decr/incr/mget等；

• 应用场景：String是最常用的一种数据类型，普通的key/value存储都可以归为此类；

• 实现方式：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。

2）Hash

• 常用命令：hget/hset/hgetall等

• 应用场景：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；

• 实现方式：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如图所示，Key是用户ID, value是一个Map。这个Map的key是成员的属性名，value是属性值。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。当前HashMap的实现有两种方式：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

3）List

• 常用命令：lpush/rpush/lpop/rpop/lrange等；

• 应用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；

• 实现方式：Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

4）Set

• 常用命令：sadd/spop/smembers/sunion等；

• 应用场景：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的；

• 实现方式：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

5）Sorted Set

• 常用命令：zadd/zrange/zrem/zcard等；

• 应用场景：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。

• 实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

2、内存管理机制不同

在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。Redis只会缓存所有的key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个操作，直到子线程完成swap操作后才可以进行修改。当从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。

对于像Redis和Memcached这种基于内存的数据库系统来说，内存管理的效率高低是影响系统性能的关键因素。传统C语言中的malloc/free函数是最常用的分配和释放内存的方法，但是这种方法存在着很大的缺陷：首先，对于开发人员来说不匹配的malloc和free容易造成内存泄露；其次频繁调用会造成大量内存碎片无法回收重新利用，降低内存利用率；最后作为系统调用，其系统开销远远大于一般函数调用。所以，为了提高内存的管理效率，高效的内存管理方案都不会直接使用malloc/free调用。Redis和Memcached均使用了自身设计的内存管理机制，但是实现方法存在很大的差异，下面将会对两者的内存管理机制分别进行介绍。

Memcached默认使用Slab Allocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以完全解决内存碎片问题。Slab Allocation机制只为存储外部数据而设计，也就是说所有的key-value数据都存储在Slab Allocation系统里，而Memcached的其它内存请求则通过普通的malloc/free来申请，因为这些请求的数量和频率决定了它们不会对整个系统的性能造成影响Slab Allocation的原理相当简单。 如图所示，它首先从操作系统申请一大块内存，并将其分割成各种尺寸的块Chunk，并把尺寸相同的块分成组Slab Class。其中，Chunk就是用来存储key-value数据的最小单位。每个Slab Class的大小，可以在Memcached启动的时候通过制定Growth Factor来控制。假定图中Growth Factor的取值为1.25，如果第一组Chunk的大小为88个字节，第二组Chunk的大小就为112个字节，依此类推。





当Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class，然后通过查询Memcached保存着的该Slab Class内空闲Chunk的列表就可以找到一个可用于存储数据的Chunk。当一条数据库过期或者丢弃时，该记录所占用的Chunk就可以回收，重新添加到空闲列表中。从以上过程我们可以看出Memcached的内存管理制效率高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。因为每个Chunk都分配了特定长度的内存空间，所以变长数据无法充分利用这些空间。如图 所示，将100个字节的数据缓存到128个字节的Chunk中，剩余的28个字节就浪费掉了。





Redis的内存管理主要通过源码中zmalloc.h和zmalloc.c两个文件来实现的。Redis为了方便内存的管理，在分配一块内存之后，会将这块内存的大小存入内存块的头部。如图所示，real_ptr是redis调用malloc后返回的指针。redis将内存块的大小size存入头部，size所占据的内存大小是已知的，为size_t类型的长度，然后返回ret_ptr。当需要释放内存的时候，ret_ptr被传给内存管理程序。通过ret_ptr，程序可以很容易的算出real_ptr的值，然后将real_ptr传给free释放内存。

Redis通过定义一个数组来记录所有的内存分配情况，这个数组的长度为ZMALLOC_MAX_ALLOC_STAT。数组的每一个元素代表当前程序所分配的内存块的个数，且内存块的大小为该元素的下标。在源码中，这个数组为zmalloc_allocations。zmalloc_allocations[16]代表已经分配的长度为16bytes的内存块的个数。zmalloc.c中有一个静态变量used_memory用来记录当前分配的内存总大小。所以，总的来看，Redis采用的是包装的mallc/free，相较于Memcached的内存管理方法来说，要简单很多。

3、数据持久化支持

Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。而memcached是不支持数据持久化操作的。

1）RDB快照

Redis支持将当前数据的快照存成一个数据文件的持久化机制，即RDB快照。但是一个持续写入的数据库如何生成快照呢？Redis借助了fork命令的 on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。我们可以通过Redis的save指令来配置RDB快照生成的时机，比如配置10分钟就生成快照，也可以配置有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中，你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的。

2）AOF日志

AOF日志的全称是append only file，它是一个追加写入的日志文件。与一般数据库的binlog不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。只有那些会导致数据发生修改的命令才会追加到AOF文件。每一条修改数据的命令都生成一条日志，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的AOF文件取代老的AOF文件。

AOF是一个写文件操作，其目的是将操作日志写到磁盘上，所以它也同样会遇到我们上面说的写操作的流程。在Redis中对AOF调用write写入后，通过appendfsync选项来控制调用fsync将其写到磁盘上的时间，下面appendfsync的三个设置项，安全强度逐渐变强。

• appendfsync no 当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。

• appendfsync everysec 当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。所以结论就是，在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。

• appednfsync always 当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。

对于一般性的业务需求，建议使用RDB的方式进行持久化，原因是RDB的开销并相比AOF日志要低很多，对于那些无法忍数据丢失的应用，建议使用AOF日志。

4、集群管理的不同

Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说，机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小，就需要构建分布式集群来扩展存储能力。

Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。下图给出了Memcached的分布式存储实现架构。当客户端向Memcached集群发送数据之前，首先会通过内置的分布式算法计算出该条数据的目标节点，然后数据会直接发送到该节点上存储。但客户端查询数据时，同样要计算出查询数据所在的节点，然后直接向该节点发送查询请求以获取数据。





相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。最新版本的Redis已经支持了分布式存储功能。Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本，它没有中心节点，具有线性可伸缩的功能。下图给出Redis Cluster的分布式存储架构，其中节点与节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。在数据的放置策略上，Redis Cluster将整个key的数值域分成4096个哈希槽，每个节点上可以存储一个或多个哈希槽，也就是说当前Redis Cluster支持的最大节点数就是4096。Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER。






为了保证单点故障下的数据可用性，Redis Cluster引入了Master节点和Slave节点。在Redis Cluster中，每个Master节点都会有对应的两个用于冗余的Slave节点。这样在整个集群中，任意两个节点的宕机都不会导致数据的不可用。当Master节点退出后，集群会自动选择一个Slave节点成为新的Master节点。

⑤ 程序员打基础必看书籍！

1、《深入理解计算机系统》
从c语言到汇编语言到硬件再到操作系统，写得非常好。是一本能帮助深入理解计算机系统的书。基本上把这本书吃透面试操作系统的大部分问题都不是问题。
2、《算法导论(第三版)》
被很多acmer coder奉为学算法的经典之作，但不太适合初学者，因为它这本书很多内容只提供了伪代码，而没有具体实现。但可以从这本书学数据结构和算法好，因为日后的编程语言对实现而言实际上并没有特别大的障碍，只是适合与不适合的选择罢了，而把想法转换成编程语言才是对算法知识的考验。如果不想太过深入的话可以忽略掉第四部分(高级设计和分析技术)第五部分(高级数据结构)和第七部分(算法问题选编)，你会发现书其实比你想象中薄很多噢！
3、《计算机网络:自顶向下方法》
软件学院的计算机网络教材，非常适合初学者，里面将计算机网络从顶层到底层逐章分析了一遍，如果能够结合一些实验来辅助理解会更好，因为里面的讲解比较抽象。
4、《STL源码剖析》
如果你是经常用c++刷算法题的同学，那么一定经常用STL的各种集合， vector， set， stack， queue等等。它们的实现原理，在源码面前，完全没有秘密。
5、《图解HTTP》
日本人着的介绍HTTP协议的书，对理解HTTP协议的一些细节有非常大的帮助，插画也很多，感觉就像看漫画一样，很容易理解的。
6、《TCP/IP详解卷一》
这本书能把枯燥的知识讲得很细致，强烈推荐这本，看完相应章节后大概能够明白为什么TCP/IP要这么设计了。面试的时候经常问到三次握手和四次挥手，还有各种状态的转移， TIME_WAIT的时间为什么是2*MSL······
7、《UNIX网络编程卷一:套接字联网API(第三版)》
中文版快800页，不过我只看了一些章节，这本书也是把TCP/IP的细节讲得很深很深，此外还有非常重要的基本套接字编程，就是写网络程序的时候那些bind， accept， listen， send， receive函数之类的，内容非常多，但是这些是理解多路复用模型所需要掌握的······select/poll/epoll这些系统调用解决了什么问题？事件机制能不能理解？就看这本书的前六章了。
8、《数据库管理系统(原理与设计)》
这个也是web开发中离不开的东西，必须划重点学会的是ER图/SQL语句/存储数据(磁盘|文件|RAID|缓冲池等)/三大范式/索引以及相应的数据结构/事务相关的所有概念，尤其重点学习SQL 。之后学会使用mysql workbench来进行数据库建模/逆向工程生成建表语句/根据SQL生成JAVA实体类等就不赘述了，开发过程中网络谷歌一下就知道啦，然后如果习惯在windows下开发的同学推荐利用navicat这个好东西。

⑥ 为什么epoll里的read函数每次都只能读一小片数据

Linux平台上，Nginx使用epoll完成事件驱动，实现高并发；本文将不对epoll本身进行介绍（网上一堆一堆的文章介绍epoll的原理及使用方法，甚至源码分析等），仅看一下Nginx是如何使用epoll的。 Nginx在epoll模块中定义了好几个函

⑦ linux epoll源码哪个包

#include #include /* basic system data types */#include /* basic socket definitions */#include /* sockaddr_in{} and other Internet defns */#include /* inet(3) functions */#include /* epoll function */#include /* nonblocking */#...

⑧ .nginx第一次的启动的时候会创建哪些文件

nginx是个多进程web容器，不同的配置下它的启动方式也是不同的，这里我只说说最典型的启动方式。
它有1个master进程，和多个worker进程（最优配置的数量与CPU核数相关）。那么，首先我们要找到main函数，它在src/core/nginx.c文件中。谈到源码了，这时我们先简单看下源码的目录结构吧。
nginx主要有下列目录：
src/core，这个目录存放了基础的数据结构像LIST、红黑树、nginx字符串，贯穿始终的一些逻辑结构如ngx_cycle_s、ngx_connection_s等，还有对一些底层操作的封装如log、文件操作、共享内存、内存池等，最后还有个nginx.c这个main启动函数了。
src/event，这个目录下存放与抽象事件相关的结构和钩子函数。nginx是以事件驱动处理流程的，事件自然是整个体系的核心了，这里定义了最核心的ngx_event_s结构。
src/event/moles目录存放了具体的种种事件驱动方式，例如epoll、kqueue、poll、aio、select等，它们通过ngx_event_actions_t结构体中的钩子挂在nginx中。nginx启动时会根据配置来决定使用哪种实现方式。
src/os/unix中存放了unix系统下许多函数调用的UNIX实现。
src/http目录存放到http mole的相关实现，这个mole负责处理http请求，包括协议的解析以及访问backend server的代码。
src/http/mole目录存放http mole类型的一些特定用途的mole，比如gzip处理加密，图片压缩等。
有个初步了解后，回到main函数中，顺序看看我们感兴趣的事情。它先执行了ngx_time_init，为什么要初始化时间呢？nginx考虑的还是很周到的，取系统时间gettimeofday是系统调用，这意味着，需要发送中断给linux内核，内核需要做进程间切换来处理这个调用。这是一个不能忽视成本的函数。nginx封装了时间函数，这样，每次我们需要处理时间时，并不是调用gettimeofday，而是nginx自己缓存的时间，这样大量减少了系统调用，取当前时间这事可是谁都爱干的。
那么，nginx是怎么维护自己的这个时钟呢？如何保证用户取到的当前时间是有意义的？nginx设计者的出发点是，nginx是事件驱动机制，当一批事件发生时，也就是epoll_wait返回时，会取一次gettimeofday来更新自己的时间，然后调用各个事件对应的处理函数。这些函数都会保证自己是无阻塞的，也就是毫秒级的处理能力，所以，在任何一个事件处理函数中，取到的时间都是之前epoll_wait刚返回时取到的时间，这样，即使拿到的时间慢了几毫秒也无所谓。关键是，每个函数都是无阻塞的，都要迅速的把控制权交还给nginx，这是基本设计原则哈。

⑨ java自学到什么程度就能找工作了

很多同学都关心Java学到什么程度才可以找到满意的工作。大家的目标都很明确，也很实在，学习Java无非就是为了找工作。

那到底要学多少Java知识，掌握多少技能，才可以找到一份满意的工作呢？

其实想要找一份小公司的开发工作不算非常难，毕竟互联网公司很多，要求也是天差地别，对技术、学历、实践能力的要求和评价标准也有很大的差距。但是进大厂的要求可就非常高了。

所以，到底Java学到什么程度才能找到第一份工作，我想应该用公司来作为变量，这样回答这个问题才有意义。

1、中小型公司

说到中小型公司，我们泛指那些500名以下员工，有稳定资金来源并且可以自我造血的公司，这类公司招聘和培训可能会有自己的一套标准。

比如学历上可能稍微做一些要求，技术上的把关更严格一点，除了Java基础知识和项目经历之外，可能还会考查你的debug能力，代码规范、异常处理能力，以及对一些Java高级特性的理解能力，以及框架的应用水平。

总而言之，这类公司选人的标准更加有体系，标准也更高。

2、二三线互联网公司

这类公司范围就很广了，比如搜狐、新浪、360、携程这类现状比较不错的企业等等，这类公司挤不到BAT TMD等一线互联网行列，但是在二三线阵容还算是比较不错的公司，它们对于人才的要求其实还是相对比较高的。

比如一般都会要求本科学历，对Java基础知识要比较熟悉，最好能够看过源码，如果没看过，那么源码方面的面试题好歹也要准备一下，除此之外，一般来说还会考察你的后端技术知识，比如数据库、网络、操作系统，考察的不会太难，能把面经上的知识点掌握了就算是比较扎实了。

这类公司一般不会考太复杂的题目，更希望招一些水平能力都是中上等的人才，只要知识面能比较广，题目都能说到点子上，也可以有机会拿到offer。

3、一线互联网公司

BAT、TMD等互联网名企都属于这类公司，这类公司和二三线互联网公司的发展差距还是比较大的，体现在公司的规模、市值、甚至是股价等方面，业务以技术为基础，因此这些公司的技术往往也是业界最顶尖的，比如阿里的云计算和中间件，头条的推荐算法、腾讯的游戏技术等等。

要进这些公司，不仅要做到之前那些事情：掌握Java基础、计算机基础知识，并且是非常熟练地掌握，你需要深入理解每一个知识点，因为面试官会不断深入地向你提问，了解你的知识深度，同时，你需要对源码有所理解，在读懂源码的基础上去理解框架的实现、JDK的实现。

并且，你还需要对Java并发编程和网络编程的使用方法与底层实现原理非常熟悉，不仅仅答出NIO和BIO的区别，或者是synchronized和lock的区别，你还需要知道NIO的底层实现epoll是什么，synchronized对应的mutex lock是什么，lock和condition的实现原理又是什么，而lock本身也是通过AQS、CAS操作类等组件来实现的，其中的内容实在太多，绝不只是几道面试题就可以搞定的。

当然，除此之外，这些公司对数据库、缓存、分布式技术等方面的要求都会比其他公司要高得多，你最好要搞懂MySQL的存储引擎、索引和锁的实现原理，Redis缓存的数据结构、备份方式、底层实现。

同时如果你能理解负载均衡算法、CAP理论，甚至是raft和paxos算法，以及分布式常用技术如消息队列、zookeeper等等，那么无疑也是可以为你加分的技能。

分享下学习路线，按照上面的路线学习，学完后找到工作不成问题！

世上无难事，只怕有心人，只要你真的想学并努力去学，你就能成功。

另外，如果自学没有资料的话，可私聊我获取，免费提供哦~

希望能帮到你，望采纳！