其他154657489456-CSDN博客

本文链接：https://blog.csdn.net/wujiahao_ccc/article/details/137874284

CAP，BASE
1 acid是关系数据库场景下，进过某个事物，数据库有一个一致性状态转变为另一个一致性状态
原子、一致、隔离、持久化。其余三个是手段，一致性是目的
2 CAP是说的分布式系统，再有多节点的分布式系统中，一致性、可用性、网络分区容错性
其中p是必须要考虑的，当发生网络分区容错时，只有cp和ap两种架构
为啥没有ca架构，自身是冲突的，节点间发生网络分区无法通信时，如果要保证一致性，那么就要暂停节点的写操作，这与可用性冲突；如果要保证可用性，所用节点都可以正常读写，这又与一致性违背

3 base，基本可用、软状态、最终一致性，可以理解为ap方案的补充，当保证可用性时，可以容忍短暂的数据不一致，但要保证数据的最终一致
核心思想：即使无法保证系统的强一致性，也要根据各自业务的特点，保证系统整体的最终一致性
ba:可以允许短暂的接口响应时间提高，非核心功能不可用
s：允许存在中间状态：节点间数据同步存在延迟

kafka多副本机制：
1.保证负载均衡
2.高可用
kafka如何保证消费消息的顺序
partition是消息写入的真正位置，消息是按照顺序写入，写入是会记录对应偏移量，但是只能保证在同一个partition中顺序消费。
如果要保证在消息顺序消费：可以一个topic指定一个partition或者指定key，同一个key的消息会放在一个partition中
如何保证消息不丢失
1.生产者丢失消息的情况：
kafka的send方法实际上是异步的，可以通过调用get方法的方式转为同步，但是效率低
虽好添加回调函数，当调用失败时可以设置retry方法，重试
2.消费者消息丢失：提交offset，但没消费完。解决方法：关闭自动提交，等消费完成后手动提交offset
3.kafka本身丢掉消息，一个topic对应多个partition，每个分区有多个副本，leader分区还没有同步完数据到follower时，leader挂了，重新选举leader，就会造成数据丢失。
可以通过设置acks参数all（-1）等所有isr中的副本都同步成功才会返回acks，acks是1表示只要leader成功就ok。还有个0，表示发送了不用等待任何副本成功直接ack，效率最高，但安全性最低。
min.insync.replicas> 1表示最少isr中有多少个副本才算成功
unclean.leader.election.enable = false。选取leader时只选取同步完全的
参数为1时没可能会丢消息，所以采用all加min.insync.replicas >= 2
如何保证不重复消费
原因：消费者消费完没有提交offset；网络问题，导致rebalance
解决：做幂等；手动提交（什么时候提交？消费完，还是有风险；或者一拉取到消息就提交【可以通过定时任务扫描做兜底】）
Kafka消费者处理偏移量（offset）的两种不同情况。：

1>消费者自己记录偏移量：这是Kafka消费者的一种常见做法。消费者在消费消息后，可以在自己的存储系统中记录下已经消费到的偏移量。这样做的好处是，即使消费者重启，也能从上次消费的位置继续消费，避免消息的重复消费或遗漏。这种方式需要消费者显式地管理偏移量。

2>Kafka自动管理偏移量：Kafka提供了自动提交偏移量的功能。当消费者消费了数据后，Kafka会定期自动提交消费者的当前偏移量到一个特殊的__consumer_offsets主题中。这样，即使消费者重启，也能从Kafka记录的偏移量继续消费。这种方式简化了消费者的开发，但在某些情况下可能会因为自动提交的延迟导致消息的重复消费。

如果服务端侧已经消费的数据没有成功提交偏移量，这意味着如果您是依赖Kafka自动提交偏移量的，那么Kafka是不会记录这次消费的。因此，如果消费者重启，它可能会重新消费这些消息。

如果您的应用程序在消费消息后，自己记录了偏移量（比如存储在数据库中），即使Kafka中的自动提交失败了，您的应用程序仍然可以根据自己记录的偏移量继续消费，避免了消息的重复消费。

所以，这两种情况并不矛盾，而是取决于是选择让Kafka自动管理偏移量，还是选择自己手动管理偏移量。在实际应用中，根据业务需求和容错性的要求选择合适的偏移量管理方式是非常重要的。

死信队列
当消息进入队列后，消费者会尝试处理它。如果处理失败，或者超过一定的重试次数仍无法被成功处理，消息可以发送到死信队列中，而不是被永久性地丢弃。在死信队列中，可以进一步分析、处理这些无法正常消费的消息，以便定位问题、修复错误，并采取适当的措施。
kafka与rocket mq零拷贝的区别

Kafka利用Java NIO中的FileChannel的transferTo方法实现零拷贝。当Kafka的Producer发送消息到Broker时，消息首先被写入到磁盘上的日志文件中。当Consumer读取消息时，Kafka通过transferTo方法直接将磁盘上的数据发送到网络，避免了将数据从磁盘读取到用户空间然后再写入到网络的过程。
Kafka的零拷贝主要用于消息的读取过程，即从Broker传输消息到Consumer。

