MQ
森林森
java学习
展开
-
RocketMq-Producer
Producer消息生产者的代码都在client模块中,相对于RocketMQ来讲,消息生产者就是客户端,也是消息的提供者方法和属性//创建主题void createTopic(final String key, final String newTopic, final intqueueNum) throws MQClientException;//根据时间戳从队列中查找消息偏移量long searchOffset(final MessageQueue mq, final long ti原创 2020-11-20 12:29:11 · 294 阅读 · 0 评论 -
RocketMq-NameServer
NameServer消息中间件的设计思路一般是基于主题订阅发布的机制。生产者(Producer)发送消息到消息服务器的某个主题,消息服务器负责将消息持久化存储消息消费者(Consumer)订阅该兴趣的主题,消息服务器根据订阅信息(路由信息)将消息推送到消费者(Push模式)或者消费者主动向消息服务器拉去(Pull模式),从而实现消息生产者与消息消费者解耦。为了避免消息服务器的单点故障,部署多台消息服务器共同承担消息的存储。生产者如何知道消息要发送到哪台消息服务器呢?如果某一台消息服务器宕机了,生原创 2020-11-20 11:19:32 · 473 阅读 · 0 评论 -
Rocketmq-导入源码
下载从官方仓库 https://github.com/apache/rocketmq clone 或者 download 源码broker: broker 模块(broke 启动进程)client :消息客户端,包含消息生产者、消息消费者相关类common :公共包dev :开发者信息(非源代码)distribution :部署实例文件夹(非源代码)example: RocketMQ 例代码filter :消息过滤相关基础类filtersrv:消息过滤服务器实现相关类(Filter启动进原创 2020-11-20 09:29:11 · 253 阅读 · 0 评论 -
Rocketmq-运维常见问题
运维常见问题RocketMQ的mqadmin命令报错问题问题描述:有时候在部署完RocketMQ集群后,尝试执行“mqadmin”一些运维命令,会出现下面的异常信息:org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to<null> failed解决方法:可以在部署RocketMQ集群的虚拟机上执行 export NAMESRV_ADDR=ip:9876 (ip指的是集群中部署Nam原创 2020-11-19 17:22:14 · 1519 阅读 · 0 评论 -
RocketMq-mqadmin管理工具
mqadmin管理工具执行命令方法: ./mqadmin {command} {args}几乎所有命令都需要配置-n表示NameServer地址,格式为ip:port几乎所有命令都可以通过-h获取帮助如果既有Broker地址(-b)配置项又有clusterName(-c)配置项,则优先以Broker地址执行命令,如果不配置Broker地址,则对集群中所有主机执行命令,只支持一个Broker地址。-b格式为ip:port,port默认是10911在tools下可以看到很多命令,但并不是所有命令都能原创 2020-11-19 17:16:56 · 2383 阅读 · 1 评论 -
RocketMq-集群-2m-slave-sync搭建
下载RocketMQ版本:4.5.1https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.5.1/rocketmq-all-4.5.1-bin-release.zipwget https://archive.apache.org/dist/rocketmq/4.5.1/rocketmq-all-4.5.1-bin-release.zipunzip rocketmq-all-4.5.1-bin-release.zip -d /opt/ cd原创 2020-11-19 16:33:18 · 126 阅读 · 0 评论 -
RocketMq-集群
集群特点NameServer是一个几乎无状态节点,可集群部署,节点之间无任何信息同步Broker部署相对复杂,Broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,rokerId为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接,定时注册Top原创 2020-11-19 13:37:39 · 167 阅读 · 0 评论 -
RocketMQ-动态扩缩容
动态扩缩容动态增减Namesrv机器NameServer是RocketMQ集群的协调者,集群的各个组件是通过NameServer获取各种属性和地址信息的。主要功能包括两部分:一个各个Broker定期上报自己的状态信息到NameServer;另一个是各个客户端,包括Producer、Consumer,以及命令行工具,通过NameServer获取最新的状态信息。所以,在启动Broker、生产者和消费者之前,必须告诉它们NameServer的地址,为了提高可靠性,建议启动多个NameServer。原创 2020-11-19 10:17:52 · 2273 阅读 · 0 评论 -
RocketMq-客户端配置
客户端配置相对于RocketMQ的Broker集群,生产者和消费者都是客户端DefaultMQProducer、TransactionMQProducer、DefaultMQPushConsumer、DefaultMQPullConsumer都继承于ClientConfig类,ClientConfig为客户端的公共配置类。客户端的配置都是get、set形式,每个参数都可以用spring来配置,也可以在代码中配置。例如namesrvAddr这个参数可以这样配置,producer.setNamesrv原创 2020-11-19 10:10:21 · 1054 阅读 · 0 评论 -
RocketMq-事务消息
事务消息RocketMQ的事务消息,是指发送消息事件和其他事件需要同时成功或同时失败。比如银行转账,A银行的某账户要转一万元到B银行的某账户。A银行发送“B银行账户增加一万元”这个消息,要和“从A银行账户扣除一万元”这个操作同时成功或者同时失败。RocketMQ采用两阶段提交的方式实现事务消息,TransactionMQProducer处理上面情况的流程是,先发一个“准备从B银行账户增加一万元”的消息,发送成功后做从A银行账户扣除一万元的操作,根据操作结果是否成功,确定之前的“准备从B银行账户增加一万元原创 2020-11-18 10:04:25 · 290 阅读 · 0 评论 -
RocketMq-顺序消息
顺序消息顺序消息是指消息的消费顺序和产生顺序相同,在有些业务逻辑下,必须保证顺序。比如订单的生成、付款、发货,这3个消息必须按顺序处理才行。顺序消息分为全局顺序消息和部分顺序消息:全局顺序消息指某个Topic下的所有消息都要保证顺序;部分顺序消息只要保证每一组消息被顺序消费即可,比如上面订单消息的例子,只要保证同一个订单ID的三个消息能按顺序消费即可。在多数的业务场景中实际上只需要局部有序就可以了RocketMQ在默认情况下不保证顺序,比如创建一个Topic,默认八个写队列,八个读队列。原创 2020-11-18 09:54:27 · 303 阅读 · 0 评论 -
RocketMq- 延迟消息
延迟消息时消息(延迟队列)是指消息发送到broker后,不会立即被消费,等待特定时间投递给真正的topic。 broker有配置项messageDelayLevel,默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”,18个level。可以配置自定义messageDelayLevel。注意,messageDelayLevel是broker的属性,不属于某个topic。发消息时,设置delayLevel等级即可:msg.se原创 2020-11-18 09:47:26 · 756 阅读 · 0 评论 -
RocketMq-死信队列
死信队列RocketMQ中消息重试超过一定次数后(默认16次)就会被放到死信队列中,在消息队列RocketMQ 中,这种正常情况下无法被消费的消息称为死信消息(Dead-Letter Message),存储死信消息的特殊队列称为死信队列(Dead-Letter Queue)。可以在控制台Topic列表中看到“DLQ”相关的Topic,默认命名是:%RETRY%消费组名称(重试Topic)%DLQ%消费组名称(死信Topic)死信队列也可以被订阅和消费,并且也会过期可视化工具:rocketmq原创 2020-11-18 09:44:16 · 8414 阅读 · 0 评论 -
RocketMq-消息重试
消息重试顺序消息的重试对于顺序消息,当消费者消费消息失败后,消息队列 RocketMQ 会自动不断进行消息重试(每次间隔时间为 1 秒),这时,应用会出现消息消费被阻塞的情况。因此,在使用顺序消息时,务必保证应用能够及时监控并处理消费失败的情况,避免阻塞现象的发生。DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumer_grp_04_01");consumer.setNamesrvAddr("node1:9876");原创 2020-11-18 09:35:37 · 624 阅读 · 0 评论 -
RocketMq-负载均衡
负载均衡RocketMQ中的负载均衡都在Client端完成,具体来说的话,主要可以分为Producer端发送消息时候的负载均衡和Consumer端订阅消息的负载均衡。Producer的负载均衡5 个队列可以部署在一台机器上,也可以分别部署在 5 台不同的机器上,发送消息通过轮询队列的方式 发送,每个队列接收平均的消息量。通过增加机器,可以水平扩展队列容量。 另外也可以自定义方式选择发往哪个队列mqadmin updateTopic -n localhost:9876 -t tp_demo_02原创 2020-11-18 09:16:50 · 1272 阅读 · 0 评论 -
RocketMq-刷盘机制
刷盘机制RocketMQ 的所有消息都是持久化的,先写入系统 PageCache,然后刷盘,可以保证内存与磁盘都有一份数据, 访问时,直接从内存读取。消息在通过Producer写入RocketMQ的时候,有两种写磁盘方式,分布式同步刷盘和异步刷盘。同步刷盘同步刷盘与异步刷盘的唯一区别是异步刷盘写完 PageCache直接返回,而同步刷盘需要等待刷盘完成才返回, 同步刷盘流程如下:(1). 写入 PageCache后,线程等待,通知刷盘线程刷盘。(2). 刷盘线程刷盘后,唤醒前端等待线程,可能是原创 2020-11-18 09:06:25 · 1328 阅读 · 0 评论 -
RocketMq-高可用机制
高可用机制RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。Master和Slave的区别:在Broker的配置文件中,参数brokerId的值为0表明这个Broker是Master,大于0表明这个Broker是Slave,brokerRole参数也说明这个Broker是Master还是Slave。(SYNC_MASTER/ASYNC_MASTER/SALVE)Master角色的Broker支持读和写,Slave角色的Broker仅支持读。Consumer可以连原创 2020-11-18 09:03:56 · 1872 阅读 · 0 评论 -
RocketMq-同步复制和异步复制
同步复制和异步复制如果一个Broker组有Master和Slave,消息需要从Master复制到Slave 上,有同步和异步两种复制方式1)同步复制同步复制方式是等Master和Slave均写 成功后才反馈给客户端写成功状态;在同步复制方式下,如果Master出故障,Slave上有全部的备份数据,容易恢复,但是同步复制会增大数据写入延迟,降低系统吞吐量。2)异步复制异步复制方式是只要Master写成功 即可反馈给客户端写成功状态。在异步复制方式下,系统拥有较低的延迟和较高的吞吐量,但是如果Ma原创 2020-11-18 09:00:54 · 1700 阅读 · 0 评论 -
RocketMQ-零拷贝
零拷贝原理原创 2020-11-18 08:58:49 · 731 阅读 · 0 评论 -
RocketMQ-消息发送-消费-消息存储
消息发送生产者向消息队列里写入消息,不同的业务场景需要生产者采用不同的写入策略。比如同步发送、异步发送、Oneway发送、延迟发送、发送事务消息等。 默认使用的是DefaultMQProducer类,发送消息要经过五个步骤:1)设置Producer的GroupName。2)设置InstanceName,当一个Jvm需要启动多个Producer的时候,通过设置不同的InstanceName来区分,不设置的话系统使用默认名称“DEFAULT”。3)设置发送失败重试次数,当网络出现异常的时候,这个次数影原创 2020-11-17 19:41:50 · 807 阅读 · 0 评论 -
RocketMq-单机安装
下载RocketMQ版本:4.5.1https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.5.1/rocketmq-all-4.5.1-bin-release.zipwget https://archive.apache.org/dist/rocketmq/4.5.1/rocketmq-all-4.5.1-bin-release.zip修改脚本 JDK 11要修改bin/runserver.shbin/runbroker.shbin原创 2020-11-17 14:47:56 · 91 阅读 · 0 评论 -
RocketMq-基本概念
RocketMQ的使用场景应用解耦系统的耦合性越高,容错性就越低。以电商应用为例,用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障或者因为升级等原因暂时不可用,都会造成下单操作异常,影响用户使用体验。流量削峰应用系统如果遇到系统请求流量的瞬间猛增,有可能会将系统压垮。有了消息队列可以将大量请求缓存起来,分散到很长一段时间处理,这样可以大大提到系统的稳定性和用户体验。举例:业务系统正常时段的QPS如果是1000,流量最高峰是10000,为了应对流量高峰配置高性能的服务原创 2020-11-17 11:41:37 · 156 阅读 · 0 评论 -
kafka-ngx_kafka_module
使用Kafka做日志收集。一、需要收集的信息:1、用户ID(user_id)2、时间(act_time)3、操作(action,可以是:点击:click,收藏:job_collect,投简历:cv_send,上传简历:cv_upload)4、对方企业编码(job_code)git clone https://github.com/edenhill/librdkafkacd librdkafka./configuremakesudo make install下载模块git clon原创 2020-11-16 19:26:19 · 350 阅读 · 0 评论 -
kafka-集群搭建
集群搭建分配三台Linux,用于安装拥有三个节点的Kafka集群。linux141(192.168.181.141)linux142(192.168.181.142)linux144(192.168.181.144)以上三台主机的/etc/hosts配置:192.168.181.141-linux140192.168.181.142-linux141192.168.181.144-linux144安装zookeeper# 解压到/opt目录tar -zxf zookeeper-3.4原创 2020-11-16 10:43:09 · 274 阅读 · 0 评论 -
kafka-延时队列
延时队列两个follower副本都已经拉取到了leader副本的最新位置,此时又向leader副本发送拉取请求,而leader副本并没有新的消息写入,那么此时leader副本该如何处理呢?可以直接返回空的拉取结果给follower副本,不过在leader副本一直没有新消息写入的情况下,follower副本会一直发送拉取请求,并且总收到空的拉取结果,消耗资源Kafka在处理拉取请求时,会先读取一次日志文件,如果收集不到足够多(fetchMinBytes,由参数fetch.min.bytes配置,默认值为原创 2020-11-14 17:47:35 · 2465 阅读 · 1 评论 -
kafka-集群应用场景
集群应用场景消息传递Kafka可以很好地替代传统邮件代理。消息代理的使用有多种原因(将处理与数据生产者分离,缓冲未处理的消息等)。与大多数邮件系统相比,Kafka具有更好的吞吐量,内置的分区,复制和容错功能,这使其成为大规模邮件处理应用程序的理想解决方案。根据我们的经验,消息传递的使用通常吞吐量较低,但是可能需要较低的端到端延迟,并且通常取决于Kafka提供的强大的持久性保证。在这个领域,Kafka与ActiveMQ或 RabbitMQ等传统消息传递系统相当网站活动路由Kafka最初的用例是能够原创 2020-11-14 17:06:34 · 290 阅读 · 0 评论 -
kafka-重试队列
重试队列kafka没有重试机制不支持消息重试,也没有死信队列,因此使用kafka做消息队列时,需要自己实现消息重试的功能。实现创建新的kafka主题作为重试队列:创建一个topic作为重试topic,用于接收等待重试的消息。普通topic消费者设置待重试消息的下一个重试topic。从重试topic获取待重试消息储存到redis的zset中,并以下一次消费时间排序定时任务从redis获取到达消费事件的消息,并把消息发送到对应的topic同一个消息重试次数过多则不再重试实现pom.xm原创 2020-11-14 17:03:50 · 1126 阅读 · 0 评论 -
kafka-__consumer_offsets
__consumer_offsetszookeeper不适合大批量的频繁写入操作。Kafka 1.0.2将consumer的位移信息保存在Kafka内部的topic中,即__consumer_offsets主题,并且默认提供了kafka_consumer_groups.sh脚本供用户查看consumer信息1. 创建topic “tp_test_01 kafka-topics.sh --zookeeper node1:2181/myKafka --create --topic tp_test_01原创 2020-11-14 15:35:08 · 1374 阅读 · 0 评论 -
kafka-消息重复的场景及解决方案
消息重复和丢失是kafka中很常见的问题,主要发生在以下三个阶段:生产者阶段broke阶段消费者阶段生产者阶段重复场景根本原因生产发送的消息没有收到正确的broke响应,导致生产者重试。生产者发出一条消息,broke落盘以后因为网络等种种原因发送端得到一个发送失败的响应或者网络中断,然后生产者收到一个可恢复的Exception重试消息导致消息重复说明:new KafkaProducer()后创建一个后台线程KafkaThread扫描RecordAccumulator中是否有消息原创 2020-11-14 15:27:40 · 1577 阅读 · 0 评论 -
kafka-一 致性
一致性保证一、概念水位标记水位或水印(watermark)一词,表示位置信息,即位移(offset)。Kafka源码中使用的名字是高水位,HW(high watermark)。副本角色Kafka分区使用多个副本(replica)提供高可用。LEO和HW每个分区副本对象都有两个重要的属性:LEO和HW。LEO:即日志末端位移(log end offset),记录了该副本日志中下一条消息的位移值。如果LEO=10,那么表示该副本保存了10条消息,位移值范围是[0, 9]。另外,Leader转载 2020-11-14 14:22:57 · 164 阅读 · 0 评论 -
kafka-稳定性-控制器
控制器afka集群包含若干个broker,broker.id指定broker的编号,编号不要重复。Kafka集群上创建的主题,包含若干个分区。每个分区包含若干个副本,副本因子包括了Follower副本和Leader副本。副本又分为ISR(同步副本分区)和OSR(非同步副本分区)控制器就是一个broker控制器除了一般broker的功能,还负责Leader分区的选举broker选举集群里第一个启动的broker在Zookeeper中创建临时节点 /controller 。其他broker在原创 2020-11-14 14:05:04 · 175 阅读 · 0 评论 -
kafka-稳定性-事务
稳定性事务一、事务场景如producer发的多条消息组成一个事务这些消息需要对consumer同时可见或者同时不可见 。producer可能会给多个topic,多个partition发消息,这些消息也需要能放在一个事务里面,这就形成了一个典型的分布式事务。kafka的应用场景经常是应用先消费一个topic,然后做处理再发到另一个topic,这个consume-transform-produce过程需要放到一个事务里面,比如在消息处理或者发送的过程中如果失败了,消费偏移量也不能提交。produc原创 2020-11-14 13:18:01 · 725 阅读 · 0 评论 -
kafka-日志存储
日志存储Kafka 消息是以主题为单位进行归类,各个主题之间是彼此独立的,互不影响。每个主题又可以分为一个或多个分区。每个分区各自存在一个记录消息数据的日志文件创建了一个 tp_demo_01 主题,其存在6个 Parition,对应的每个Parition下存在一个[Topic-Parition] 命名的消息日志文件。在理想情况下,数据流量分摊到各个 Parition 中,实现了负载均衡的效果。在分区日志文件中,你会发现很多类型的文件,比如: index、.timestamp、.log、.sna原创 2020-11-14 10:38:45 · 1719 阅读 · 0 评论 -
kafka-分区
分区副本机制Kafka在一定数量的服务器上对主题分区进行复制。当集群中的一个broker宕机后系统可以自动故障转移到其他可用的副本上,不会造成数据丢失–replication-factor 3 1leader+2follower将复制因子为1的未复制主题称为复制主题。主题的分区是复制的最小单元。在非故障情况下,Kafka中的每个分区都有一个Leader副本和零个或多个Follower副本。包括Leader副本在内的副本总数构成复制因子。所有读取和写入都由Leader副本负责。通常,分原创 2020-11-13 19:50:48 · 404 阅读 · 1 评论 -
kafka-再均衡
再均衡(Rebalance)本质上是一种协议,规定了一个消费组中所有消费者如何达成一致来分配订阅主题的每个分区。比如某个消费组有20个消费组,订阅了一个具有100个分区的主题。正常情况下,Kafka平均会为每个消费者分配5个分区。这个分配的过程就叫再均衡什么时候再均衡?再均衡的触发条件:组成员发生变更(新消费者加入消费组组、已有消费者主动离开或崩溃了)订阅主题数发生变更。如果正则表达式进行订阅,则新建匹配正则表达式的主题触发再均衡。订阅主题的分区数发生变更如何进行组内分区分配?原创 2020-11-13 14:29:54 · 571 阅读 · 0 评论 -
Rabbitmq- 延迟队列
延迟队列延迟消息是指的消息发送出去后并不想立即就被消费,而是需要等(指定的)一段时间后才触发消费。例如下面的业务场景:在支付宝上面买电影票,锁定了一个座位后系统默认会帮你保留15分钟时间,如果15分钟后还没付款那么不好意思系统会自动把座位释放掉。怎么实现类似的功能呢?可以用定时任务每分钟扫一次,发现有占座超过15分钟还没付款的就释放掉。但是这样做很低效,很多时候做的都是些无用功;可以用分布式锁、分布式缓存的被动过期时间,15分钟过期后锁也释放了,缓存key也不存在了;还可以用延迟队列原创 2020-11-13 09:03:57 · 154 阅读 · 0 评论 -
kafak-消费者
kafak-消费者消费者从订阅的主题消费消息,消费消息的偏移量保存在Kafka的名字是 __consumer_offsets 的主题中。消费者还可以将自己的偏移量存储到Zookeeper,需要设置offset.storage=zookeeper。推荐使用Kafka存储消费者的偏移量。因为Zookeeper不适合高并发多个从同一个主题消费的消费者可以加入到一个消费组中。消费组中的消费者共享group_id。configs.put(“group.id”, “xxx”);group_id一般设置为应原创 2020-11-13 08:55:57 · 178 阅读 · 0 评论 -
kafka-生产者消息发送流程
消息发送Producer创建时,会创建一个Sender线程并设置为守护线程。生产消息时,内部其实是异步流程;生产的消息先经过拦截器->序列化器->分区器,然后将消息缓存在缓冲区(该缓冲区也是在Producer创建时创建)。批次发送的条件为:缓冲区数据大小达到batch.size或者linger.ms达到上限,哪个先达到就算哪个。批次发送后,发往指定分区,然后落盘到broker;如果生产者配置了retrires参数大于0并且失败原因允许重试,那么客户端内部会对该消息进行重试。落盘到b原创 2020-11-12 10:02:50 · 845 阅读 · 0 评论 -
kafak-服务端参数配置
服务端参数配置$KAFKA_HOME/config/server.properties文件中的配置zookeeper.connect该参数用于配置Kafka要连接的Zookeeper/集群的地址。它的值是一个字符串,使用逗号分隔Zookeeper的多个地址。Zookeeper的单个地址是 host:port形式的,可以在最后添加Kafka在Zookeeper中的根节点路径zookeeper.connect=node2:2181,node3:2181,node4:2181/myKafkali原创 2020-11-11 19:55:23 · 550 阅读 · 0 评论 -
kafka-客户端发送消息
消息的发送与接收生产者主要的对象有: KafkaProducer , ProducerRecord 。其中 KafkaProducer 是用于发送消息的类, ProducerRecord 类用于封装Kafka的消息。KafkaProducer 的创建需要指定的参数和含义其他参数可以从 org.apache.kafka.clients.producer.ProducerConfig 中找到。我们后面的内容会介绍到。消费者生产消息后,需要broker端的确认,可以同步确认,也可以异步确认。同步原创 2020-11-11 17:29:14 · 662 阅读 · 0 评论