xiaoxualg的博客

本文介绍了在CentOS7服务器上使用Docker搭建ELK(Elasticsearch+Logstash+Kibana)日志系统的完整流程。主要内容包括：1) 创建Docker网络并部署Elasticsearch 8.5.0容器，配置相关参数；2) 安装配置Logstash 8.5.0容器，设置日志收集规则；3) 部署Kibana 8.5.0容器用于可视化展示；4) 最后给出了SpringBoot项目对接Logstash的具体配置方法，包括添加依赖和logback配置。整个搭建过程详细说明了各组件参数设置

上述就是常见的Redis 数据结构以及基础使用，后续文章会逐步深入各个数据结构，剖析他们的设计以及性能高的原因。

传统的Kafka集群，会将每个节点的状态信息统一保存在Zookeeper中，并通过Zookeeper动态选举产生一个Controller节点，通过Controller节点来管理Kafka集群，比如触发Partition的选举。后续，如果需要对接更多的Source和Sink，或者进行更大规模甚至集群化的数据计算，那就需要其他更大型的流式计算框架来处理了。这都是典型的批量计算。Raft协议是目前进行去中心化集群管理的一种常见算法，类似于之前的Paxos协议，是一种基于多数同意，从而产生集群共识的分布式算法。

然后，Kafka的log文件只能以追加的方式往文件的末端添加(这种写入方式称为顺序写)，这样，新的数据写入时，就可以直接往直前申请的磁盘空间中写入，而不用再去磁盘其他地方寻找空闲的空间(普通的读写文件需要先寻找空闲的磁盘空间，再写入。缓存数据断电就会丢失，这是大家都能理解的，所以缓存中的数据如果没有及时写入到硬盘，也就是常说的刷盘，那么当服务突然崩溃，就会有丢消息的可能。这些底层的优化机制都是操作系统提供的优化机制，其实针对任何上层应用语言来说，都是一个黑盒，只能去调用，但是控制不了具体的实现过程。

Leader 选举机制保证了我们集群中的Partition每时每刻只有一个Leader，保证了我们服务的高可用，但是，并不是这样就能保证我们服务的稳定，通常Leader是业务繁忙的一个机器，如果在所有partition中，1在拥有大部分partiton的备份，如果在选举过程中导致1变成大部分Partition的Leader，那么就会导致1机器的压力，没有分配好集群中机器的资源。ISR 表示所有在AR中存活的副本，存活的机器，需要与Leader定时发送消息，如果超时，会被提出ISR集合，超时时间由。

开发者可以实现Serializer和接口，以支持特定的数据格式。实现接口@Override// 示例：将对象转为字符串字节实现接口@Override// 示例：通过 JSON 解析为对象使用自定义序列化器在生产者和消费者的配置中指定自定义类：每条消息在发送到 Kafka 主题时，生产者需要确定将消息发送到哪个分区（Partition）。指定分区：生产者直接指定消息的目标分区。根据 Key 计算分区：如果消息设置了 Key，则通过 Key 的哈希值确定分区。随机分区。

单机部署

Netty不看重Windows上的使用，在Linux系统上，AIO的底层实现仍使用EPOLL，没有很好实现AIO，因此在性能上没有明显的优势，而且被JDK封装了一层不容易深度优化。AIO还有个缺点是接收数据需要预先分配缓存, 而不是NIO那种需要接收时才需要分配缓存, 所以对连接数量非常大但流量小的情况, 内存浪费很多。而且Linux上AIO不够成熟，处理回调结果速度跟不上处理需求。