zk 记录集中的服务器数量，主题数量，分区信息，副本信息，集群控制器等信息。（数据不大，种类多，关注数据一致性，不要求速度高并发cp）
nacos主要做服务发现，Kafka中的zk的作用是状态管理。(ap)
不能替换。
RocketMQ为什么不使用ZooKeeper而自己开发NameServer？
kafka启动不了、在服务发现领域，ZooKeeper 根本就不能算是最佳的选择。
在分布式系统中，即使是对等部署的服务，因为请求到达的时间，硬件的状态，操作系统的调度，虚拟机的GC等，任何一个时间点，这些对等部署的节点状态也不可能完全一致，而流量不一致的情况下，只要注册中心在A承诺的时间内（例如1s内）将数据收敛到一致状态（即满足最终一致），流量将很快趋于统计学意义上的一致，所以注册中心以最终一致的模型设计在生产实践中完全可以接受。
在CAP的权衡中，注册中心的可用性比数据强一致性更宝贵，所以整体设计更应该偏向AP，而非CP，数据不一致在可接受范围，而P下舍弃A却完全违反了注册中心不能因为自身的任何原因破坏服务本身的可连通性的原则。
当数据中心服务规模超过一定数量，作为注册中心的ZooKeeper性能堪忧。
在服务发现和健康监测场景下，随着服务规模的增大，无论是应用频繁发布时的服务注册带来的写请求，还是刷毫秒级的服务健康状态带来的写请求，还是恨不能整个数据中心的机器或者容器皆与注册中心有长连接带来的连接压力上，ZooKeeper很快就会力不从心，而ZooKeeper的写并不是可扩展的，不可以通过加节点解决水平扩展性问题。
kafka发送失败？在服务发现场景中，其最核心的数据——实时的健康的服务的地址列表，真的需要数据持久化么？
不需要
在服务发现中，服务调用发起方更关注的是其要调用的服务的实时的地址列表和实时健康状态，每次发起调用时，并不关心要调用的服务的历史服务地址列表、过去的健康状态。
但是一个完整的生产可用的注册中心，除了服务的实时地址列表以及实时的健康状态之外，还会存储一些服务的元数据信息，例如服务的版本，分组，所在的数据中心，权重，鉴权策略信息，服务标签等元数据，这些数据需要持久化存储，并且注册中心应该提供对这些元数据的检索的能力。
使用ZooKeeper作为服务注册中心时，服务的健康检测绑定在了ZooKeeper对于Session的健康监测上，或者说绑定在TCP长链接活性探测上了。
ZK与服务提供者机器之间的TCP长链接活性探测正常的时候，该服务就是健康的么？答案当然是否定的！注册中心应该提供更丰富的健康监测方案，服务的健康与否的逻辑应该开放给服务提供方自己定义，而不是一刀切搞成了TCP活性检测！
kafka的使用。健康检测的一大基本设计原则就是尽可能真实的反馈服务本身的真实健康状态，否则一个不敢被服务调用者相信的健康状态判定结果还不如没有健康检测。
如果注册中心（Registry）本身完全宕机了，服务调用链路应该受到影响么？
不应该受到影响。
服务调用（请求响应流）链路应该是弱依赖注册中心，必须仅在服务发布，机器上下线，服务扩缩容等必要时才依赖注册中心。
这需要注册中心仔细的设计自己提供的客户端，客户端中应该有针对注册中心服务完全不可用时做容灾的手段，例如设计客户端缓存数据机制就是行之有效的手段。另外，注册中心的健康检查机制也要仔细设计以便在这种情况不会出现诸如推空等情况的出现。
查看kafka状态？ZooKeeper的原生客户端并没有这种能力，所以利用ZooKeeper实现注册中心的时候我们一定要问自己，如果把ZooKeeper所有节点全干掉，你生产上的所有服务调用链路能不受任何影响么？
阿里巴巴是不是完全没有使用 ZooKeeper？并不是。
熟悉阿里巴巴技术体系的都知道，其实阿里巴巴维护了目前国内最大规模的ZooKeeper集群，整体规模有近千台的ZooKeeper服务节点。
在粗粒度分布式锁，分布式选主，主备高可用切换等不需要高TPS支持的场景下有不可替代的作用，而这些需求往往多集中在大数据、离线任务等相关的业务领域，因为大数据领域，讲究分割数据集，并且大部分时间分任务多进程/线程并行处理这些数据集，但是总是有一些点上需要将这些任务和进程统一协调，这时候就是ZooKeeper发挥巨大作用的用武之地。
但是在交易场景交易链路上，在主业务数据存取，大规模服务发现、大规模健康监测等方面有天然的短板，应该竭力避免在这些场景下引入ZooKeeper，在阿里巴巴的生产实践中，应用对ZooKeeper申请使用的时候要进行严格的场景、容量、SLA需求的评估。
fatal error during kafkaserver。对于ZooKeeper，大数据使用，服务发现不用。
不多
kafka主要应用在大数据，数据分析的场景中
分布式事务没有用kafka的
可以选择使用rabbitmq或者rockmq
都行。
究竟选择什么技术，要看你的应用场景。
kafka broker may not available。意思是一般情况下好像都行，应用场景的极限情况下，就不同了。
mangodb
Kafka做中间件，可以持久化，但持久化不是它的目的，比如默认的1G，7天删除。
MongoDB随机读写，读取比较重的场合。
Kafka就是顺序读写，随机读写效率不行。
查看kafka运行状态？有的
一般不要主动flush到磁盘，最好由操作系统的后台线程执行异步的flush，这样速度快。
要保证数据的可靠性，完全可以acks=-1。
min.insync.replicas用于指定当acks=-1时，主题的分区至少几个副本确认才算生产成功。
自己定义。
kafka生产者数据阻塞、INTERNAL只是一个名称，你可以按照需求设置自己需要的名称。
但是必须和协议对应起来。
一般协议使用PLAINTEXT即可。
listeners=PT://web:9092,PT2://innor:9093
advertised.listeners=PT://web:9092,PT2://innor:9093
kafka重启命令？listener.security.protocol.map=PLAINTEXT:PT,PLAINTEXT:PT2,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
没什么关系。
状态同步吗？会的
不需要，只要获取请求报文的参数部分即可。
大数据处理中有ETL，对数据抽取转换加载，以便后续进行处理。
kafka重试机制、使用该模块，快速收集数据。
一般会。比如业务场景用RocketMQ，RabbitMQ，大数据用Kafka等。
但是如果是大数据，需要用到Kafka，一般生产环境不会有多套Kafka集群。但是开发/测试肯定都会有一套。
跟生产者调优有关。
一般生产者调优包括：生产者使用多个实例，多个应用
生产者使用多线程等。
如果需要并发，最好使用线程池。
Kafka 将消息以 topic 为单位进行管理。
向Kafka topic发布消息的程序成为producer。
订阅topics并消费消息的程序成为consumer。
Kafka以集群的方式运行，可以由一个或多个服务组成，每个服务叫做broker。
producers 通过网络将消息发送到Kafka集群，集群向消费者提供消息。
producer、consumer以及Kafka都可以横向扩展。
数据传输的事务定义通常有以下三种级别：
（1）最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输
（2）最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
（3）精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而仅仅被传输一次，这是大家所期望的
（1）节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接。
（2）如果节点是个 follower，必须能及时的同步leader的写操作，延时不能太久。
producer直接将数据发送到broker的leader(主节点)，不需要在多个节点进行分发，为了帮助producer做到这点，所有的Kafka节点都可以及时的告知：哪些节点是活动的，目标topic 目标分区的leader在哪。这样producer就可以直接将消息发送到目的地了。
这些元数据保存于zookeeper。
Kafa consumer消费消息时，向broker发出"fetch"请求去消费特定分区的消息，consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer 拥有offset的控制权，可以向后回滚去重新消费之前的消息。
Kafka最初考虑的问题是，customer应该从brokes拉取消息还是brokers将消息推送到consumer，也就是pull还push。在这方面，Kafka 遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息
一些消息系统比如 Scribe 和 Apache Flume 采用了push模式，将消息推送到下游的consumer。这样做有好处也有坏处：由broker决定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。
Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略
Pull 有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发。
消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和 CRC32校验码。
•消息长度: 4 bytes (value: 1+4+n)
•版本号: 1 byte
•CRC 校验码: 4 bytes
•具体的消息: n bytes
(1).Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。
(2).通过索引信息可以快速定位message和确定response的最大大小。
(3).通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。
(4).通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。
(1).Kafka 持久化日志，这些日志可以被重复读取和无限期保留，默认7天保留。
(2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性
(3).Kafka 支持实时的流式处理
• 副本因子不能大于Broker的个数；
• 第一个分区（编号为0）的第一个副本放置位置是随机从brokerList选择的；
• 其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个Broker，5个分区，假设第一个分区放在第四个Broker上，那么第二个分区将会放在第五个 Broker上；第三个分区将会放在第一个Broker上；第四个分区将会放在第二个Broker 上，依次类推；
• 剩余的副本相对于第一个副本放置位置其实是由nextReplicaShift决定的，而这个数也是随机产生的
在启动 Kafka 集群之前，我们需要配置好log.dirs参数，其值是Kafka数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。
当然也可以配置log.dir参数，含义一样。只需要设置其中一个即可。
如果log.dirs参数只配置了一个目录，那么分配到各个Broker上的分区肯定只能在这个目录下创建文件夹用于存放数据。
如果log.dirs参数配置了多个目录，那么Kafka会在哪个文件夹中创建分区目录呢？
答案是：Kafka会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为Topic名+分区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给log.dirs参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。
topic中的多个partition以文件夹的形式保存到broker，每个分区序号从0递增，且消息有序
Partition文件下有多个segment（xxx.index，xxx.log）
segment文件里的大小和配置文件大小一致可以根据要求修改默认为1g
如果大小大于1g时，以第一条消息的偏移量命名，滚动新segment文件。
request.required.acks 有三个值 0 1 -1
0：生产者不会等待broker的ack，这个延迟最低但是存储的保证最弱，当server挂掉的时候就会丢数据。
1：服务端会等待ack值leader副本确认接收到消息后发送ack；但是如果leader挂掉后他不确保是否复制完成新leader也会导致数据丢失
-1：同样在1的基础上，服务端会等所有的ISR follower的副本受到数据后才会收到leader发出的ack，这样数据不会丢失。也可以指定最小确认副本的个数。
消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（offset）的位置，等到下次消费时，他会接着上次位置继续消费。偏移量存储于Kafka特定主题：__consumer_offsets中。
一个消费者组中的一个分片对应一个消费者成员，他能保证每个消费者成员都能访问，如果组中成员太多会有空闲的成员。
一个消费者组里它的内部各个消费者是有序的
消费组与消费组之间是无序的
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
下面的StudentService.java实现了 通过JDBC对表STUDENTS的SELECT 和INSERT操作：
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
