topic

前言 在日常的工作与学习中，我们经常会使用思维导图这个工具，来把抽象而又无形的思考转换成有形并且具体的图像，是理清思路，梳理逻辑的一大神器。 准确的说，思维导图并不是一个具体的工具，而是一种方法。是道而不是术。实际落地时，我们通常还需要借助外部的工具。从最原始的纸和笔，到各种软件，可以说是应用尽有。目前我在使用的是 xmind 这款软件，下面就会以 xmind 为媒介间接的通过 Java 代码画思维导图。 放码过来 通过目录生成思维导图 我在看书的时候有一个习惯，先通过思维导图画出一本书的大纲，然后通过这个大纲来分主次的去阅读。可能有些同学感到疑惑，还没读过书，如何了解大纲呢？其实一本书的目录就是这本书最好的大纲。 本文通过把一个目录生成思维导图的例子来学习 xmind 基本的 api 使用。当然如果想系统学习的同学，可以参考文末给出的官方 api 链接。下图就是我们最终要生成的结果。 引入依赖 xmind 最开始是在 eclipse 上进行定制开发而来（对，这个 eclipse 就是你在遇到 idea 后，喜新厌旧抛弃的那个编程软件），所以天生就对 Java 有良好的支持。这个 地址 就是 xmind 在 github 上的仓库。对 xmind 的操作的 api 全在 org.xmind.core 包下，按官方提示把代码拉下来在本地打个包，再引入就 ok 了。但是呢

前言 在日常的工作与学习中，我们经常会使用思维导图这个工具，来把抽象而又无形的思考转换成有形并且具体的图像，是理清思路，梳理逻辑的一大神器。 准确的说，思维导图并不是一个具体的工具，而是一种方法。是道而不是术。实际落地时，我们通常还需要借助外部的工具。从最原始的纸和笔，到各种软件，可以说是应用尽有。目前我在使用的是 xmind 这款软件，下面就会以 xmind 为媒介间接的通过 Java 代码画思维导图。 放码过来 通过目录生成思维导图 我在看书的时候有一个习惯，先通过思维导图画出一本书的大纲，然后通过这个大纲来分主次的去阅读。可能有些同学感到疑惑，还没读过书，如何了解大纲呢？其实一本书的目录就是这本书最好的大纲。 本文通过把一个目录生成思维导图的例子来学习 xmind 基本的 api 使用。当然如果想系统学习的同学，可以参考文末给出的官方 api 链接。下图就是我们最终要生成的结果。 引入依赖 xmind 最开始是在 eclipse 上进行定制开发而来（对，这个 eclipse 就是你在遇到 idea 后，喜新厌旧抛弃的那个编程软件），所以天生就对 Java 有良好的支持。这个 地址 就是 xmind 在 github 上的仓库。对 xmind 的操作的 api 全在 org.xmind.core 包下，按官方提示把代码拉下来在本地打个包，再引入就 ok 了。但是呢

zookeeper+KAFKA 集群搭建 ZooKeeper是一个分布式的1600174884，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、集群管理等。因为Kafka集群是把状态信息保存在Zookeeper中的，并且Kafka的动态扩容是通过Zookeeper来实现的，所以需要优先搭建Zookeerper集群，建立分布式状态管理。开始准备环境，搭建集群： zookeeper是基于Java环境开发的所以需要先安装Java 然后这里使用的zookeeper安装包版本为zookeeper-3.4.14，Kafka的安装包版本为kafka_2.11-2.2.0。 AMQP协议：Advanced Message Queuing Protocol （高级消息队列协议）是一个标准开放的应用层的消息中间件协议。AMQP定义了通过网络发送的字节流的数据格式。因此兼容性非常好，任何实现AMQP协议的程序都可以和与AMQP协议兼容的其他程序交互，可以很容易做到跨语言，跨平台。 server1：192.168.42.128 server2：192.168.42.129 server3：192.168.42.130

Kafka概述 是基于点对点模式和发布订阅模式的分布式消息队列系统 为什么要用kafka,为什么要用消息队列 1）解耦： 2）冗余： 3）扩展性： 4）灵活性 & 峰值处理能力： 5）可恢复性： 6）顺序保证： 7）缓冲： 8）异步通信： kafka构架 1）Producer ：消息生产者，就是向kafka broker发消息的客户端； 2）Consumer ：消息消费者，向kafka broker取消息的客户端； 3）Topic ：可以理解为一个队列（就是同一个业务的数据放在一个topic下）； 4） Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partion只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic； 5）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic； 6）Partition

三、控制台的使用 1. 切换语言为简体中文 上图首页即为“驾驶舱”标签下的图标，中共有4个图： - Broker TOP 10 ：是指前10个Brokder处理消息的数量。比如从上图可以看出来，我只有一个Brokder，并且此Brokder处理了1000条消息. - Broker 5min trend: 此图标可以筛选出某个Topic下5分钟的消息数量，可以切换时间，所以就相当于可以查看某个Topic下的消息数量趋势。 - 剩余2个图没搞懂含义。 2. 切换namesrvAdd 3. 集群 4. 主题 1.状态 2. 发送消息 5.消息 可以参考 “消息查询” 这篇文章。 ———————————————— 版权声明：本文为CSDN博主「GNG」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/so_geili/article/details/90142461 来源： https://www.cnblogs.com/guixie/p/11872009.html

