topic

Passing ROS arguments to nodes via the command-line 通过命令行将ROS参数传递给节点 All ROS nodes take a set of arguments that allow various properties to be reconfigured. Examples include configuring the name/namespace of the node, topic/service names used, and parameters on the node. 所有ROS节点都采用一组参数， 可以 重新配置各种属性。示例包括配置节点的名称/命名空间，使用的主题/服务名称以及节点上的参数。 Note: all features on this page are only available as of the ROS 2 Bouncy release. 注意：此 网页 上的所有功能仅在ROS 2 Bouncy 及之后发行版本 中提供 ，适用于Bouncy、Crystal和Dashing。 Name remapping 名称重新映射 <old name>:=<new name> . The name/namespace of the node itself can be remapped __node:=

分布式消息队列 nsq ，简单易用，去中心化的设计使 nsq 更健壮， nsq 充分利用了 go 语言的 goroutine 和 channel 来实现的消息处理，代码量也不大，读不了多久就没了。后期的文章我会把 nsq 的源码分析给大家看。 主要的分析路线如下 分析 nsq 的整体框架结构，分析如何做到的无中心化分布式拓扑结构，如何处理的单点故障。 分析 nsq 是如何保证消息的可靠性，如何保证消息的处理，对于消息的持久化是如何处理和扩展的。 分析 nsq 是如何做的消息的负载处理，即如何把合理的、不超过客户端消费能力的情况下，把消息分发到不同的客户端。 分析 nsq 提供的一些辅助组件。 这篇帖子，介绍 nsq 的主体结构，以及他是如何做到去中心化的分布式拓扑结构，如何处理的单点故障。 几个组件是需要先大概说一下 nsqd 消息队列的主体，对消息的接收，处理和把消息分发到客户端。 nsqlookupd nsq 拓扑结构信息的管理者，有了他才能组成一个简单易用的无中心化的分布式拓扑网络结构。 go-nsq nsq 官方的go语言客户端，基本上市面上的主流编程语言都有相应的客户端 在这里 还有可视化的组件 nsqadmin 和一些工具像 nsq_to_file 、 nsq_stat 、等等，这些在后期的帖子里会介绍 nsqd 是独立运行的，我们可以直接使用部署几个 nsqd

/*--> */ /*--> */ /*--> */ /*--> */ 启动 zookeeper 1、./zkServer restart 启动kafaka 2、./kafka-server-start /usr/local/etc/kafka/server.properties 创建topic 3、./kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test 查询topic 列表 4、 ./kafka-topics --list --zookeeper localhost:2181 Zookeeper 启动ZK服务 ./zkServer start 查看ZK服务状态 bin/zkServer status 停止ZK服务 bin/zkServer stop 重启ZK服务 bin/zkServer restart 连接服务器 bin/zkCli -server 127.0.0.1:2181 查看根目录 ls / 创建 testnode节点 create /zk/testnode "test" 查看节点内容 get /zk/testnode 设置节点内容 set /zk/testnode test 删除节点 delete /zk/testnode

1、基本概念 需要了解producer,consumer,groupId,broker,topic,partition,segment的概念，如下图。 2、版本名 kafka_2.10-0.8.2.jar，2.10是指Scala版本，0.8.2是指kafka版本。 3、核心功能 Producer API允许程序发布数据流到一个到多个Kafka topic。 Consumer API允许程序订阅一个到多个topic，并且进行消费。 Streams API允许程序作为一个数据流处理，将一个或多个topic中输入的数据进行消费，并生产数据流到一个或多个topics中。 Connector API，可以通过Connector管理Kafka和另一个系统之间的数据复制，比如去捕获关系型数据库中的任意改变到一个表中。 4、topic介绍 topic（不同的业务数据，分流到不同的topic进行处理） kafka对与zookeeper是强依赖的，是以zookeeper作为基础的，即使不做集群，也需要zk的支持。以下是kafka中必须要填写的配置文件，id为在zk中注册的brokerid，后者为要注册到的zookeeper的host和port。 broker.id=0 zookeeper.connect=localhost:2181 zk说白了，就是一个节点服务系统，至于用这个节点做什么，做单活

下载带有管理界面的RabbitMQ Docker镜像 docker pull rabbitmq:3.7.7-management 然后创建并运行RabbitMQ容器 docker run -d --name rabbitmq3.7.7 -p 5672:5672 -p 15672:15672 -v `pwd`/data:/var/lib/rabbitmq --hostname myRabbit -e RABBITMQ_DEFAULT_VHOST=my_vhost -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin rabbitmq:3.7.7-management docker run -d --hostname rabbitmqhost --name rabbitmq3.6 --restart always -p 5672:5672 -p 15672:15672 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin rabbitmq:3.6.15-management -d：后台运行 --hostname：设置容器的主机名 --name：容器命名 --restart always：开机启动 -p：端口号映射，前面是宿主机端口，后面是容器端口

