日志系统笔记

1、Kafka
1）Kafka — 解决elk集群性能瓶颈，没有kafka对日志存取和缓冲配合logstash提取，过滤的话，es单扛海量日志，扛不住。主要是在高并发的日志搜集系统里提供分布式的消息队列服务，
不同系统之间传递消息
Kafka是像rabbitMQ一样的MQ发布订阅消息系统，往硬盘存，可以存TB级消息
产生消息的人直接写入Kafka队列中，elastic search 来消费
zookeeper 解决集群中几个Kafka互相认识了谁是谁，
producer – topic话题 – broker(中间人，就是kafka) – topic --consumer
一个topic能有多个分区， 每个Partition对应一个文件夹，名字为Topic+序号，里面有Segment（段数据文件=index file+data file 即 .index 和 .log 索引文件和数据文件）
每个Partition都是一个有序的队列，每条消息都有ID/Offset
每台机器一个broker.id,也就是每个机器是一个broker

这样分开来存，突破了单个文件夹得I/O限制
2) 支持消息持久化，Broker会暂时缓存，到阈值时，统一写到磁盘上

filebeat（占cpu少，10%左右） **内网(解决网络问题)**连 kafka -----用 MirrorMaker同步到 IDC（数据中心） 上的Kafka
而两个 Kafka 之间的数据传输，虽然说也会由于网络延时或者抖动出现数据丢失或者重复的问题，但是，在发现某个时段数据有问题的时候，只需要在 IDC 数据中心的 Kafka 集群上重新拉取一下公有云 Kafka 集群上这个故障时间段的数据就行了。因而也不用担心网络出现问题。

共需要8台服务器
上图没展示的，第一步 filebeat搜集Nginx数据，最后一步 kibana展示Elasticsearch上的数据

Kafka 与 RabbitMQ

没有消息队列，这么多微服务怎么统一管理通信

RabbitMQ通过Websocket与小程序连接
1> RabbitMQ – 消息匹配，不用开发成本
2> 订单系统
1）RMQ不好的地方
为了实现发布订阅功能，从而使用的消息复制，会降低性能并耗费更多资源
多个消费者无法严格保证消息顺序
大量的订单集中在一个队列，吞吐量受到了限制
2）Kafka的优势
首先，Kafka 的发布订阅并不会复制消息，因为 Kafka 的发布订阅就是消费者直接去获取被 Kafka 保存在日志文件中的消息就好。无论是多少消费者，他们只需要主动去找到消息在文件中的位置即可。

其次，Kafka 不会出现消费者出错后，把消息重新入队的现象。

最后，Kafka 可以对订单进行分区，把不同订单分到多个分区中保存，这样，吞吐量能更好。

3> 延迟队列，比如10分钟不支付就取消订单，用RMQ 那一条条戴手表的消息

4> 消息的保持和溯源，Kafka的消息会被持久化一个专门的日志文件里，不会像rabbitMQ式的被消费了就被删除

5> 消息的错误处理，kafka必须处理掉消息，否则等待，RMQ重新入队或者移走

6> kafka更复杂

————————————————
版权声明：本文为CSDN博主「面向bug，春暖花开」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qigeminghao/article/details/122344537