上一篇文章我们主要介绍了什么是 Kafka，Kafka 的基本概念是什么，Kafka 单机和集群版的搭建，以及对基本的配置文件进行了大致的介绍，还对 Kafka 的几个主要角色进行了描述，我们知道，不管是把 Kafka 用作消息队列、消息总线还是数据存储平台来使用，最终是绕不过 消息 这个词的，这也是 Kafka 最最核心的内容，Kafka 的消息从哪里来？到哪里去？都干什么了？别着急，一步一步来，先说说 Kafka 的消息从哪来。 生产者概述 在 Kafka 中，我们把产生消息的那一方称为 生产者 ，比如我们经常回去淘宝购物，你打开淘宝的那一刻，你的登陆信息，登陆次数都会作为消息传输到 Kafka 后台，当你浏览购物的时候，你的浏览信息，你的搜索指数，你的购物爱好都会作为一个个消息传递给 Kafka 后台，然后淘宝会根据你的爱好做智能推荐，致使你的钱包从来都禁不住诱惑，那么这些生产者产生的 消息 是怎么传到 Kafka 应用程序的呢？发送过程是怎么样的呢？ 尽管消息的产生非常简单，但是消息的发送过程还是比较复杂的，如图 我们从创建一个 ProducerRecord 对象开始，ProducerRecord 是 Kafka 中的一个核心类，它代表了一组 Kafka 需要发送的 key/value 键值对，它由记录要发送到的主题名称（Topic Name），可选的分区号

使用pykafka来进行消息生产 1 #coding:utf8 2 from pykafka import KafkaClient 3 import json 4 5 client = KafkaClient(hosts='192.168.1.1:9092') 6 7 topic = client.topics['perfin'] 8 producer = topic.get_producer(use_rdkafka=False) 9 producer.start() 10 11 msg_dict = { 12 "sleep_time": 10, 13 "db_config" : { 14 "database" : "test", 15 "host" : "192.168.137.12", 16 "user" : "root", 17 "password" : "root" 18 }, 19 "table" : "msg", 20 "msg" : "Hello World" 21 } 22 msg = json.dumps(msg_dict) 23 producer.produce(msg) 24 producer.stop() 来源： https://www.cnblogs.com/yeyong/p/11854944.html

简介 Kafka是基于发布订阅的消息系统。最初起源于LinkedIn，于2011年成为开源Apache项目，然后于2012年成为Apache顶级项目。Kafka用Scala和Java编写，因其分布式可扩展架构及可持久化、高吞吐率特征而被广泛使用。 消息队列 通常在项目中，我们会因为如下需求而引入消息队列模块： 1.解耦：消息系统相当于在处理过程中间插入了一个隐含的、基于数据的接口层。无需预先定义不同的接口地址和请求应答规范，这允许数据上下游独立决定双方的处理过程，只需要约定数据格式即可任意扩展服务类型和业务需求。 2.缓冲：消息系统作为一个缓冲池，应对常见的访问量不均衡情形。比如特殊节假日的流量剧增和每日不同时段的访问量差异。以及处理不同数据类型所需的不同实时性。使整个业务处理架构以较低成本获得一定灵活性。 3. 异步：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 Kafka的特点 作为一种分布式的，基于发布/订阅的消息系统。Kafka的主要设计目标如下： 1.以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。 2.高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。 3

背景 第三方介入开放平台后，开放平台需要将设备状态、属性等值发给第三方，目前使用的方案是HTTP方式推送，但是由于数据量大，使用HTTP推送有很大的局限性； 经过评估，使用rocketmq可很好的解决该问题； 解决方案 开放平台将设备状态、属性值等资源发送到MQ，第三方消费对应的topic即可 安全方案 利用rocketmq的acl功能，开放平台使用admin权限，根据appid将设备信息发送到对应的topic，然后再开放平台上开放指定的topic的订阅权限 技术评估 官网地址： http://rocketmq.apache.org/ 下载安装包及源码地址： https://github.com/apache/rocketmq ACL权限控制： https://github.com/apache/rocketmq/blob/master/docs/cn/acl/user_guide.md rocketmq console支持acl issue： https://github.com/apache/rocketmq-externals/pull/244 该功能未上线，master代码也无 多topic时，rocketmq性能影响： https://www.cnblogs.com/felixzh/p/6198174.html ----rocketmq支持万级别的topic

上一篇文章 讲了如何用spring cloud stream集成kafka，并且跑起来一个demo，如果这一次宣传spring cloud stream的文章，其实到这里就可以啦。但实际上，工程永远不是简单的技术会还是不会的问题，在实际的开发中，我们会遇到很多的细节问题（简称坑），这篇文章，会把其中一些很小的点说一下，算是用实例告诉大家，工程的复杂性，往往体现在实际的繁琐步骤中。 1、group的配置 在发送消息的配置里面，group是不用配置的 关于这一点的证明，可以在源代码的注释里面看到 org.springframework.cloud.stream.config.BindingProperties 2、修改topic的partitions 配置文件如下 bindings: output: binder: kafka destination: wph-d-2 #消息发往的目的地，对应topic content-type: text/plain #消息的格式 producer: partitionCount: 7 partitionCount是用来设置partition的数量，默认是1，如果这个topic已经建了，修改partitionCount无效，会提示错误 Caused by: org.springframework.cloud.stream.provisioning