当前位置： 首页 >> Kafka >> 分布式消息队列

---

分布式消息队列

2020-07-02 13:36:27 星期四  阅读：2833

---

####使用消息队列的好处 `解耦` `可恢复性`：消费者挂了，数据还可以恢复 `缓冲`：解决生产速度与消费速度不一致的场景（特别是生产大于消费的问题） `削峰`：使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷请求而完全崩溃 `灵活`：动态增减机器 ####消息队列的两种模式 `点对点模式（Flume）`：一对一，如果Flume要实现一对多，则需要多个channel和多个sink `发布订阅模式（Kafka）`：一对多，消费者消费数据之后不会清除数据 `消费者主动拉取（Kafka）`：消费者的消费速度由消费者决定。缺点是：消费者需要定期轮询队列是否有新消息，当队列里长时间没有消息的时候，过多的轮询会浪费资源 `队列主动推送`：所有消费者得到的消息速度一样。不用消费者自己去轮询。缺点是：有的消费者消费速度慢，会造成崩溃；而有的消费速度快，资源没有得到充分利用。 ####Kafka架构 注意：`目前在生产 环境中很少有用kafka2.x版本的，因为太新了，风险太大` 同一个topic下有多个分区的作用：不同的分区存放在不同的broker，生产者发送消息的时候可以并发的往不同的分区（broker）发送消息。同时，消费端也可以启动多个消费者来消费同时从多个分区里消费数据。 一个分区，只能被同一个消费者组里的一个消费者消费。但是一个消费者能消费多个分区 `消费者并发度最好的时候`：消费组里的消费者个数与某个主题的分区数一样（消费者的个数多余某个topic的分区个数是没有意义的，浪费资源） ####Kafka的启动方式 Kafka虽然是集群模式，但是启动的时候需要每台节点依次手动启动（可自己写脚本自动启动集群所有broker），因为没有像Hadoop那样有单独的slave文件来指定集群之间的关系 ``` cd $KAFKA_HOME/ bin/kafka-server-start.sh config/server.properites ``` 但是这种方式启动是前台启动，当前终端退出后，kafka就关闭了。官方推荐的命令如下，以守护进程的方式启动 ``` cd $KAFKA_HOME/ bin/kafka-server-start.sh -daemon config/server.properites ``` 开启或关闭kafka的时候需要到每台机器上执行，为了增加开发效率，这里编写一个脚本，只需要在一台节点上执行就OK ```bash #!/bin/bash # filename: kafka-cluster.sh case $1 in "start"){ for i in broker1 broker2 broker3 do echo "--------------$i---------------" ssh $i "/opt/software/kafka/bin/kafka-server-start.sh -daemon /opt/software/kafka/config/server.properites" done };; "stop"){ for i in broker1 broker2 broker3 do echo "--------------$i---------------" # 关闭的时候不需要指定配置文件 ssh $i "/opt/softwre/kafka/bin/kafka-server-stop.sh" done } esca ``` ####Kafka高效读写数据 `顺序写磁盘` Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写，官网有数据表明，同样的磁盘，顺序写能达到600MB/s，而随机写只有100KB/s。顺序写之所以快，是因为其省去了大量磁头的寻址时间。 `零拷贝技术` 计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省CPU周期和内存带宽。 举例来说，如果要读取一个文件并通过网络发送它，传统方式下每个读/写周期都需要复制两次数据和切换两次上下文，而数据的复制都需要依靠CPU。通过零复制技术完成相同的操作，上下文切换减少到两次，并且不需要CPU复制数据。 零复制协议对于网络链路容量接近或超过CPU处理能力的高速网络尤为重要。在这种网络下，CPU几乎将所有时间都花在复制要传送的数据上，因此将成为使通信速率低于链路容量的瓶颈。 `ZK在Kafka中的作用` Kafka集群中有一个broker会被选举为Controller，负责管理集群broker的上下线。所有topic的分区副本分配和leader选举等工作。Controller所有的工作都是依赖zk的。 其次，要想让多台broker组成集群，需要把注册信息存储到zk。 最后，存储消费者offset（0.9版本及之后，offset存储在broker本地的一个系统自动创建的topic中）以及 存储所有topic的元数据（包括所有topic名称、有几个分区，哪个分区在哪台broker，有几个分区副本等） ####深入Kafka架构 #####关于分区副本数 如果某个topic的分区副本数设置为3，则说明每个分区有2个follower和一个leader（并不是一个leader和3个follower） 某个分区的leader和follower肯定不在同一台机器上 #####关于偏移量 偏移量不是topic全局的，而是针对具体的每个分区。也就是说，Kafka只能保证分区内消息的有序性，并不能保证topic全局的有序性。 #####关于topic Kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。 topic是逻辑上的概念（并没有具体的topic目录），partition是物理上的概念（一个partition是一个目录），每个partition对应一个log文件，该log文件中存储的就是producer生产的数据，producer生产的数据会被不断追加到该log文件末端，而每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到了那个offset，以便出错时从上次的位置继续消费。 #####Kafka文件存储机制 由于生产者的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个`partition分为多个segment`。每个segment对应两个文件——index文件和log文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号。 例如，my_topic有三个分区，则其对应的文件夹为： - my_topic-0 my_topic-1 my_topic-2