topic

1.面向消息的中间件(MOM) 1.什么是MOM 面向消息的中间件，Message Oriented Middleware，简称MOM，中文简称消息中间件，利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。 一个MOM系统，通常会包括客户端（Clients）、消息（Message）和 MOM，客户端是发送或者接受消息的应用程序，消息封装了要传递的内容，MOM可以存储和转发消息。如下图所示，系统A和系统B之间的消息传递，不是直接通信，而是通过中间件来间接的传递 2.MOM的好处 降低系统间通信复杂度：有了MOM，系统间的通信，不用考虑系统是什么语言开发的，也不用考虑复杂的网络编程，各个系统只需要关心自身和MOM之间如何进行消息的接受和发送即可，这些操作通过简单的API就可以完成。 提高了消息的灵活性：系统A通过MOM向系统B发送消息，消息可以存储在MOM中，并由MOM转发。即使是系统B不在线，MOM会持有这个消息，直到系统B连接并处理消息。这就是说，系统A发完消息后，就可以执行其它操作，而不必阻塞等待，尤其是对那些时间无关或者并行处理的操作，非常适用。 松散耦合：有了MOM的存在，对于系统B而言，只要发送的消息没有变化，就不必考虑系统Ａ的变化。A系统的代码改变，不会影响到B系统，反之亦然。 2.JMS基本概念 1.JMS是什么 Java消息服务

kafka运维常用查询操作总结以下几点： kafka生产和消费消息测试 发送：bin/kafka-console-producer.sh --broker-list 10.46.200.165:9092 --topic contentApprove 接收：bin/kafka-console-consumer.sh --bootstrap-server 10.46.200.165:9092 --topic contentApprove --from-beginning 创建topic命令参考 .bin/kafka-topics.sh --create --zookeeper localhost:2181 --partitions 6 --replication-factor 2 --topic test ### --partition：创建分区数，一般可以是服务器数量的双倍 ### --replication-factor：副本数默认为1，表示没有副本。保证冗余必须最少2 kafka修改副本数 bin/kafka-reassign-partitions.sh --zookeeper 10.124.77.41:2181 --reassignment-json-file test.json –execute 将分区数3修改为9 bin/kafka-topics.sh -

背景 前不久自建了大数据平台，由于时间问题，排期紧张，未能对平台进行压测。现在平台搭建完成，计划对平台组件逐一进行一次压测。 欢迎指正，不喜勿喷！ 压测目标 测试Kafka集群写入消息和消费消息的能力，根据测试结果评估当前Kafka集群模式的负载能力。 测试包括对Kafka写入消息和消费消息进行压力测试，根据不同量级的消息处理结果 测试方法 在服务器上使用kafka自带的测试脚本，模拟不同量级消息写入及读取请求，查看Kafka处理不同数量级的消息数时的处理能力，包括每秒生成消息数、吞吐量、消息延迟时间。 环境概况 系统环境 系统 版本 其他 centos 7.6 8C 32G kafka 版本2.11-2.4.0 5台 测试环境 测试数据量：1亿条。 topic batch-size ack message-size(bytes) compression-codec partition replication throughput test_producer 10000 1 512 none 4 3 30000 test_producer 20000 1 512 none 4 3 30000 test_producer 40000 1 512 none 4 3 30000 test_producer 60000 1 512 none 4 3 30000 test_producer

1.方法一.直接删除Topic a:如果Kafka服务器 delete.topic.enable=false 1) kafka-topics.sh --delete --zookeeper host:port --topic topicname 2) 删除kafka存储目录（server.properties文件log.dirs配置，默认为"/tmp/kafka-logs"）相关topic目录 3)删除zookeeper "/brokers/topics/"目录下相关topic节点 b:如果Kafka服务器 delete.topic.enable=true bin/kafka-topics.sh --zookeeper 192.168.4.71:2181,192.168.4.72:2181,192.168.4.73:2181delete test 2.方法二:设置 retention.ms 2.1 设置原数据最大的保留时间1m,5分钟后删除, bin/kafka-configs.sh --alter --zookeeper 192.168.4.71:2181,192.168.4.72:2181,192.168.4.73:2181 --entity-type topics --entity-name test --add-config retention.ms =1000 2.2

一、环境及准备 集群环境： 软件版本： 部署前操作： 关闭防火墙，关闭selinux(生产环境按需关闭或打开) 同步服务器时间，选择公网ntpd服务器或者自建ntpd服务器 [root@es1 ~]# crontab -l #为了方便直接使用公网服务器 #update time */5 * * * * /usr/bin/rdate -s time-b.nist.gov &>/dev/null 安装配置Java环境 参考此文章配置jvm部分https://www.cnblogs.com/panwenbin-logs/p/10369402.html 配置hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.16.150.134 rocketmq-nameserver1 172.16.150.134 rocketmq-master1 172.16.150.135 rocketmq-nameserver2 172.16.150.135 rocketmq-master2 172.16.150.136 rocketmq