来自CAP原作者yang-xiaodong的原理图： 本文撰写者：cmliu,部分内容引用自官方文档,部分内容待更新# .NetCore CAP # 1,简介 CAP 是一个遵循 .NET Standard 标准库的C#库，用来处理分布式事务以及提供EventBus的功能，她具有轻量级，高性能，易使用等特点。 目前 CAP 使用的是 .NET Standard 1.6 的标准进行开发，目前最新预览版本已经支持 .NET Standard 2.0 ## CAP 的应用场景主要有以下两个： ### 分布式事务中的最终一致性（异步确保）的方案。 >分布式事务是在分布式系统中不可避免的一个硬性需求，CAP 没有采用两阶段提交（2PC）这种事务机制 >而是采用的 本地消息表+MQ 这种经典的实现方式，这种方式又叫做 异步确保。 ### 具有高可用性的 EventBus(事件总线)。 >CAP 实现了 EventBus 中的发布/订阅，它具有 EventBus 的所有功能。 >也就是说你可以像使用 EventBus 一样来使用 CAP，另外 CAP 的 EventBus 是具有高可用性的， CAP 借助于本地消息表来对 EventBus 中的消息进行了持久化 >这样可以保证 EventBus 发出的消息是可靠的，当消息队列出现宕机或者连接失败的情况时，消息也不会丢失 #####

Topic交换器，即主题模式，进行规则匹配。 一、Provider 配置文件 1 spring.application.name=provider 2 spring.rabbitmq.host=192.168.50.30 3 spring.rabbitmq.port=5672 4 spring.rabbitmq.username=rabbit 5 spring.rabbitmq.password=rabbit 6 #设置交换器名称 7 mq.config.exchange=log.topic 代码 1 public class UserSender { 2 @Autowired 3 private AmqpTemplate amqpTemplate; 4 5 @Value("${mq.config.exchange}") 6 private String exchange; 7 8 public void send(String msg) { 9 //交换器、路由键、消息 10 this.amqpTemplate.convertAndSend(this.exchange, "user.log.debug", msg); 11 this.amqpTemplate.convertAndSend(this.exchange, "user.log.info", msg); 12 } 13

关于 Kafka Kafka 是最初由 Linkedin 公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于 zookeeper 协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如 基于 hadoop 的批处理系统、低延迟的实时系统、storm/Spark 流式处理引擎，web/nginx 日志、访问日志，消息服务等等，用scala语言编写，Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源 项目。（ 以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间的访问性能。） Kafka 的特点 ①高吞吐量，低延迟： Kafka 每秒可以处理几十万条消息 延迟最多只有几毫秒 ②可扩展性： Kafka 集群支持热扩展（ 热扩展指不重启整个集群的前提下，向集群中添加新的节点 ） ③持久性，可靠性：消息被持久化到本地磁盘并且支持数据备份防止丢失 ④容错性：允许集群中的节点失败 ⑤高并发：支持数千个客户端同时读写 Kafka 使用场景 ①日志收集：一个公司使用 Kafka 收集各种服务的 log ②消息系统：解耦和生产者和消费者、缓存消息等。（解耦：在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的

发送消息和拉取消息 package com.shtel.paas.service.mq ; import java.io.UnsupportedEncodingException; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import com.ctg.mq.api.exception.MQException; import com.ctg.mq.api.exception.MQProducerException; import com.shtel.paas.sdk.core.PaasBaseRequest; import com.shtel.paas.sdk.core.PaasBaseResponse; import com

KafkaProducer在调用send方法发送消息至broker的过程中，首先是经过拦截器Inteceptors处理，然后是经过序列化Serializer处理，之后就到了Partitions阶段，即分区分配计算阶段。在某些应用场景下，业务逻辑需要控制每条消息落到合适的分区中，有些情形下则只要根据默认的分配规则即可。在KafkaProducer计算分配时，首先根据的是ProducerRecord中的partition字段指定的序号计算分区。读者有可能刚睡醒，看到这个ProducerRecord似曾相识，没有关系，先看段Kafka生产者的示例片段： Producer<String,String> producer = new KafkaProducer<String,String>(properties); String message = "kafka producer demo"; ProducerRecord<String, String> producerRecord = new ProducerRecord<String, String>(topic,message); try { producer.send(producerRecord).get(); } catch (InterruptedException e) { e.printStackTrace(); }