常用的服务器软件有哪些

RabbitMQ,遵循AMQP协议，由内在高并发的erlang语言开发，用在实时的对可靠性要求比较高的消息传递上。
kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。
1)在架构模型方面，
RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制。
kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。
2)在吞吐量，
kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量 *** 作，具有O(1)的复杂度，消息处理的效率很高。
rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的 *** 作；基于存储的可靠性的要求存储可以采用内存或者硬盘。
3)在可用性方面，
rabbitMQ支持miror的queue，主queue失效，miror queue接管。
kafka的broker支持主备模式。
4)在集群负载均衡方面，
kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。
rabbitMQ的负载均衡需要单独的loadbalancer进行支持。
所以关于这两个选择，我们还是了解了这4个大致的区别。关于高吞吐，以及我们队日志的特定场景分析，任然选择了，kafka。当然设计理念不一样，rabbitMQ用于可靠的消息传递，智齿事物，不支持批量的 *** 作，可用性差不多，只是实现不一样。在集群方面，kafka胜一筹，通过topic注册zookeeper，调用机制，实现语义指定分片，然而rabbitMQ的负载需要单独loadbalancer支持
————————————————
版权声明：本文为CSDN博主「大壮vip」的原创文章，遵循 CC 40 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：>0基础架构：

说明：filebeat日志直接传送给es，直接从界面查看日志

1架构图

使用filebeat收集日志直接写入kafka，然后再由logstash从kafka读取写到elasticsearch

其中各组件说明如下：

Filebeat：轻量级数据收集引擎。早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。如果用它来对服务器进行日志收集，将加重服务器的负载。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计，所以filebeat作为一个轻量级的日志收集处理工具(Agent)，它可以用来替代Logstash，由于其占用资源少，所以更适合于在各个服务器上搜集日志后传输给Logstash，这也是官方推荐的一种做法。收集日志

Logstash：数据收集处理引擎。支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等 *** 作，然后存储以供后续使用。对日志进行过滤、分析

Elasticsearch：分布式搜索引擎。是基于Lucene的开源分布式搜索服务器，具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析，并能将这三者结合起来。搜集、分析、存储数据

Kibana：可视化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。图形化展示日志
如果还是遇到性能瓶颈

使用filebeat收集日志，先转发到beat端的logstash1，然后logstash1转发到kafka，然后再由logstash2从kafka读取写到elasticsearch。

2架构升级：

架构解释：

（1）首先用户通过nginx代理访问ELK日志统计平台，这里的Nginx可以设置界面密码。

（2）Nginx将请求转发到kibana

（3）kibana到Elasticsearch中去获取数据，这里的Elasticsearch是两台做的集群，日志数据会随机保存在任意一台Elasticsearch服务器。

（4）Logstash1从Kafka中取出数据并发送到Elasticsearch中。

（5）Kafka服务器做日志数据的持久化保存，避免web服务器日志量过大的时候造成的数据收集与保存不一致而导致日志丢失，其中Kafka可以做集群，然后再由Logstash服务器从Kafka持续的取出数据。

（6）logstash2从Filebeat取出的日志信息，并放入Kafka中进行保存。

（7）Filebeat在客户端进行日志的收集。

注1：Kafka的加入原因与作用

整个架构加入Kafka，是为了让整个系统更好的分层，Kafka作为一个消息流处理与持久化存储软件，能够帮助我们在主节点上屏蔽掉多个从节点之间不同日志文件的差异，负责管理日志端（从节点）的人可以专注于向 Kafka里生产数据，而负责数据分析聚合端的人则可以专注于从 Kafka内消费数据。所以部署时要把Kafka加进去。

而且使用Kafka进行日志传输的原因还在于其有数据缓存的能力，并且它的数据可重复消费，Kafka本身具有高可用性，能够很好的防止数据丢失，它的吞吐量相对来说比较好并且使用广泛。可以有效防止日志丢失和防止logsthash挂掉。综合来说：它均衡了网络传输，从而降低了网络闭塞，尤其是丢失数据的可能性，

注2：双层的Logstash作用

这里为什么要在Kafka前面增加二台logstash呢？是因为在大量的日志数据写入时，容易导致数据的丢失和混乱，为了解决这一问题，增加二台logstash可以通过类型进行汇总分类，降低数据传输的臃肿。

如果只有一层的Logstash，它将处理来自不同客户端Filebeat收集的日志信息汇总，并且进行处理分析，在一定程度上会造成在大规模日志数据下信息的处理混乱，并严重加深负载，所以有二层的结构进行负载均衡处理，并且职责分工，一层汇聚简单分流，一层分析过滤处理信息，并且内层都有二台Logstash来保障服务的高可用性，以此提升整个架构的稳定性。

kafka⾼性能，是多⽅⾯协同的结果，包括宏观架构、分布式partition存储、ISR数据同步、以及“⽆所不⽤其极”的
⾼效利⽤磁盘/ *** 作系统特性。
零拷⻉并不是不需要拷⻉，⽽是减少不必要的拷⻉次数。通常是说在IO读写过程中。
nginx的⾼性能也有零拷⻉的身影。
传统IO
⽐如：读取⽂件，socket发送
传统⽅式实现：先读取、再发送，实际经过1~4四次copy。

