消息中间件-Kafka1-实现原理

news2024/12/27 5:05:02

消息中间件-Kafka

一、kafka简介

1、概念
Kafka是最初由Linkedin公司开发,是一个分布式、支持分区(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
2、Kafka特性

  • Kafka具有近乎实时性的消息处理能力,即使面对海量消息也能够高效地存储消息和查询消息。
    Kafka将消息保存在磁盘中,它以顺序读写的方式访问磁盘,从而避免了随机读写磁盘导致的性能瓶颈。
  • Kafka支持批量读写消息,并且会对消息进行批量压缩
  • Kafka支持消息分区,每个分区中的消息保证顺序传输,而分区之间则可以并发操作,具备高并发能力
  • Kafka也支持在线增加分区,支持在线水平扩展
  • Kafka支持为每个分区创建多个副本,其中只会有一个Leader副本负责读写,其他副本只负责与Leader副本进行同步,Kafka会将Leader副本均匀地分布在集群中的服务器上,实现性能最大化,同时具备较强的容灾能力

3、应用场景

  • 在应用系统中可以将Kafka作为传统的消息中间件,实现消息队列和消息的发布/订阅,在某些特定场景下其性能要更优于RabbitMQ、ActiveMQ等传统的消息中间件
  • Kafka也被用作系统中的数据总线,将其接入多个子系统中,子系统会将产生的数据发送到Kafka中保存,之后流转到目的系统中
  • Kafka还可以用作日志收集中心,多个系统产生的日志统一收集到Kafka中,然后由数据分析平台进行统一处理。日志会被Kafka持久化到磁盘,所以同时支持离线数据处理和实时数据处理
  • 事件溯源
    Kafka的持久化存储和顺序消息传递特性使其成为事件溯源的理想选择。通过将系统的事件以消息的形式写入Kafka的主题中,可以实现对系统状态的完全恢复和追溯。这对于需要满足合规性要求或实现事件溯源的系统非常重要,如金融交易系统、电子商务系统等。
  • 流媒体处理
    Kafka在流媒体处理领域也有着广泛的应用。流媒体处理要求系统能够高效地处理大规模的音视频数据流。Kafka的高吞吐量和低延迟特性使其成为一个理想的流媒体处理平台。通过使用Kafka,可以构建高性能的音视频处理系统,实现实时的流媒体传输、转码、存储和分发。

4、数据持久化
在分布式系统中,各个组件是通过网路连接起来的。一般认为网络传输是不可靠的,当数据在两个组件之间进行传递的时候,传输过程可能会失败。除非数据被持久化到磁盘,否则就可能造成消息的丢失。Kafka把数据以消息的形式持久化到磁盘,即使Kafka出现宕机,也可以保证数据不会丢失,通过这一方式规避了数据丢失风险。为了避免磁盘上的数据不断增长,Kafka提供了日志清理、日志压缩等功能,对过时的、已经处理完成的数据进行清除。在磁盘操作中,耗时最长的就是寻道时间,这是导致磁盘的随机I/O性能很差的主要原因。为了提高消息持久化的性能,Kafka采用顺序读写的方式访问,实现了高吞吐量。
5、扩展与容灾
Kafka的每个Topic(主题)都可以分为多个Partition(分区),每个分区都有多个Replica(副本),实现消息冗余备份。每个分区中的消息是不同的,这类似于数据库中水平切分的思想,提高了并发读写的能力。而同一分区的不同副本中保存的是相同的消息,副本之间是一主多从的关系,其中Leader副本负责处理读写请求,Follower副本则只与Leader副本进行消息同步,当Leader副本出现故障时,则从Follower副本中重新选举Leader副本对外提供服务。这样,通过提高分区的数量,就可以实现水平扩展;通过提高副本的数量,就可以提高容灾能力。
Kafka的容灾能力不仅体现在服务端,在Consumer端也有相关设计。Consumer使用pull方式从服务端拉
取消息,并且在Consumer端保存消费的具体位置,当消费者宕机后恢复上线,可以根据自己保存的消费位
置重新拉取需要的消息进行消费,这就不会造成消息丢失。也就是说,Kafka不决定何时、如何消费消息,
而是Consumer自己决定何时、如何消费消息。
Kafka还支持Consumer的水平扩展能力。我们可以让多个Consumer加入一个Consumer Group(消费组),在一个Consumer Group中,每个分区只能分配给一个Consumer消费,当Kafka服务端通过增加分区数量进行水平扩展后,我们可以向Consumer Group中增加新的Consumer来提高整个Consumer Group的消费能力。当Consumer Group中的一个Consumer出现故障下线时,会通过Rebalance操作将下线Consumer负责处理的分区分配给其他Consumer继续处理;当下线Consumer重新上线加入Consumer Group时,会再进行一次Rebalance操作,重新分配分区。当然,一个Consumer Group可以订阅很多不同的Topic,每个Consumer可以同时处理多个分区
6、分区数据的顺序保证
Kafka保证一个分区内的消息的有序性,但是并不保证多个partition之间的数据有顺序。
7、异步通信
Kafka为系统提供了异步处理能力。例如,两个系统需要通过网络进行数据交换,其中一端可以把一个消息放入Kafka中后立即返回继续执行其他路基,不需要等待对端的响应。待后者将处理结果放入Kafka中之后,前者可以从其中获取并解析响应。

二、Kfaka核心概念

  • 消息
    消息是Kafka中最基本的数据单元。消息由一串字节构成,其中主要由key和value构成,key和value也都是byte数组。key的主要作用是根据一定的策略,将此消息路由到指定的分区中,这样就可以保证包含同一key的消息全部写入同一分区中,key可以是null。
  • Topic/分区/Log
    Topic是用于存储消息的逻辑概念,可以看作一个消息集合。每个Topic可以有多个生产者向其中推送(push)消息,也可以有任意多个消费者消费其中的消息。每个Topic可以划分成多个分区(每个Topic都至少有一个分区),同一Topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时,都会被分配一个offset,它是消息在此分区中的唯一编号,Kafka通过offset保证消息在分区内的顺序,offset的顺序性不跨分区,即Kafka只保证在同一个分区内的消息是有序的;同一Topic的多个分区内的消息,Kafka并不保证其顺序性。同一Topic的不同分区会分配在不同的Broker上。分区是Kafka水平扩展性的基础,我们可以通过增加服务器并在其上分配Partition的方式来增加Kafka的并行处理能力。
    分区在逻辑上对应着一个Log,当生产者将消息写入分区时,实际上是写入到了分区对应的Log中。Log是一个逻辑概念,可以对应到磁盘上的一个文件夹。Log由多个Segment组成,每个Segment对应一个日志文件和索引文件。在面对海量数据时,为避免出现超大文件,每个日志文件的大小是有限制的,当超出限制后则会创建新的Segment,继续对外提供服务。这里要注意,因为Kafka采用顺序I/O,所以只向最新的Segment追加数据。
  • 保留策略与日志压缩
    无论消费者是否已经消费了消息,Kafka都会一直保存这些消息,但并不会像数据库那样长期保存。为了避免磁盘被占满,Kafka会配置相应的“保留策略”(retention policy),以实现周期性地删除陈旧的消息。

一种是根据消息保留的时间,当消息在Kafka中保存的时间超过了指定时间,就可以被删除
根据Topic存储的数据大小,当Topic所占的日志文件大小大于一个阈值,则可以开始删除最旧的消息。

Kafka会启动一个后台线程,定期检查是否存在可以删除的消息。“保留策略”的配置是非常灵活的,可以有全局的配置,也可以针对Topic进行配置覆盖全局配置。

  • 消息压缩
    在很多场景中,消息的key与value的值之间的对应关系是不断变化的,就像数据库中的数据会不断被修改一样,消费者只关心key对应的最新value值。此时,可以开启Kafka的日志压缩功能,Kafka会在后台启动一个线程,定期将相同key的消息进行合并,只保留最新的value值。
    压缩过程:
    在这里插入图片描述
  • Broker
    一个单独的Kafka服务器就是一个Broker。Broker的主要工作就是接收生产者发过来的消息,分配offset,之后保存到磁盘中;同时,接收消费者、其他Broker的请求,根据请求类型进行相应处理并返回响应。在一般的生产环境中,一个Broker独占一台物理服务器。
  • 分区副本
    每个分区的副本集合中,都会选举出一个副本作为Leader副本,Kafka在不同的场景下会采用不同的选举策略所有的读写请求都由选举出的Leader副本处理,其他都作为Follower副本,Follower副本仅仅是从Leader 副本处把数据拉取到本地之后,同步更新到自己的Log中。一般情况下,同一分区的多个副本会被分配到不同的Broker上,这样,当Leader所在的Broker宕机之后,可以重新选举新的Leader,继续对外提供服务。
  • ISR(In-Sync Replica)集合
    ISR(In-Sync Replica)集合表示的是目前“可用”(alive)且消息量与Leader相差不多的副本集合,其中每个副本必须满足副本所在节点必须维持着与ZooKeeper的连接副本最后一条消息的offset与Leader副本的最后一条消息的offset之间的差值不能超出指定的阈值*
    每个分区中的Leader副本都会维护此分区的ISR集合。写请求首先由Leader副本处理,之后Follower副本会从Leader上拉取写入的消息,这个过程会有一定的延迟,导致Follower副本中保存的消息略少于Leader副本,只要未超出阈值都是可以容忍的。如果一个Follower副本出现异常,比如:宕机,发生长时间GC而导致Kafka僵死或是网络断开连接导致长时间没有拉取消息进行同步,就会违反上面的两个条件,从而被Leader副本踢出ISR集合。当Follower副本从异常中恢复之后,会继续与Leader副本进行同步,当Follower副本“追上”(即最后一条消息的offset的差值小于指定阈值)Leader副本的时候,此Follower副本会被Leader副本重新加入到ISR中。
  • HW
    HW(HighWatermark)和LEO与上面的ISR集合紧密相关。HW标记了一个特殊的offset,当消费者处理消息的时候,只能拉取到HW之前的消息,HW之后的消息对消费者来说是不可见的。与ISR集合类似,HW也是由Leader副本管理的。当ISR集合中全部的Follower副本都拉取HW指定消息进行同步后,Leader副本会递增HW的值。
  • LEO(Log End Offset)
    LEO是所有的副本都会有的一个offset标记,它指向追加到当前副本的最后一个消息的offset。当生产者向Leader副本追加消息的时候,Leader副本的LEO标记会递增;当Follower副本成功从Leader副本拉取消息并更新到本地的时候,Follower副本的LEO就会增加。

HW与LEO的关系如下图
在这里插入图片描述
①Producer向此Partition推送消息。
②Leader副本将消息追加到Log中,并递增其LEO。
③Follower副本从Leader副本拉取消息进行同步。
④Follower副本将拉取到的消息更新到本地Log中,并递增其LEO。
⑤当ISR集合中所有副本都完成了对offset=11的消息的同步,Leader副本会递增HW。
在①~⑤步完成之后,offset=11的消息就对生产者可见了。

  • 为什么kafka数据冗余要设计成这样?
    常见的数据同步包括同步复制和异步复制。
    同步复制要求所有能工作的Follower副本都复制完,这条消息才会被认为提交成功。一旦有一个
    Follower副本出现故障,就会导致HW无法完成递增,消息就无法提交,生产者获取不到消息。这
    种情况下,故障的Follower副本会拖慢整个系统的性能,甚至导致整个系统不可用。
    异步复制中,Leader副本收到生产者推送的消息后,就认为此消息提交成功。Follower副本则异步
    地从Leader副本同步消息。这种设计虽然避免了同步复制的问题,但同样也存在一定的风险。现在
    假设所有Follower副本的同步速度都比较慢,它们保存的消息量都远远落后于Leader副本。
    在这里插入图片描述
    此时Leader副本所在的Broker突然宕机,则会重新选举新的Leader副本,而新Leader副本中没有原来
    Leader副本的消息,这就出现了消息的丢失,而有些消费者则可能消费了这些丢失的消息,状态变得不可控。
    Kafka权衡了同步复制和异步复制两种策略,通过引入了ISR集合,巧妙地解决了上面两种方案存在的
    缺陷:当Follower副本的延迟过高时,Leader副本被踢出ISR集合,消息依然可以快速提交,生产者可以快速得到响应,避免高延时的Follower副本影响整个Kafka集群的性能。当Leader副本所在的Broker突然宕机的时候,会优先将ISR集合中Follower副本选举为Leader副本,新Leader副本中包含了HW之前的全部消息,这就避免了消息的丢失。值得注意是,Follower副本可以批量地从Leader副本复制消息,这就加快了网络I/O,Follower 副本在更新消息时是批量写磁盘,加速了磁盘的I/O,极大减少了Follower与Leader的差距。
  • Cluster(集群)与Controller(指挥中心)
    多个Broker可以做成一个Cluster(集群)对外提供服务,每个Cluster当中会选举出一个Broker来担任
    Controller,Controller是Kafka集群的指挥中心,而其他Broker则听从Controller指挥实现相应的功能。
    Controller负责管理分区的状状态、管理每个分区的副本状态、监听Zookeeper中数据的变化等工作。
    Controller也是一主多从的实现,所有Broker都会监听Controller Leader的状态,当Leader Controller出现故障时则重新选举新的Controller Leader。
  • 生产者
    生产者(Producer)的主要工作是生产消息,并将消息按照一定的规则推送到Topic的分区中。这里选
    择分区的“规则”可以有很多种,例如:根据消息的key的Hash值选择分区,或按序轮询全部分区的方式。
  • 消费者
    消费者(Consumer)的主要工作是从Topic中拉取消息,并对消息进行消费。某个消费者消费到
    Partition的哪个位置(offset)的相关信息,是Consumer自己维护的。 如下图
    在这里插入图片描述
  • Consumer Group 消费者组
    在Kafka中,多个Consumer可以组成一个Consumer Group,一个Consumer只能属于一个Consumer
    Group。Consumer Group保证其订阅的Topic的每个分区只被分配给此Consumer Group中的一个消费者处理。如果不同Consumer Group订阅了同一Topic,Consumer Group彼此之间不会干扰。这样,如果要实现一个消息可以被多个消费者同时消费(“广播”)的效果,则将每个消费者放入单独的一个Consumer Group;如果要实现一个消息只被一个消费者消费(“独占”)的效果,则将所有Consumer放入一个Consumer Group中。
    消费者组消费消息如图:
    在这里插入图片描述
    Consumer Group除了实现“独占”和“广播”模式的消息处理,Kafka还通过Consumer Group实现了消费者的水平扩展和故障转移。在上图中,当Consumer3的处理能力不足以处理两个Partition中的数据时,可以通过向Consumer Group中添加消费者的方式,触发Rebalance操作重新分配分区与消费者的对应关系,从而实现水平扩展。如下图所示,添加Consumer4之后,Consumer3只消费Partition2中的消息,Partition3中的消息则由Consumer4来消费。
    在这里插入图片描述
    下面来看消费者出现故障的场景,当Consumer4宕机时,Consumer Group会自动重新分配分区,如下图所示,由Consumer3接管Consumer4对应的分区继续处理。
    在这里插入图片描述
    注,Consumer Group中消费者的数量并不是越多越好,当其中消费者数量超过分区的数量时,会导
    致有消费者分配不到分区,从而造成消费者的浪费

三、Kafak消息处理流程图

  • 单个Kafka Server单体模式
    在这里插入图片描述
    Kafka的每个Topic(主题)都可以分为多个Partition(分区),每个分区都有多个Replica(副本),实现消息冗余备份。每个分区中的消息是不同的,这类似于数据库中水平切分的思想,提高了并发读写的能力。而同一分区的不同副本中保存的是相同的消息,副本之间是一主多从的关系,其中Leader副本负责处理读写请求,Follower副本则只与Leader副本进行消息同步,当Leader副本出现故障时,则从Follower副本中重新选举Leader副本对外提供服务。
  • 集群Kafak Server 集群模式
    在这里插入图片描述
    如上所示,生产者会根据业务逻辑产生消息,之后根据路由规则将消息发送到指定分区的Leader副本所在的Broker上。在Kafka服务端接收到消息后,会将消息追加到Log中保存,之后Follower副本会与
    Leader副本进行同步,当ISR集合中所有副本都完成了此消息的同步后,则Leader副本的HW会增加,并向生产者返回响应。
    当消费者加入到Consumer Group时,会触发Rebalance操作将分区分配给不同的消费者消费。随后,消费者会恢复其消费位置,并向Kafka服务端发送拉取消息的请求,Leader副本会验证请求的offset以及其他相关信息,最后返回消息。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2253026.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

使用 Python 中的 TripoSR 根据图像创建 3D 对象

使用 Python 中的 TripoSR 根据图像创建 3D 对象 1. 效果图2. 步骤图像到 3D 对象设置环境导入必要的库设置设备创建计时器实用程序上传并准备图像处理输入图像生成 3D 模型并渲染下载.stl 文件展示结果3. 源码4. 遇到的问题及解决参考这篇博客将引导如何使用Python 及 TripoSR…

【SKFramework框架核心模块】3-3、调试器

推荐阅读 CSDN主页GitHub开源地址Unity3D插件分享QQ群:398291828小红书小破站 大家好,我是佛系工程师☆恬静的小魔龙☆,不定时更新Unity开发技巧,觉得有用记得一键三连哦。 一、前言 【Unity3D框架】SKFramework框架完全教程《全…

03-13、SpringCloud Alibaba第十三章,升级篇,服务降级、熔断和限流Sentinel

SpringCloud Alibaba第十三章,升级篇,服务降级、熔断和限流Sentinel 一、Sentinel概述 1、Sentinel是什么 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保…

QT实战-qt各种菜单样式实现

本文主要介绍了qt普通菜单样式、带选中样式、带子菜单样式、超过一屏幕菜单样式、自定义带有滚动条的菜单样式, 先上图如下: 1.普通菜单样式 代码: m_pmenu new QMenu(this);m_pmenu->setObjectName("quoteListMenu"); qss文…

健康养生生活

在快节奏的现代生活中,健康养生愈发成为人们关注的焦点。它不仅是一种生活方式,更是对生命质量的珍视与呵护。 健康养生,饮食为先。合理的膳食结构是维持身体健康的基石。我们应确保每餐营养均衡,增加蔬菜、水果、全谷物以及优质蛋…

2023年华数杯数学建模B题不透明制品最优配色方案设计解题全过程文档及程序

2023年华数杯全国大学生数学建模 B题 不透明制品最优配色方案设计 原题再现: 日常生活中五彩缤纷的不透明有色制品是由着色剂染色而成。因此,不透明制品的配色对其外观美观度和市场竞争力起着重要作用。然而,传统的人工配色存在一定的局限性…

C语言实验 循环结构2

时间:2024.12.3 一、实验 7-1 求符合给定条件的整数集 #include<stdio.h> int main(){int a,b,s,g; scanf("%d",&a);int h=0; for(int i=a;i<=a+3;i++){for(int j=a;j<=a+3;j++){for(int k=a;k<=a+3;k++){if((i!=j)&&(i!=k)&&…

Android10 设备死机的问题分析和解决

最近客户反馈一个问题&#xff0c;设备偶现死机。最后解决&#xff0c;在此记录。 目录 一死机的现象 二死机的类型 三 死机问题分析 1 死机现象的梳理 2 死机日志 1&#xff09;日志分析一 2 日志分析二&#xff08;正确方案&#xff09; 一死机的现象 设备死机&#x…

koa中间件

文章目录 1. koa中间件简介2. 中间件类型1. 应用级中间件2. 路由级中间件3. 错误处理中间件4. 第三方中间件 3.中间件执行流程 1. koa中间件简介 在Koa中&#xff0c;中间件呈现为一个异步函数&#xff0c;该函数支持 async/await 语法&#xff0c;它接收两个参数&#xff1a;…

python学opencv|读取视频(一)灰度视频制作和保存

【1】引言 上一次课学习了用opencv读取图像&#xff0c;掌握了三个函数&#xff1a;cv.imread()、cv.imshow()、cv.imwrite() 相关链接如下&#xff1a; python学opencv|读取图像-CSDN博客 这次课我们继续&#xff0c;来学习用opencv读取视频。 【2】学习资源 首先是官网…

BioDeepAV:一个多模态基准数据集,包含超过1600个深度伪造视频,用于评估深度伪造检测器在面对未知生成器时的性能。

2024-11-29, 由罗马尼亚布加勒斯特大学创建BioDeepAV数据集&#xff0c;它专门设计来评估最先进的深度伪造检测器在面对未见过的深度伪造生成器时的泛化能力&#xff0c;这对于提高检测器的鲁棒性和适应性具有重要意义。 数据集地址&#xff1a;biodeep 一、研究背景&#xff1…

Apache Airflow 快速入门教程

Apache Airflow已经成为Python生态系统中管道编排的事实上的库。与类似的解决方案相反&#xff0c;由于它的简单性和可扩展性&#xff0c;它已经获得了普及。在本文中&#xff0c;我将尝试概述它的主要概念&#xff0c;并让您清楚地了解何时以及如何使用它。 Airflow应用场景 …

【OpenAI库】从0到1深入理解Python调用OpenAI库的完整教程:从入门到实际运用

文章目录 Moss前沿AI一、初识OpenAI API1.1 获取API-Key&#xff08;两种方案&#xff09;1.2 安装OpenAI库 二、Python调用OpenAI API的基础设置2.1 设置API密钥和Base URL2.2 参数详解 三、构建一个简单的聊天应用3.1 创建聊天请求3.2 参数详解3.3 处理响应 四、完整代码示例…

42 基于单片机的智能浇花系统

目录 一、主要功能 二、硬件资源 三、程序编程 四、实现现象 一、主要功能 基于51单片机&#xff0c;采样DHT11温湿度传感器检测温湿度&#xff0c;通过LCD1602显示 4*4按键矩阵可以设置温度湿度阈值&#xff0c;温度大于阈值则开启水泵&#xff0c;湿度大于阈值则开启风扇…

typecho 添加主题备份及恢复功能

typecho 换主题很简单&#xff0c;但是确有一个比较麻烦的事情&#xff0c;就是主题配置在切换主题的同时也就被删除了。于是&#xff0c;今天我下决心要弄一个备份恢复的功能出来。网上查了很久&#xff0c;都没有找到适合的&#xff08;不过还是有参考价值的&#xff09;。最…

docker部署RustDesk自建服务器

客户端&#xff1a; Releases rustdesk/rustdesk GitHub 服务端&#xff1a; 项目官方地址&#xff1a;GitHub - rustdesk/rustdesk-server: RustDesk Server Program 1、拉取RustDesk库 docker pull rustdesk/rustdesk-server:latest 阿里云库&#xff1a; docker pu…

从零开始了解推荐系统(算法构建、召回、粗排、精排、重排、冷启动、衡量标准)

算法构建 推荐算法流程 实际上是一种信息处理逻辑&#xff0c;当获取了用户与内容的信息之后&#xff0c;按照一定的逻辑处理信息后&#xff0c;产生推荐结果。热度排行榜就是最简单的一种推荐方法&#xff0c;依赖的逻辑是当一个内容被大多数用户喜欢&#xff0c;那么大概率…

【第 1 章 初识 C 语言】1.8 使用 C 语言的 7 个步骤

目录 1.8 使用 C 语言的 7 个步骤 1.8.1 第 1 步&#xff1a;定义程序的目标 1.8.2 第 2 步&#xff1a;设计程序 1.8.3 第 3 步&#xff1a;编写代码 1.8.4 第 4 步&#xff1a;编译 1.8.5 第 5 步&#xff1a;运行程序 1.8.6 第 6 步&#xff1a;测试和调试程序 1.8.…

基于Matlab卡尔曼滤波的GPS/INS集成导航系统研究与实现

随着智能交通和无人驾驶技术的迅猛发展&#xff0c;精确可靠的导航系统已成为提升车辆定位精度与安全性的重要技术。全球定位系统&#xff08;GPS&#xff09;和惯性导航系统&#xff08;INS&#xff09;在导航应用中各具优势&#xff1a;GPS提供全球定位信息&#xff0c;而INS…

C++知识整理day3类与对象(下)——赋值运算符重载、取地址重载、列表初始化、友元、匿名对象、static

文章目录 1.赋值运算符重载1.1 运算符重载1.2 赋值运算符重载 2.取地址重载2.1 const成员函数2.2 取地址运算符重载 3.类与对象的补充3.1 再探构造函数---初始化列表3.2 类型转换3.3 static成员3.4 友元3.5 内部类3.6 匿名对象3.7 对象拷贝时的编译器优化 1.赋值运算符重载 赋…