目次
消息队列
一、为什么使用消息队列？消息队列有什么长处/缺点？先容下Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么长处缺点，怎样弃取？
1.公司业务场景是什么，这个业务场景有什么寻衅，如果不消MQ有什么贫困，现在用了MQ有什么利益
2.消息队列长处：
解耦(担心挂)
异步
削峰
3.消息队列缺点：
整个体系可用性低沉(外部依赖变多，MQ挂了，体系挂了)；复杂度变高（须要注意消息重复，消息遗漏，消息序次）；引入了划一性题目(A体系完成返回乐成，用户以为乐成，但B/C/D体系那边某个失败了，那就数据差别等了)
体系复杂度进步，可用性降落，还须要包管划一性
以是须要额外的架构来规避上述题目
4.Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么长处缺点，怎样弃取？
中小型公司用rabbitmq，社区活泼，根本满足需求;大型公司研发本领雄厚，可用rocketmq;大数据实时范畴用kafka很尺度;
二、怎样包管消息队列的高可用性？
RabbitMQ(主从架构)
镜像集群模式，是每个节点上都有queue和数据。写消息到queue时，会主动把消息同步到多个实例的queue上。
Kafka(切分消息+replica副本机制)
broker，topic，partition，repilication
三、怎样包管消息不被重复斲丧？怎样包管斲丧消息的幂等性？(全局唯一标识ack /offset)
1.消息本身该有全局唯一标识，rabbitmq是ack，kafka是offset，纪录下来每次斲丧到哪个号码了
2.团结业务，制止重复斲丧产生影响。好比数据库的唯一键/主键，好比搭配redis
四、怎样包管消息不会丢失？
三个大概性，生产者发送给MQ时丢失了；MQ本身丢失了；MQ发给斲丧者丢失了
生产端弄丢了数据(事故机制 offset)
MQ弄丢了数据(元数据长期化+confirmed机制)
斲丧端弄丢了数据(关闭主动提交offset)
关闭主动提交offset，重复斲丧包管幂等性
brocker宕机，重新推选partition的leader，但其他follower还没同步好数据，就会有数据丢失的题目
五、怎样包管消息的序次性？(写入的序次、读取的序次)
消息是序次性有两个方面，一个是写入消息的序次，一个是读取的序次
写入时要包管序次，key来确认分配到哪个partition，一个partition对应一个斲丧者，
rabbitmq queue
kafka 一个topic，一个partition，一个consumer，内部单线程斲丧，这种吞吐低。
六、消息如果延时了大概处置处罚过慢大概积蓄了几百万消息大概逾期了怎么办理
七、如果让你写一个消息队列怎样举行架构计划？
体系可拓展性
数据落地磁盘
mq的高可用性
数据0丢失
Kafka
根本概念
脚色术语
Broker
Topic
Record
Partition
Offset
Replica
Producer
Consumer
Consumer Offset
Consumer Group
Rebalance
ISR
HW
LEO
拓扑架构
Topic、Partition、Segment、.log、.index、Message
Kafka分布式集群构建
焦点计划原理
消息队列
- 一、为什么使用消息队列？消息队列有什么长处/缺点？先容下Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么长处缺点，怎样弃取？
- 1.公司业务场景是什么，这个业务场景有什么寻衅，如果不消MQ有什么贫困，现在用了MQ有什么利益
- 举行投后业务场景后端从sqlServer无感知切花u你Mysql此中的数据校验。这个业务场景的寻衅点就在于怎样在真实场景中验证业务逻辑(写利用)的准确性，并包管不影响运营数据的维护，确保上线无题目。这就须要一套前端，一个利用，触发两个哀求，一个是原有sqlserver 的哀求，另一个是对Mysql数据库利用，紧张使用了消息队列实现了双写利用，确保了原有运营数据的正常维护而且后端职员能在最真实最全面的待上线体系中实时举行数据对比
- 2.消息队列长处：
- 解耦(担心挂)
- 通过发布订阅消息这个模子，使体系与体系之间解耦，挂了也不影响团体，
- 削峰
- 有些时间段业务繁忙，但现实并不须要非常快速相应，可以使用消息队列实现匀称处置处罚消息，包管节点不会挂
- 3.消息队列缺点：
- 整个体系可用性低沉(外部依赖变多，MQ挂了，体系挂了)；复杂度变高（须要注意消息重复，消息遗漏，消息序次）；引入了划一性题目(A体系完成返回乐成，用户以为乐成，但B/C/D体系那边某个失败了，那就数据差别等了)
- 4.Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么长处缺点，怎样弃取？
- 中小型公司用rabbitmq，社区活泼，根本满足需求;大型公司研发本领雄厚，可用rocketmq;大数据实时范畴用kafka很尺度;
- 二、怎样包管消息队列的高可用性？
- RabbitMQ(主从架构)
- 有几种模式，第一种平常集群模式，是一个元数据queue存储信息，斲丧者拉数据访问到其他节点时，其他节点到queue所在节点拉数据，复制到其他节点再返回。
- 镜像集群模式，是每个节点上都有queue和数据。写消息到queue时，会主动把消息同步到多个实例的queue上。
- 网络传输开销大；而且如许对于大消息是存储不了的，存储方面有瓶颈
- Kafka(切分消息+replica副本机制)
- broker，topic，partition，repilication
- kafka由多个broker构成，每个broker是一个节点；一个topic可以分别为多个partition，每个partition可以存在于差别的broker上，每个partition就放一部门数据。（切分消息了，真正的分布式）
- kafka0.8以后，多了replica（复成品）副本机制。每个partition的数据都会同步到其他broker上，而且推选leader，leader负责同步data到follower；生产和斲丧都只跟leader沟通，包管数据划一性。
- 写数据时，生产者写leader，leader将数据落入本地磁盘，接着其他follower本身主动到leader来Pull数据，一旦全部follower同步好数据，就会发送ack给leader,leader收到全部follower的ack后，就会返回写乐成的消息给生产者。
- 读数据时，读leader，leader如果挂了，就重新推选leader，读新leader；但是只有当一个消息已经被全部follower都同步乐成返回ack的时间，才会被斲丧者读到。
- 三、怎样包管消息不被重复斲丧？怎样包管斲丧消息的幂等性？(全局唯一标识ack /offset)
- 1.消息本身该有全局唯一标识，rabbitmq是ack，kafka是offset，纪录下来每次斲丧到哪个号码了
- 2.团结业务，制止重复斲丧产生影响。好比数据库的唯一键/主键，好比搭配redis
- 四、怎样包管消息不会丢失？
- 三个大概性，生产者发送给MQ时丢失了；MQ本身丢失了；MQ发给斲丧者丢失了
- 生产端弄丢了数据(事故机制 offset)
- rabbitmq(事故机制)
- 生产者开启事故机制，得到确认才commit，否则rollback（同步的）
- 生产者开启confirmed机制，每个消息有唯一id，一段时间没有得到ack就重发该消息。（异步的）
- MQ弄丢了数据(元数据长期化+confirmed机制)
- rabbitmq
- 开启rabbitmq元数据queue的长期化和消息的长期化，长期化到磁盘
- confirmed机制和长期化搭配起来，只有消息被长期化到磁盘，才发送ack关照生产者
- 斲丧端弄丢了数据(关闭主动提交offset)
- kafka
- brocker宕机，重新推选partition的leader，但其他follower还没同步好数据，就会有数据丢失的题目
- 1.给topic的partition设置副本数要大于即是2
- 2.在producer端设置acks=all，要求每条数据必须写入全部replica后，才气以为是写乐成了
- 3.在producer端设置reties=MAX，要求一旦写入失败则无穷充实
- 4.给kafka服务端设置min.insync.replicas>=1，要求一个leader感知到治沙一个follower还跟本身保持接洽清除后，如许才气确保Leader挂了尚有一个follower
- 五、怎样包管消息的序次性？(写入的序次、读取的序次)
- 消息是序次性有两个方面，一个是写入消息的序次，一个是读取的序次
- 写入时要包管序次，key来确认分配到哪个partition，一个partition对应一个斲丧者，
- rabbitmq queue
- 拆分为多个queue，每个queue对应一个consumer；大概就一个queue，一个consumer，该consumer内部用内存队列列队，分发给差别的worker来处置处罚
- kafka 一个topic，一个partition，一个consumer，内部单线程斲丧，这种吞吐低。
- 一个topic，一个partition，一个consumer，内部单线程斲丧，这种吞吐低。
- 写N个内存queue，具有雷同key的数据都到同一个内存queue，但是对于N个线程，每个线程分别斲丧一个内存queue即可。（多个queue，多个线程，但是queue与线程1V1）
- 六、消息如果延时了大概处置处罚过慢大概积蓄了几百万消息大概逾期了怎么办理
- 2.征用呆板，扩大partition到十倍，consumer到十倍，十倍速率举行快速斲丧（暂时分发数据的consumer步调中，斲丧之后不做耗时处置处罚，直接匀称轮询写入暂时创建好的10倍数目的的queue）
- 快写满了：先用1,2,3举行快速斲丧数据，然后晚上再补捞数据
- 七、如果让你写一个消息队列怎样举行架构计划？
- 体系可拓展性
- kafka的计划理念：broker->topic->partition，每个partition存放一个呆板，存一部门数据，资源不敷，给topic增长partition，做数据迁徙，增长呆板
- 数据落地磁盘
- 序次写，制止磁盘随机读写的寻址开销。磁盘序次读写的性能高
- mq的高可用性
- replica副本机制->leader&follewer->broker挂了重新推选Leader即可对外服务
- 斲丧端Rebalance，某斲丧者实例挂掉后，再均衡分配实例
- 数据0丢失
- 数据多了怎么办，大了怎么办，丢了怎么办，重复斲丧了怎么办，逾期了怎么办，包管序次怎么办
- Kafka
- 根本概念
- 高吞吐的分布式发布/订阅消息体系，即 为差别体系之间转达消息的
- 脚色术语
- Broker
- 数据存储中心。每个kafka集群包罗一个或多个服务器，每个服务器被称为broker
- Topic
- 每条发布到Kafka集群的消息都有个分类，种别即为Topic(主题)，用来区分具体业务
- Partition
- 每个Topic包罗一个或多个Partition，每个Partition都是有序稳定的队列，Partition中的每条消息都会被分配一个唯一ID （称为offset）
- Producer
- 消息的生产者，负责发布消息push到kafka broker
- Consumer
- 消息的斲丧者，负责到broker去pull消息来斲丧
- Consumer Group
- 斲丧者组，可以给每个consumer指定斲丧者组，若不指定，则为默认的group。同时斲丧多个Partition以实现高吞吐
- Rebalance
- 再均衡。斲丧者组内某个斲丧实例挂掉后，其他斲丧者实例主动重新分配订阅主题分区的过程。Rebalance是Kafka斲丧者端实现高可用的紧张本领。
- ISR
- In-Sync Replica Set.ISR聚集代表每个分区的一组同步聚集，处于 ISR 聚集中的副本，意味着 follower 副本与 leader 副本保持同步状态，只有处于 ISR 聚集中的副本才有资格被推选为 leader
- HW
- HightWatermark，水位线，指的是斲丧者能见到的最大的offset，ISR队列中最小的LEO
- LEO
- Log End Offset, 指的是每个副本最大的offset；
- 拓扑架构
- 多个producer，多个broker，多个 consumer group，外加一个zookeeper。zookeeper来举行管理集群设置，推选Leader，在Consumer Group发生厘革时举行rebalance。
- Producer push 消息 发布到broker，consumer使用pull模式从broker订阅并斲丧消息。
- 生产者将消息分布到差别broker上的差别partition上，斲丧者可以斲丧集群中多个节点的多个partition。
- 写消息时，允很多个生产者写道同一个partition中
- 但读消息时，一个partition只能被一个斲丧者组的一个斲丧者读，但是可以同时被其他斲丧组读取。（斲丧者组内的斲丧者读partition互斥）
- 支持消息长期化存储。长期化数据存储在log日记文件中。（先缓存在内存，到达肯定阈值再同一写入磁盘，镌汰磁盘IO调用次数）
- 消息写入Partition，是序次写入磁盘的，制止随机读写的 “寻头”磁头不绝移动(磁盘的性能瓶颈之一，SSD破例)
- Topic、Partition、Segment、.log、.index、Message
- topic的partition数字决定了构成topic的log的数目，>=同时运行的consumer，>集群broker的数目，尽大概匀称分布在broker中
- kafka是基于文件存储的，partition可用来拆分topic，将大量消息分成多批写到差别节点上，均衡负载。
- 每个partition对应一个文件夹，存储该partition的消息，以巨细相当的segment文件夹为单元，内容为 消息索引(.index)和消息数据(.log)。partition定名为topic+序号(0,1,...)
- Partition文件夹的定名，Segment文件夹的定名，.index 和 .log的切分和定名
- Kafka分布式集群构建
- kafka2.8.0版本中移除了对Zookeeper的依赖，通过KRaft举行本身的集群管理。
- 一些设置参数：
- brocker.id
- 若服务器ip所在厘革时，只要brocker.id没有变，就不会影响consumer的斲丧
- logs.segment.bytes
- 设置每个segment数据文件的巨细，默认是1G，高出这个巨细会主动创建一个新的segment
- delete.topic.enable
- 在0.8.2版本之后，kafka提供的删除topic 的功能，但是默认不会物理删除topic数据。如果须要物理删除，设为true
- acks
- 指定必须多少个分区副本收到消息，生产者才会以为写入消息是乐成的。（对消息丢失的大概性有庞大影响）
- acks=0：写入消息之前不会期待任何来自服务器的相应，轻易丢消息，但是吞吐量高
- aks=1(leader)：只要集群的leader节点收到消息，生产者就会收到来自服务器的乐成相应。可靠性中等，leader如果发生题目,follower将来得及同步，就会丢失部门数据
- acks=-1(all)：只有当全部加入复制的节点都收到消息，生产者才会收到一个来自服务器的乐成相应。延长高。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
|
发表于 
