sfklyqh的博客

现在常用的绝大部分消息队列提供的服务质量都是At least once（至少一次，不允许丢失消息，但是允许有少量重复消息出现），包括RocketMQ、RabbitMQ和Kafka都是这样。也就是说，消息队列很难保证消息不重复。

消息从生产到消费的过程，可以划分为三个阶段：生产阶段：在这个阶段，从消息在Producer创建出来，经过网络传输发送到Broker端。存储阶段：在这个阶段，消息在Broker端存储，如果是集群，消息会在这个阶段被复制到其他副本上。消费阶段：在这个阶段，Consumer从Broker上拉取消息，经过网络传输发送到Consumer上。

一、 RocketMQ特点具有灵活的可扩展性。 RocketMQ 天然支持集群，其核心四大组件（NameServer、Broker、 Producer、Consumer）的每一个都可以在没有单点故障的情况下进行水平扩展。具有海量消息堆积能力。RocketMQ 采用零拷贝原理实现了超大量消息的堆积能力。支持顺序消息。RocketMQ 可以保证消息消费者按照消息发送的顺序对消息进行消费。消息分为全局有序消息和局部有序消息，一般推荐使用局部有序消息，即生产者通过某一类消息顺序发生至同一队列中来实现。

一、分区在使用 Kafka 作为消息队列时，不管是发布还是订阅都需要指定主题（Topic），但这里的主题只是一个逻辑上的概念，实际上 Kafka 基本存储单元是分区（ Parition ），在一个Topic中会有一个或多个Partiton...

一、Kafka特点为发布和订阅提供高吞吐量 消息持久化，将消息持久化到磁盘，可用于批量消费 分布式，支持服务器间的消息分区以及分布式消费 消息消费采用PULL模式：消息被处理的状态是在Consumer端维护的，而不是由服务器端维护的，Broker 无状态，Consumer 自己保存 offset 支持Online和Offline场景，同时支持离线数据处理和实时数据处理二、基本概念Broker：Kafka集群中的一台或多台服务器 Topic：发布到Kafka的每条消息都有一个类别，这个类别

一、为何要用消息队列场景举例某天产品人员说：系统要增加一个用户注册功能，注册成功后用户能受到邮件通知。方案一：提供一个注册页面，点击按钮提交之后保存用户的注册信息，然后发送邮件，最后返回用户注册成功问题：点击注册按钮之后响应有点慢，开发人员想到的优化方案是保存注册信息与发送邮件分开执行。方案二：单独启动线程来做发送邮件的事情问题：注册操作的响应是快乐，但有用户反映没收到注册成功的邮件，能不能再在发送邮件的时候先保存发送邮件的内容，如果邮件发送失败了则进行补发方案三：提供一个类

一、分布式应用和集群的区别如果一个业务被拆分成多个子业务部署在不同服务器上，那就是分布式应用 如果时同一个业务部署在多台服务器上，那几十集群二、系统间的通信方式基于远程过程调用的方式 基于消息队列的方式2.1 基于远程过程调用的方式（RPC）RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。它是协议，是一种规范，需要有遵循这套规范的实现。典型的RPC实现包括Dubbo、Thrift、GRPC等 网络通信的实现是透明的，调用放不需要关心网络之间的通信协议