RocketMQ同样支持零拷贝技术，但它的实现侧重点可能与Kafka有所不同。RocketMQ在存储设计上采用了内存映射文件（MappedByteBuffer）和文件预读（File Preload）技术，这些技术可以有效地减少在消息生产和消费过程中的磁盘I/O操作。
RocketMQ的零拷贝实现不仅仅局限于消息的读取过程，它还通过内存映射文件来优化消息的写入过程，即Producer写入消息到Broker。

总结：
Kafka的零拷贝实现主要集中在优化消息的读取过程，通过FileChannel的transferTo方法直接将磁盘上的数据发送到网络，减少CPU拷贝操作。
RocketMQ的零拷贝实现不仅优化了消息的读取过程，还通过内存映射文件（MappedByteBuffer）技术优化了消息的写入过程，减少了磁盘I/O操作。

ISR in-sync replicas
一个partirion中与leader保持同步的副本列表，这里不是指立即同步，而是指在最大延迟时间内（replica.lag.time.max.ms：默认500）同步成功的副本，只有在isr内的才能被选为新leader
Kafka的两个重要属性：
LEO:log end offset下一个消息的位移值
HW：高水位线，同步备份完成的偏移量。Leader的HW值由ISR中的所有备份的LEO最小值决定
Kakfa高性能
生产者向broker中发送消息，和消费者从broker拉取消息消费的维度都是partition的leader节点。
如果生产一条发一条会造成大量的网络消耗，影响kafka性能，采用批量传输解决。同样生产者读取消息如果采用传统的IO方式，回影响性能，因此Kafka使用了顺序写+零拷贝
批量传输
kafka的消息是一个键值对，发送到broker前，会先经由路由策略（轮询、散列【key】、自定义），将消息存入本地的partition队列。

生产者生产消息经过序列化和压缩后追加存入本地消息收集器，sender扫描消息收集器中达到**阈值（数量、等待时间）**的消息批量发送至对应的leader节点

Kafka中的rebalance（再平衡）主要发生在以下场景：

消费者组成员变化：当新的消费者加入消费者组或现有消费者离开消费者组（包括正常退出和崩溃）时，会触发rebalance。这是为了重新分配分区所有权，确保分区的消息能够被消费者组内的所有消费者平均消费。
主题分区数变化：如果订阅的主题增加了分区，Kafka会进行rebalance来分配新增的分区。这确保了新增的分区可以被消费者组中的消费者所消费。
消费者组订阅的主题列表变化：如果消费者通过subscribe方法改变了它订阅的主题列表，这也会触发rebalance，以确保新的订阅关系能够生效。
消费者崩溃或心跳超时：如果消费者因为崩溃停止工作，或者由于网络问题等原因导致心跳超时（Kafka消费者通过定期发送心跳来表明它们仍然活跃），Kafka会认为该消费者已经离开消费者组，从而触发rebalance。
消费者手动调用poll方法的间隔时间过长：如果消费者调用poll方法的间隔时间超过了max.poll.interval.ms配置的时间，Kafka同样会认为该消费者已经不再活跃，触发rebalance。

rebalance是Kafka保证消息消费负载均衡和高可用性的重要机制，但也可能导致短暂的消费中断。因此，合理配置消费者和监控消费者组的状态对于维护Kafka应用的稳定性至关重要。

rebalance对Kafka消费者有以下影响：

消费延迟：在rebalance过程中，消费者组内的所有消费者都不能消费消息，直到rebalance完成。这会导致消息消费的延迟。
消息重复消费：rebalance可能导致某些消息被重复消费。因为在rebalance之前，某些消息可能已经被消费者拉取但还未提交偏移量，rebalance后这些消息可能会被分配给其他消费者，导致重复消费。
消费者负载不均：虽然rebalance的目的是为了均衡消费者的负载，但在某些情况下，如果分区数不能被消费者数整除，可能会导致部分消费者分配到更多的分区，从而负载较重。

避免rebalance的策略包括：

稳定消费者组成员：尽量避免频繁地添加或移除消费者。在服务发布过程中，可以通过蓝绿部署或滚动更新等方式，逐步替换消费者实例，减少消费者组成员的突变。
合理设置会话超时和心跳间隔：通过调整session.timeout.ms和heartbeat.interval.ms参数，可以减少因网络抖动或消费者处理逻辑过长导致的非预期rebalance。
使用静态成员ID：Kafka 2.3及以上版本支持静态成员ID（group.instance.id），这允许消费者在重启或重新连接时保持其在消费者组中的身份，减少不必要的rebalance。
控制消费者poll间隔：确保消费者调用poll的间隔时间不会超过max.poll.interval.ms配置，以避免因消费者被认为已死而触发rebalance。
分区管理策略：在增加主题分区时，考虑到可能触发的rebalance，可以在业务低峰期进行操作，并确保消费者组能够平滑过渡。