🙂🙂🙂关注 微信公众号：【芋艿的后端小屋】 有福利： RocketMQ / MyCAT / Sharding-JDBC 所有 源码分析文章列表 RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址 您对于源码的疑问每条留言 都 将得到 认真 回复。 甚至不知道如何读源码也可以请教噢 。 新的 源码解析文章 实时 收到通知。 每周更新一篇左右 。 认真的 源码交流微信群。 1、概述 2、Producer 发送消息 DefaultMQProducer#send(Message) DefaultMQProducerImpl#sendDefaultImpl() DefaultMQProducerImpl#tryToFindTopicPublishInfo() MQFaultStrategy MQFaultStrategy LatencyFaultTolerance LatencyFaultToleranceImpl FaultItem DefaultMQProducerImpl#sendKernelImpl() 3、Broker 接收消息 SendMessageProcessor#sendMessage AbstractSendMessageProcessor#msgCheck DefaultMessageStore#putMessage 4

Flink Kafka Connector 是 Flink 内置的 Kafka 连接器，它包含了从 Kafka Topic 读入数据的 Flink Kafka Consumer 以及向 Kafka Topic 写出数据的 Flink Kafka Producer，除此之外 Flink Kafa Connector 基于 Flink Checkpoint 机制提供了完善的容错能力。本文从 Flink Kafka Connector 的基本使用到 Kafka 在 Flink 中端到端的容错原理展开讨论。 1.Flink Kafka 的使用 在 Flink 中使用 Kafka Connector 时需要依赖 Kafka 的版本，Flink 针对不同的 Kafka 版本提供了对应的 Connector 实现。 1.1 版本依赖 既然 Flink 对不同版本的 Kafka 有不同实现，在使用时需要注意区分，根据使用环境引入正确的依赖关系。 <dependency> <groupId>org.apache.flink</groupId> <artifactId>${flink_kafka_connector_version}</artifactId> <version>${flink_version}</version> </dependency> 在上面的依赖配置中 ${flink

一、NameSever介绍 1.1 NameSever是什么 NameServer 的主要功能是为整个 MQ 集群提供服务协调与治理，具体就是记录维护 Topic 、 Broker 的信息，及监控 Broker 的运行状态，为 client 提供路由能力。 NameServer 之间没有信息同步操作，主要通过 Broker 轮询修改信息。 * Name Server 是一个无状态节点，可集群部署，节点之间无任何信息同步; * Broker 分为 Master 与 Slave，它们是一对多的关系，一个 Master 可以对应多个 Slave。 每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server; * Producer与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Master Broker 发送心跳。Producer 完全无状态，可集群部署; * Consumer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master

目录 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 如何解决ResourceManager单点问题，实现高可用？ 6.2.3 Kafka 术语介绍 问题 Kafka与Zookeeper Broker注册管理 Topic注册管理 生产者负载均衡 消费者负载均衡 消费分区与消费者关系 消息消费进度Offset记录 消费者注册 负载均衡 1）Range策略 2）RoundRobin策略 资料 6.3 Zookeeper在阿里巴巴的实践与应用 6.3.2 案例二 RPC服务框架：Dubbo 服务提供者 服务消费者 监控中心 6.3.3 案例三 基于MySQL Binlog的增量订阅和消费组件：Canal Canal基本工作原理 Canal Server主备切换设计 Canal Client的HA设计 6.3.4 案例四 分布式数据库同步系统：Otter 分布式SEDA模型 数据模型 任务处理流程(多阶段任务协调处理) 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 YARN是Hadoop为了提高计算节点的扩展性，同时为了支持多计算模型和提供资源的细粒度调度而引入的全新一代分布式协调框架。 核心为ResourceManager，资源管理中心，负责集群中所有资源的统一管理和分配。 （可理解为YARN的大脑

Jms规范里的两种message传输方式Topic和Queue，两者的对比如下表()： 　 Topic Queue 概要 Publish Subscribe messaging 发布订阅消息 Point-to-Point 点对点 有无状态 topic数据默认不落地，是无状态的。 　　Queue数据默认会在mq服务器上以文件形式保存，比如Active MQ一般保存在$AMQ_HOME/data/kr-store/data下面。也可以配置成DB存储。 完整性保障 并不保证publisher发布的每条数据，Subscriber都能接受到。 Queue保证每条数据都能被receiver接收。 消息是否会丢失 一般来说publisher发布消息到某一个topic时，只有正在监听该topic地址的sub能够接收到消息；如果没有sub在监听，该topic就丢失了。 Sender发送消息到目标Queue，receiver可以异步接收这个Queue上的消息。Queue上的消息如果暂时没有receiver来取，也不会丢失。 消息发布接收策略 一对多的消息发布接收策略，监听同一个topic地址的多个sub都能收到publisher发送的消息。Sub接收完通知mq服务器 一对一的消息发布接收策略，一个sender发送的消息，只能有一个receiver接收。receiver接收完后，通知mq服务器已接收