1、第⼀次：将磁盘⽂件，读取到 *** 作系统内核缓冲区；
2、第⼆次：将内核缓冲区的数据，copy到application应⽤程序的buffer；
3、第三步：将application应⽤程序buffer中的数据，copy到socket⽹络发送缓冲区(属于 *** 作系统内核的缓冲区)；
4、第四次：将socket buffer的数据，copy到⽹络协议栈，由⽹卡进⾏⽹络传输。

实际IO读写，需要进⾏IO中断，需要CPU响应中断(内核态到⽤户态转换)，尽管引⼊DMA(Direct Memory
Access，直接存储器访问)来接管CPU的中断请求，但四次copy是存在“不必要的拷⻉”的。
实际上并不需要第⼆个和第三个数据副本。数据可以直接从读缓冲区传输到套接字缓冲区。
kafka的两个过程：
1、⽹络数据持久化到磁盘 (Producer 到 Broker)
2、磁盘⽂件通过⽹络发送（Broker 到 Consumer）
数据落盘通常都是⾮实时的，Kafka的数据并不是实时的写⼊硬盘，它充分利⽤了现代 *** 作系统分⻚存储来利⽤内
存提⾼I/O效率。
磁盘⽂件通过⽹络发送（Broker 到 Consumer）
磁盘数据通过DMA(Direct Memory Access，直接存储器访问)拷⻉到内核态 Buffer
直接通过 DMA 拷⻉到 NIC Buffer(socket buffer)，⽆需 CPU 拷⻉。
除了减少数据拷⻉外，整个读⽂件 ==> ⽹络发送由⼀个 sendfile 调⽤完成，整个过程只有两次上下⽂切换，因此⼤⼤提⾼了性能。
Java NIO对sendfile的⽀持就是FileChanneltransferTo()/transferFrom()。
fileChanneltransferTo( position, count, socketChannel);
把磁盘⽂件读取OS内核缓冲区后的fileChannel，直接转给socketChannel发送；底层就是sendfile。消费者从broker读取数据，就是由此实现。
具体来看，Kafka 的数据传输通过 TransportLayer 来完成，其⼦类PlaintextTransportLayer 通过Java NIO 的FileChannel 的 transferTo 和 transferFrom ⽅法实现零拷⻉。

页缓存是 *** 作系统实现的⼀种主要的磁盘缓存，以此⽤来减少对磁盘 I/O 的 *** 作。
具体来说，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问。
Kafka接收来⾃socket buffer的⽹络数据，应⽤进程不需要中间处理、直接进⾏持久化时。可以使⽤mmap内存⽂件映射。
Memory Mapped Files
简称mmap，简单描述其作⽤就是：将磁盘⽂件映射到内存, ⽤户通过修改内存就能修改磁盘⽂件。
它的⼯作原理是直接利⽤ *** 作系统的Page来实现磁盘⽂件到物理内存的直接映射。完成映射之后你对物理内存的 *** 作会被同步到硬盘上（ *** 作系统在适当的时候）。

通过mmap，进程像读写硬盘⼀样读写内存（当然是虚拟机内存）。使⽤这种⽅式可以获取很⼤的I/O提升，省去了⽤户空间到内核空间复制的开销。
mmap也有⼀个很明显的缺陷：不可靠，写到mmap中的数据并没有被真正的写到硬盘， *** 作系统会在程序主动调⽤flush的时候才把数据真正的写到硬盘。
Kafka提供了⼀个参数 producertype 来控制是不是主动flush；
如果Kafka写⼊到mmap之后就⽴即flush然后再返回Producer叫同步(sync)；
写⼊mmap之后⽴即返回Producer不调⽤flush叫异步(async)。
Java NIO对⽂件映射的⽀持Java NIO，提供了⼀个MappedByteBuffer 类可以⽤来实现内存映射。
MappedByteBuffer只能通过调⽤FileChannel的map()取得，再没有其他⽅式。
FileChannelmap()是抽象⽅法，具体实现是在 FileChannelImplmap()可⾃⾏查看JDK源码，其map0()⽅法就是调⽤了Linux内核的mmap的API。

*** 作系统可以针对线性读写做深层次的优化，⽐如预读(read-ahead，提前将⼀个⽐较⼤的磁盘块读⼊内存) 和后写(write-behind，将很多⼩的逻辑写 *** 作合并起来组成⼀个⼤的物理写 *** 作)技术。

Kafka 在设计时采用了文件追加的⽅式来写⼊消息，即只能在⽇志⽂件的尾部追加新的消 息，并且也不允许修改已写⼊的消息，这种⽅式属于典型的顺序写盘的 *** 作，所以就算 Kafka 使⽤磁盘作为存储介质，也能承载⾮常⼤的吞吐量。
mmap和sendfile：

---