Decade_Faiz的博客

Docker Compose是一个用于定义和运行多个Docker容器的工具，负责实现对 docker 容器集群的快速编排，它使用 YAML 文件来配置应用程序的服务、网络和卷等方面。Compose服务(service)：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例。项目(project)：由一组关联的应用容器组成的一个完整业务单元，在文件中定义。

ADD和COPY都能够将宿主机的文件添加到容器当中，但是ADD还有一个更强大的功能，ADD后面还能够接url参数，就是说ADD可以联网下载你url指定的文件，而COPY仅仅只能添加上下文目录中的文件。用来从 context（上下文） 上下文复制新文件，目录或远程文件 url ，并将它们添加到位于指定路径的映像文件系统中。RUN 命令将在当前映像之上的新层中执行任意命令并提交结果，生成的提交映像将用于 Dockerfile 中的下一步。用来为启动的容器指定执行的命令，在 Dockerfile 中。

当 Docker 启动时，会自动在主机上创建一个docker0虚拟网桥，实际上是 Linux 的一个 bridge，可以理解为一个软件交换机。它会在挂载到它的网口之间进行转发。同时，Docker 随机分配一个本地未占用的私有网段（在RFC1918中定义）中的一个地址给docker0接口。比如典型的，掩码为。此后启动的容器内的网口也会自动分配一个同一网段（）的地址。当创建一个 Docker 容器的时候，同时会创建了一对veth pair接口（当数据包发送到一个接口时，另外一个接口也可以收到相同的数据包）

例如：groupid的hashcode值=1，1%50=1，那么_consumer_offsets主题的1号分区，在哪个broker上，就选择这个节点的coordinator作为这个消费者组的老大。**注意：在消费者API代码中必须配置消费者组id。**命令行启动消费者不填写消费者组id会被自动填写随机的消费者组id。形成一个消费者组的条件，是所有消费者的groupid相同。运行三个消费者程序，分别在三个控制台中发现每个消费者消费的都是不同分区的数据。：辅助实现消费者组的初始化和分区的分配。

针对broker0节点，分区2的AR优先副本是0节点，但是0节点却不是Leader节点，所以不平衡数加1，AR副本总数是4，所以broker0节点不平衡率为1/4>10%,需要重平衡。在生产环境中，每台服务器的配置和性能不一致，但是Kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别服务器存储压力较大。Broker1的不平衡数为0，不需要再平衡。但是我们发现，新节点服役之后，之前创建的topic还是只存在之前的节点中，于是我们创建一个要均衡的主题。，来保证每台机器的读写吞吐量都是均匀的。

在消息发送过程中，涉及到了两个线程—— main 线程和 Sender 线程。回调函数会在 producer 收到 ack 时调用，为异步调用，该方法有两个参数，分别是元数据信息（RecordMetadata）和异常信息（Exception），如果 Exception 为 null，说明消息发送成功，如果 Exception 不为 null，说明消息发送失败。**需求：**创建 Kafka 生产者，采用异步的方式发送到 Kafka Broker。在node1节点中开启kafka消费者。

【代码】【Kafka】Kafka基础操作笔记。

3000ms为连接mq的超时时间,延时等级为2.

顺序消费和并发消费的重试机制并不相同，顺序消费消费失败后会先在客户端本地重试直到最大重试次数，这样可以避免消费失败的消息被跳过，消费下一条消息而打乱顺序消费的顺序，而并发消费消费失败后会将消费失败的消息重新投递回服务端，再等待服务端重新投递回来，在这期间会正常消费队列后面的消息。若Consumer消费某条消息失败，则RocketMQ会在重试间隔时间后，将消息重新投递给Consumer消费，若达到最大重试次数后消息还没有成功被消费，则消息将被投递至死信队列。针对方案一的缺点，方案二能够比较好的解决。

Broker 端会为每个消息创建索引（哈希索引），应用可以通过 topic、key 来查询这条消息内容，以及消息被谁消费。但通常情况下，不同的 Topic 之间的消息没有必然的联系，而 Tag 则用来区分同一个 Topic 下相互关联的消息，例如全集和子集的关系、流程先后的关系。注：msgId一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同msgId的情况（消费者主动重发、因客户端重投机制导致的重复等），这种情况就需要使业务字段进行重复消费。如果失败，则直接返回。消息为什么会重复消费？

消息发送方在发送了一条消息后，不需要等待服务端响应即可发送第二条消息，发送方通过回调接口接收服务端响应，并处理响应结果。Push模式也是基于pull模式的，只能客户端内部封装了api，一般场景下，上游消息生产量小或者均速的时候，选择push模式。同步发送是最常用的方式，是指消息发送方发出一条消息后，会在收到服务端同步响应之后才发下一条消息的通讯方式，可靠的同步传输被广泛应用于各种场景，如重要的通知消息、短消息通知等。异步发送是指发送方发出一条消息后，不等服务端返回响应，接着发送下一条消息的通讯方式。