Web服务器
Web服务器也称为WWW(WORLD WIDE WEB)服务器，主要功能是提供网上信息浏览服务。
- 应用层使用HTTP协议。
- HTML文档格式。
- 浏览器统一资源定位器(URL)。
Web服务器常常以B/S（Browser/Server）方式提供服务。
- 浏览器向服务器发出HTTP请求(Request)。
- 服务器收到浏览器的请求数据，经过分析处理，向浏览器输出响应数据（Response）。
- 浏览器收到服务器的响应数据，经过分析处理，将最终结果显示在浏览器中。
Apache
Apache软件基金会的一个开放源代码的网页服务器，可以在大多数计算机操作系统中运行，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充，将Perl／Python等解释器编译到服务器中。
Apache是基于模块化设计的，它的核心代码并不多，大多数的功能都被分散到各个模块中，各个模块在系统启动的时候按需载入。
MPM（Multi -Processing Modules，多重处理模块）是Apache的核心组件之一，Apache通过MPM来使用操作系统的资源，对进程和线程池进行管理。Apache为了能够获得最好的运行性能，针对不同的平台 (Unix/Linux、Window)做了优化，为不同的平台提供了不同的MPM，用户可以根据实际情况进行选择，其中最常使用的MPM有 prefork和worker两种。至于您的服务器正以哪种方式运行，取决于安装Apache过程中指定的MPM编译参数,在X系统上默认的编译参数为 prefork。
由于大多数的Unix都不支持真正的线程，所以采用了预派生子进程(prefork)方式，象Windows或者Solaris这些支持 线程的平台，基于多进程多线程混合的worker模式是一种不错的选择。Apache中还有一个重要的组件就是APR（Apache portable Runtime Library），即Apache可移植运行库，它是一个对操作系统调用的抽象库，用来实现Apache内部组件对操作系统的使用，提高系统的可移植性。 Apache对于php的解析，就是通过众多Module中的php Module来完成的。
Apache的工作模式
prefork的工作原理
一个单独的控制进程(父进程)负责产生子进程，这些子进程用于监听请求并作出应答。Apache总是试图保持一些备用的 (spare)或是空闲的子进程用于迎接即将到来的请求。这样客户端就无需在得到服务前等候子进程的产生。在Unix系统中，父进程通常以root身份运行以便邦定80端口，而 Apache产生的子进程通常以一个低特权的用户运行。User和Group指令用于配置子进程的低特权用户。运行子进程的用户必须要对他所服务的内容有读取的权限，但是对服务内容之外的其他资源必须拥有尽可能少的权限。
worker的工作原理
每个进程能够拥有的线程数量是固定的。服务器会根据负载情况增加或减少进程数量。一个单独的控制进程(父进程)负责子进程的建立。每个子进程能够建立ThreadsPerChild数量的服务线程和一个监听线程，该监听线程监听接入请求并将其传递给服务线程处理和应答。Apache总是试图维持一个备用(spare)或是空闲的服务线程池。这样，客户端无须等待新线程或新进程的建立即可得到处理。在Unix中，为了能够绑定80端口，父进程一般都是以root身份启动，随后，Apache以较低权限的用户建立子进程和线程。User和Group指令用于配置Apache子进程的权限。虽然子进程必须对其提供的内容拥有读权限，但应该尽可能给予他较少的特权。另外，除非使用了suexec ，否则，这些指令配置的权限将被CGI脚本所继承。
启动阶段
在启动阶段，Apache主要进行配置文件解析(例如http.conf以及Include指令设定的配置文件等)、模块加载(例如mod_php.so,mod_perl.so等)和系统资源初始化（例如日志文件、共享内存段等）工作。在这个阶段，Apache为了获得系统资源最大的使用权限，将以特权用户root（X系统）或超级管理员administrator(Windows系统)完成启动。
运行阶段
在运行阶段，Apache主要工作是处理用户的服务请求。在这个阶段，Apache放弃特权用户级别，使用普通权限，这主要是基于安全性的考虑，防止由于代码的缺陷引起的安全漏洞。
由于Apache的Hook机制，Apache 允许模块(包括内部模块和外部模块，例如mod_php5.so,mod_perl.so等)将自定义的函数注入到请求处理循环中。mod_php5.so/php5apache2.dll就是将所包含的自定义函数，通过Hook机制注入到Apache中，在Apache处理流程的各个阶段负责处理php请求。
Apache将请求处理循环分为11个阶段，依次是：Post-Read-Request，URI Translation，Header Parsing，Access Control，Authentication，Authorization，MIME Type Checking，FixUp，Response，Logging，CleanUp。
- Post-Read-Request阶段:在正常请求处理流程中，这是模块可以插入钩子的第一个阶段。对于那些想很早进入处理请求的模块来说，这个阶段可以被利用。
- URI Translation阶段 : Apache在本阶段的主要工作：将请求的URL映射到本地文件系统。模块可以在这阶段插入钩子，执行自己的映射逻辑。mod_alias就是利用这个阶段工作的。
- Header Parsing阶段 : Apache在本阶段的主要工作：检查请求的头部。由于模块可以在请求处理流程的任何一个点上执行检查请求头部的任务，因此这个钩子很少被使用。mod_setenvif就是利用这个阶段工作的。
- Access Control阶段 : Apache在本阶段的主要工作：根据配置文件检查是否允许访问请求的资源。Apache的标准逻辑实现了允许和拒绝指令。mod_authz_host就是利用这个阶段工作的。
- Authentication阶段 : Apache在本阶段的主要工作：按照配置文件设定的策略对用户进行认证，并设定用户名区域。模块可以在这阶段插入钩子，实现一个认证方法。
- Authorization阶段 : Apache在本阶段的主要工作：根据配置文件检查是否允许认证过的用户执行请求的操作。模块可以在这阶段插入钩子，实现一个用户权限管理的方法。
- MIME Type Checking阶段 : Apache在本阶段的主要工作：根据请求资源的MIME类型的相关规则，判定将要使用的内容处理函数。标准模块mod_negotiation和mod_mime实现了这个钩子。
- FixUp阶段 : 这是一个通用的阶段，允许模块在内容生成器之前，运行任何必要的处理流程。和Post_Read_Request类似，这是一个能够捕获任何信息的钩子，也是最常使用的钩子。
- Response阶段 : Apache在本阶段的主要工作：生成返回客户端的内容，负责给客户端发送一个恰当的回复。这个阶段是整个处理流程的核心部分。
- Logging阶段 : Apache在本阶段的主要工作：在回复已经发送给客户端之后记录事务。模块可能修改或者替换Apache的标准日志记录。
- CleanUp阶段 : Apache在本阶段的主要工作：清理本次请求事务处理完成之后遗留的环境，比如文件、目录的处理或者Socket的关闭等等，这是Apache一次请求处理的最后一个阶段。
nginx
轻量级的Web服务器、反向代理服务器，优势在于内存占用少，启动极快，高并发能力强
工作原理
Nginx由内核和模块组成。
Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。
Nginx的模块从结构上分为核心模块、基础模块和第三方模块：
核心模块：HTTP模块、EVENT模块和MAIL模块
基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块，
第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。
Nginx的模块从功能上分为如下三类：
Handlers（处理器模块）。此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
Filters （过滤器模块）。此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
Proxies （代理类模块）。此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。
热部署
Nginx默认采用多进程工作方式，Nginx启动后，会运行一个master进程和多个worker进程。其中master充当整个进程组与用户的交互接口，同时对进程进行监护，管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。worker用来处理基本的网络事件，worker之间是平等的，他们共同竞争来处理来自客户端的请求。
修改配置文件nginx.conf后，重新生成新的worker进程，会以新的配置进行处理请求，而且新的请求必须都交给新的worker进程，在把老的worker进程那些以前的请求处理完毕后，kill掉，实现配置热更新
互斥锁
在创建master进程时，先建立需要监听的socket（listenfd），然后从master进程中fork()出多个worker进程，如此一来每个worker进程多可以监听用户请求的socket。一般来说，当一个连接进来后，所有在Worker都会收到通知，但是只有一个进程可以接受这个连接请求，其它的都失败，这是所谓的惊群现象。nginx提供了一个accept_mutex（互斥锁），有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。
先打开accept_mutex选项，只有获得了accept_mutex的进程才会去添加accept事件。nginx使用一个叫ngx_accept_disabled的变量来控制是否去竞争accept_mutex锁。ngx_accept_disabled = nginx单进程的所有连接总数 / 8 -空闲连接数量，当ngx_accept_disabled大于0时，不会去尝试获取accept_mutex锁，ngx_accept_disable越大，于是让出的机会就越多，这样其它进程获取锁的机会也就越大。不去accept，每个worker进程的连接数就控制下来了，其它进程的连接池就会得到利用，这样，nginx就控制了多进程间连接的平衡。
每个worker进程都有一个独立的连接池，连接池的大小是worker_connections。这里的连接池里面保存的其实不是真实的连接，它只是一个worker_connections大小的一个ngx_connection_t结构的数组。并且，nginx会通过一个链表free_connections来保存所有的空闲ngx_connection_t，每次获取一个连接时，就从空闲连接链表中获取一个，用完后，再放回空闲连接链表里面。一个nginx能建立的最大连接数，应该是worker_connections * worker_processes。当然，这里说的是最大连接数，对于HTTP请求本地资源来说，能够支持的最大并发数量是worker_connections * worker_processes，而如果是HTTP作为反向代理来说，最大并发数量应该是worker_connections * worker_processes/2。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。
Nginx处理HTTP请求流程
http请求是典型的请求-响应类型的的网络协议。http是文件协议，所以我们在分析请求行与请求头，以及输出响应行与响应头，往往是一行一行的进行处理。通常在一个连接建立好后，读取一行数据，分析出请求行中包含的method、uri、http_version信息。然后再一行一行处理请求头，并根据请求method与请求头的信息来决定是否有请求体以及请求体的长度，然后再去读取请求体。得到请求后，我们处理请求产生需要输出的数据，然后再生成响应行，响应头以及响应体。在将响应发送给客户端之后，一个完整的请求就处理完了。
proxy_pass
代理转发,当被代理的机器有多台时，需要使用upstream来定义一个服务器组，如www
其中www名字可以自定义，在后面的proxy_pass那里引用
upstream
负载均衡，指定一个组及关联的server服务端，可以再根据需求增加负载策略（IPHASH、加权论调、最少连接），之后在后面的server规则下配置proxy_pass时指向该服务组即可
高并发原理
Nginx采用了Linux的epoll模型，epoll模型基于事件驱动机制，它可以监控多个事件是否准备完毕，如果OK，那么放入epoll队列中，这个过程是异步的。worker只需要从epoll队列循环处理即可。
epoll 模型原理理解
首先，epoll是linux系统本身具备的一个功能，nginx只是借助于linux系统实现了高效处理IO事件
epoll的逻辑是，对于一个要执行处理的对象（linux把它视为一个文件描述符），epoll可以给这个文件描述符增加一些事件标识，如读、写、异常等，再交由系统底层的红黑树进行管理，那么，对于用户来说，就可以理解为是否就绪，下一步，网卡回调机制会将已经就绪的文件描述符插入到就绪队列，这样，nginx所在主机的系统在本地可以遍历就绪队列从而确认哪些文件描述符已经就绪，确认就绪后，再远程过去一次性取出。从而规避掉了让系统内核去不断轮询服务端导致IO阻塞的情况发生。
缓存
Nginx缓存可作为性能优化的一个重要手段，可以极大减轻后端服务器的负载。
缓存，是Nginx提供的，可以加快访问速度的机制，说白了，在配置上就是一个开启，同时指定目录，让缓存可以存储到磁盘上。
Nginx设置缓存有两种方式：
proxy_cache_path和proxy_cache
Cache-Control和Pragma
Nginx配合PHP工作的FastCGI工作原理
FastCGI的方式是，web服务器收到一个请求时，他不会重新fork一个进程（因为这个进程在web服务器启动时就开启了，而且不
会退出），web服务器直接把内容传递给这个进程（进程间通信，但fastcgi使用了别的方式，tcp方式通信），这个进程收到请求后
进行处理，把结果返回给web服务器，最后自己接着等待下一个请求的到来，而不是退出。
fastcgi 跟 cgi 的区别
|
名称 |
在web服务器方面 |
在对数据处理的进程方面 |
|
cgi |
fork一个新进程进行处理 |
读取参数，处理数据，然后就结束生命周期 |
|
FastCgi |
用tcp跟进程建立连接 |
开启TCP端口，进入循环，等待数据处理 |
Apache和Nginx比较
功能对比
Nginx和Apache一样，都是HTTP服务器软件，在功能实现上都采用模块化结构设计，都支持通用的语言接口，如PHP、Perl、Python等，同时还支持正向和反向代理、虚拟主机、URL重写、压缩传输、SSL加密传输等。
- 在功能实现上，Apache的所有模块都支持动、静态编译，而Nginx模块都是静态编译的，
- 对FastCGI的支持，Apache对Fcgi的支持不好，而Nginx对Fcgi的支持非常好；
- 在处理连接方式上，Nginx支持epoll，而Apache却不支持；
- 在空间使用上，Nginx安装包仅仅只有几百K，和Nginx比起来Apache绝对是庞然大物。
Nginx相对apache的优点
- 轻量级，同样起web 服务，比apache 占用更少的内存及资源
- 静态处理，Nginx 静态处理性能比 Apache 高 3倍以上
- 抗并发，nginx 处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能。在Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。
- 高度模块化的设计，编写模块相对简单
- 社区活跃，各种高性能模块出品迅速啊
apache相对nginx的优点
- rewrite，比nginx 的rewrite 强大
- 模块超多，基本想到的都可以找到
- 少bug，nginx的bug相对较多
- 超稳定
- Apache对PHP支持比较简单，Nginx需要配合其他后端用
关于性能优势的理解
传统上基于进程或线程模型架构的web服务通过每进程或每线程处理并发连接请求，这势必会在网络和I/O操作时产生阻塞，其另一个必然结果则是对内存或CPU的利用率低下。生成一个新的进程/线程需要事先备好其运行时环境，这包括为其分配堆内存和栈内存，以及为其创建新的执行上下文等。这些操作都需要占用CPU，而且过多的进程/线程还会带来线程抖动或频繁的上下文切换，系统性能也会由此进一步下降。另一种高性能web服务器/web服务器反向代理：Nginx（Engine X），nginx的主要着眼点就是其高性能以及对物理计算资源的高密度利用，因此其采用了不同的架构模型。受启发于多种操作系统设计中基于“事件”的高级处理机制，nginx采用了模块化、事件驱动、异步、单线程及非阻塞的架构，并大量采用了多路复用及事件通知机制。在nginx中，连接请求由为数不多的几个仅包含一个线程的进程worker以高效的回环(run-loop)机制进行处理，而每个worker可以并行处理数千个的并发连接及请求。
apache是同步，nginx是异步，在处理事务上显然是nginx更好一点，也更能处理事务的并发。也有很多人认为是nginx反向代理所以会比apache更好处理并发，其实不是的，单纯的反向代理模式并不能提高性能，后端收到的请求数没变，协议也没变，带宽也没有减小，而且如果是默认配置，还会把HTTP/1.1变成HTTP/1.0，反而会降低性能，那些说性能提高的通常也没测过，只是个心理作用而已。
Tomcat
Web应用服务器，属于轻量级应用服务器，适合中小型系统和并发访问用户不是很多的场合
JVM 参数配置
catalina.sh添加：
JAVA_OPTS=’-Xms512m -Xmx1024m’要加“m”说明是MB，否则就是KB了，在启动tomcat时会 报内存不足。
-Xms：初始值-Xmx：最大值-Xmn：最小值
NoSQL数据库
非关系型数据库，区别于Mysql等关系型数据库（关系型数据库，是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成库。），去掉了关系数据库的关系型特性，数据之间无关系，这样就非常容易扩展。
Redis
Redis是单线程模式的NoSQL，但是由于采用了网络IO多路复用技术的epoll模型，使用的是IO多路复用中的异步IO非阻塞模型，即轮询的方式同时处理多个请求，并采用异步IO方式，不因为某一个请求的阻塞而阻塞掉整个线程，从而提高了整体效率
Redis 主从原理
主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段
通过SYNC命令建立连接，建立连接后，通过RDB方式master将数据同步给slave，数据保持一致后，新数据的变化再通过发送缓存命令给slave实现实时同步
配置实现：
slaveof <masterip> <masterport>
RDB快照原理
fork函数复制当前主进程的副本作为子进程，由子进程单独处理快照文件生成，实现方式就是把内存数据写入磁盘临时文件，而主进程继续处理数据请求。
Redis 哨兵模式
哨兵，英文名sentinel,是一个分布式系统，用于对主从结构中的每一台服务器进行监控，当主节点出现故障后通过投票机制来挑选新的主节点，并且将所有的从节点连接到新的主节点上
配置文件核心
sentinel monitor mymaster 127.0.0.1 6379 2
原理：
多个 sentinel 进程组成分布式的架构，负责持续监控主从节点的健康状况，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。
Redis Cluster 集群
cluster的目的，是为了解决单台服务器的内存空间有限，无法容纳海量数据的情况，通过分布式共用多台服务器的内存资源，组成内存资源池，从而提高数据容量
针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster
基于hash slot算法，实现数据在所有节点的均匀分布
Memcached
memcached的设计思路是预先分配内存空间资源，拿空间换时间，实现速度的提高
Memcached服务器端（server）和客户端（client）组成，client先通过计算key的hash值来确定kv对所处在的server位置，实现分布式，当hash表满了之后，新的插入数据会替代老的数据，更新的策略是LRU（最近最少使用）
Memcached采用master-worker多线程工作模式，为每个任务创建单独的worker，再由master去调度并响应客户端命令请求
memcached高可用
由于memcached本身不支持多个服务端互相通信，存在单点问题，故可以采用Magent 代理多台缓存服务器方式，实现分布式集群
Redis和Memcached区别
|
对比内容 |
具体阐述 |
|
内存空间和数据量大小 |
Memcached可以修改最大内存，采用LRU算法，Redis增加了VM的特性，突破了物理内存的限制 |
|
性能 |
平均每一个核Redis在存储小数据时比Memcached性能更高，100k以上时Memcached性能高于redis |
|
操作方便性 |
MemCached结构数据单一，仅支持key-value数据类型 Redis支持更加丰富的数据类型，如list，set，hash，也可以在服务器端进行丰富的操作，减少网络IO次数和数据体积 |
|
可靠性 |
Memcached不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的， Redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价 |
|
应用场景 |
Memcached：动态系统中减轻数据库的负载，提升性能，作缓存，适合多读少写，大数据量的情况 Redis：适用于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统 |
|
单个key-value的大小 |
Memcached最大支持1MB；Redis最大支持512MB |
MongoDB
MongoDB 基本的概念是文档、集合、数据库，将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。
MongoDB 区别于redis memcached的map，是通过数据库存储管理kv集合，通过json的方式操作数据，类似下面这样
>> use test_db
>> db.createCollection(“mycol”, { capped : true, autoIndexID : true, size : 6142800, max : 10000 } )
Kafka Zookeeper
- kafka由Producer、Broker、Consumer以及ZooKeeper几个组件组成，broker负责接受Producer和Consumer的请求，并把消息持久化到本地磁盘。
- Broker以topic为单位将消息分成不同的分区（partition），每个分区可以有多个副本，通过数据冗余的方式实现容错。
- 每个分区中的消息被赋予了唯一整数标识，称之为偏移量offset，记录已消费的消息，避免重复读取，由Consumer各自维护当前进度
- kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。
- 生产者通过监听zookeeper上Broker节点感知Broker，Topic的状态，变更，来实现动态负载均衡机制
对象存储
Minio
- Minio 非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T不等。
- Minio使用纠删码erasure code和校验和checksum。 即便丢失一半数量（N/2）的硬盘，仍然可以恢复数据。
- Minio支持云原生，能与Kubernetes、Docker、Swarm编排系统良好对接，实现灵活部署
- Minio采用去中心化的无共享架构，对象数据被打散存放在不同节点的多块硬盘，对外提供统一命名空间访问，并通过负载均衡或者DNS轮询在各个服务器之间实现负载均衡
- Minio对象存储系统把存储资源组织为租户-桶-对象的形式
FastDFS
FastDFS服务端由跟踪器（tracker）和存储节点（storage）构成。跟踪器主要做调度工作，在访问上起负载均衡的作用。
存储节点存储文件时，FastDFS同时对文件的meta data进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key value pair）方式表示，文件meta data是文件属性列表，可以包含多个键值对。
FastDFS将存储节点服务器通过分卷的形式进行组织，在卷中增加服务器时，同步已有的文件由FastDFS自动完成
日志分析系统
ELK Stack
Elasticsearch
基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎,通过对索引分配分片部署到多个节点的方式实现分布式搜索
ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，可以提高查询速度
传统的关系数据库提供事务保证，具有不错的性能，高可靠性，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。
后来，随着访问量的上升，几乎大部分使用 MySQL 架构的网站在数据库上都开始出现了性能问题，web 程序不再仅仅专注在功能上，同时也在追求性能。
倒排索引，也常被称为反向索引，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射，它是文档检索系统中最常用的数据结构。
https://www.jianshu.com/p/52b92f1a9c47
logstash
logstash分为三个步骤：inputs（必须的）→ filters（可选的）→ outputs（必须的），inputs生成时间，filters对其事件进行过滤和处理，outputs输出到输出端或者决定其存储在哪些组件里。inputs和outputs支持编码和解码
Logstash管道中的每个input阶段都在自己的线程中运行。将写事件输入到内存（默认）或磁盘上的中心队列。每个管道工作线程从该队列中取出一批事件，通过配置的filter处理该批事件，然后通过output输出到指定的组件存储。管道处理数据量的大小和管道工作线程的数量是可配置的
filebeat
Filebeat结构：由两个组件构成，分别是inputs（输入）和harvesters（收集器），这些组件一起工作来跟踪文件并将事件数据发送到您指定的输出，harvester负责读取单个文件的内容。harvester逐行读取每个文件，并将内容发送到输出。为每个文件启动一个harvester。harvester负责打开和关闭文件，这意味着文件描述符在harvester运行时保持打开状态。如果在收集文件时删除或重命名文件，Filebeat将继续读取该文件。这样做的副作用是，磁盘上的空间一直保留到harvester关闭。默认情况下，Filebeat保持文件打开，直到达到close_inactive
filbeat不会丢失数据，它将每个事件的传递状态存储在注册表文件中。在已定义的输出被阻止且未确认所有事件的情况下，Filebeat将继续尝试发送事件，直到输出确认已接收到事件为止。
原文链接：https://blog.51cto.com/zerry/4303409
