rocketmq

RocketMQ 的主和从一直在使用 nio 进行数据同步: master master 监听端口 org.apache.rocketmq.store.ha.HAService.AcceptSocketService#beginAccept master 建立连接 org.apache.rocketmq.store.ha.HAService.AcceptSocketService#run master 读取 slave 上报的 maxOffset org.apache.rocketmq.store.ha.HAConnection.ReadSocketService#run master 传输数据给 slave org.apache.rocketmq.store.ha.HAConnection.WriteSocketService#run slave slave 连接 master org.apache.rocketmq.store.ha.HAService.HAClient#connectMaster slave 报告 maxOffset 给 master org.apache.rocketmq.store.ha.HAService.HAClient#run slave 接收 master 传输来的数据 org.apache.rocketmq.store.ha.HAService

一、windows下配置jdk及Rocketmq环境变量： vim /root/.bashrc #在该文件添加一下内容 # Set RocketMQ Environment ROCKETMQ_HOME=/home/MyRocketMQ-bin # 此处为上述步骤中的maven编译后文件目录代码 ROCKETMQ_CLASSPATH=$ROCKETMQ_HOME/lib # 此处为rocketmq运行所依赖的jar的classpath ROCKETMQ_PATH=$ROCKETMQ_HOME/bin # 此处为rocketmq运行bin目录，加入到可执行命令 NAMESRV_ADDR=127.0.0.1:9876 # Set Java Environment JAVA_HOME=/usr/java/jdk1.7.0_79 JRE_HOME=/usr/java/jdk1.7.0_79/jre PATH=.:$PATH:$JAVA_HOME/bin:$JRE_HOME/bin:$ROCKETMQ_PATH # 此处将ROCKETMQ_PATH CLASSPATH=.:$CLASSPATH:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib:$ROCKETMQ_PATH 根据实际情况

1，RocketMq四大核心组件： 在 RocketMQ里，有以下几个核心的模块： Producer ， Consumer ， Broker ， NameSrv 。他们之间的关系如下 先简单了解一下各个模块的功能，下面会有章节详细介绍各个模块的功能。 Producer和Consumer很好理解，顾名思义就是生产者和消费者，生产者负责生产消息，消费者负责消费消息，这2块的逻辑都是由业务使用者定义的。 Broker是RocketMQ的核心，Broker实现了 消息的存储、拉取 等功能。 Broker通常以集群方式启动，并可配置主从，每个Broker上提供对指定topic的服务。理解了Broker的原理，以及和其他服务交互的方式就基本弄懂了整个消息中间件的原理。 NameSrv是一个无状态的名称服务，可以集群部署。所有Broker启动的时候会向NameSrv注册自己的信息。Producer会根据目标topic从NameSrv获取到达指定Broker的路由信息，Consumer同理。 对于 Producer端RocketMQ采用了轮询的方式保证了负载均衡，Consumer端通常采用cluster集群方式消费消息，我们可以自己定义消息在消息端的分配方式。另外，MQ还提供了顺序消息的特性，简单了解一下MQ提供的特性即可，具体实现后面章节会进行阐述。 2，RocketMQ包结构详析：

导入包： https://github.com/gaufung/rocketmq-client-dotnet/tree/master using org.apache.rocketmq.client.consumer.listener; using org.apache.rocketmq.client.producer; using System; using System.Text; using java.util; using System.Windows.Forms; using org.apache.rocketmq.client.consumer; using org.apache.rocketmq.common.consumer; using System.Threading; using System.Collections.Generic; namespace wf_RMQ3 { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { try { DefaultMQProducer p = new DefaultMQProducer("PG01"); p

前言 在系统变的复杂后，分布式、微服务等架构技术，就要考虑到应用在系统中了。尤其数据量大了后，就需要 对数据库进行拆分。 如：注册的用户数据，量大了后，就需要考虑分库分表 一旦数据库进行了分拆，那就出现很多头疼的问题， 其中之一就是事务问题 。那我们就来看看问题是怎么出现的？ 场景 先来上个图 进行数据拆分后，就类似上面的架构。 上图中我们就拿用户的数据进行举例， 用户量一旦几千万时 ，就需要进行分库分表；上图就分了3个库，每个库都保证了高可用。 这样的架构设计，会遇到事务问题，我们来看看具体的业务场景：用户A转账100元给用户B，这个业务比较简单，我们来分析一下里面具体的步骤： 1、用户A的账户先扣除100元 2、再把用户B的账户加100元 逻辑很简单，上伪代码 代码也是比较清晰的，感觉没有什么问题， 那我们来分析一下问题在哪？ 问题 我们看到在转账业务中， 有两步，一个是操作用户A扣钱，一个是操作用户B加钱 如果在同一个数据库中进行，可以保证这两步操作，要么同时成功，要么同时不成功。这样就保证了转账的数据一致性。 但是如果用户A的数据在集群A中，用户B在集群B中呢？ 因为他们不在同一个事务中；如用户A扣款成功，但用户B加钱失败了；那就坑了，数据不完整了。 类似这种问题在微服务架构会更多，因为各个服务都是独立的模块，都是远程调用，都没法在同一个事务中，都会遇到事务问题。

本文未完成，有空再补充，不小心发布了，抱歉 Rocket版本：4.3.0 这几天在整RocketMQ，可谓是困难重重，其中关于控制台的命令，网上的都是一半一半的， 所以我打算直接用整一个完整的官方的命令的翻译以及使用详解。 其中很多命令我都没用过，反正我尽量将我用过的，知道的命令加以解释吧。 其他没用过的就原文代替，所以本文会随着我的使用而更新。 题外话： 关于broker.conf的问题 初始的broker.conf文件一开始只有 开头注释和几个配置项 ，其他配置项并没有在文件里显示，而且我在里面改了deleteWhen这个配置项的时候。 发现并没有生效，也是奇怪。 然后当我偶然用了控制台命令 updateBrokerConf 修改deleteWhen的时候，再去打开broker.conf文件，发现文件内容变成了全部的配置项，那个 开头的注释都不见了，这奇怪吧，如果有哪位仁兄知道的并且想告诉我怎么回事的话，欢迎私信。 命令我就参考网上他们的表格形式吧，好看一点，或者说如果网上只写了10个命令，那我就把剩下的都补上，所以相当于完善，不存在什么抄不抄袭。 原版命令 The most commonly used mqadmin commands are: updateTopic Update or create topic deleteTopic Delete topic from

转自 ： https://my.oschina.net/u/4232045/blog/3117247 在高并发业务场景下，消息队列在流量削峰、解耦上有不可替代的作用。当前使用较多的消息队列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、Pulsar 等。 消息队列这么多，到底该选择哪款消息队列呢？ 选择消息队列的基本标准 虽然这些消息队列在功能和特性方面各有优劣，但我们在选择的时候要有一个基本标准。 首先，必须是开源的产品。开源意味着，如果有一天你使用的消息队列遇到了一个影响你系统业务的 Bug，至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统的问题，而不是等待开发者发布的下一个版本来解决。 其次，这个产品必须是近年来比较流行并且有一定社区活跃度的产品。流行的好处是，只要使用场景不太冷门，遇到 Bug 的概率会非常低，因为大部分遇到的 Bug，其他人早就遇到并且修复了。在使用过程中遇到的一些问题，也比较容易在网上搜索到类似的问题，然后很快的找到解决方案。还有一个优势就是，流行的产品与周边生态系统会有一个比较好的集成和兼容。 最后，作为一款及格的消息队列，必须具备的几个特性包括： 消息的可靠传递：确保不丢消息； Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息； 性能：具备足够好的性能

一.预备环境 1.系统 Windows 2. 环境 JDK1.8、Maven、Git 二. RocketMQ部署 1.下载 1.1地址：http://rocketmq.apache.org/release_notes/release-notes-4.2.0/ 1.2选择‘Binary’进行下载 1.3解压已下载工程 2. 配置 2.1 系统环境变量配置 变量名：ROCKETMQ_HOME 变量值：MQ解压路径\MQ文件夹名 2.2重启服务器 3. 启动 3.1 启动NAMESERVER Cmd命令框执行进入至‘MQ文件夹\bin’下，然后执行‘start mqnamesrv.cmd’，启动NAMESERVER。成功后会弹出提示框，此框勿关闭。 3.2 启动BROKER cmd命令框执行进入至‘MQ文件夹\bin’下，然后执行‘start mqbroker.cmd -n 127.0.0.1:9876 autoCreateTopicEnable=true’，启动BROKER。成功后会弹出提示框，此框勿关闭。 假如弹出提示框提示‘错误: 找不到或无法加载主类 xxxxxx’。打开runbroker.cmd，然后将‘%CLASSPATH%’加上英文双引号。保存并重新执行start语句。 三. RocketMQ插件部署 1. 下载 地址：https://github.com/apache

RocketMQ作为消息中间件，在系统异步化架构中，应用非常广泛。但是我们在享用RocketMQ的同时，也不能百分百完全信赖它。一旦RocketMQ崩溃了，给我们业务带来的也将是毁灭性打击。 因此，我们在使用RocketMQ的时候，一定要做好补偿工作。 下面提供一个RocketMQ的补偿架构图，已在实际工作中应用： 总结：在系统设计中，针对各个可能存在安全隐患的点，一定要提前做好防御措施。切不可存在侥幸心理。 来源： https://www.cnblogs.com/dushenzi/p/11678744.html

作者 | 李响 阿里云资深技术专家 关注“阿里巴巴云原生”公众号，回复关键词“容器”，可下载云栖大会容器专场全部 PPT 摘要： 利用云原生技术构建应用简便快捷，部署应用轻松自如，运行应用按需伸缩。如今，云原生已经成为下一代技术发展的趋势。在 2019 杭州云栖大会开发者峰会上，阿里巴巴资深技术专家李响就为大家分享了阿里巴巴的云原生技术与开发者的那些故事。 为什么选择云原生？ 云原生的本质目标就是充分释放云计算带来的红利，阿里巴巴希望开发者能够使用云上极致弹性的资源交付能力，也能够使用云上极为便捷的产品和服务。阿里巴巴实践云原生也已经走过了几年时间，并在去年启动了全站上云。阿里巴巴希望业务可以更好地拥抱云，更加全面地推进云原生。 云原生既带来了技术红利，同时也带来了业务红利。 在资源效率方面，云原生为资源效率带来了极大提升。使用容器、调度等技术不仅提高了单机维度的部署密度和资源效率，还提高了集群维度资源配置的合理性和使用率。除此之外，将业务搬到云上，还可以使用云的极致弹性的资源交付能力，既能够应对流量洪峰，也降低了资源的使用成本。 在开发效率方面，使用 Kubernetes 这样的平台增强了运维自动化的能力，也增强了对应用和资源进行编排的能力，并降低了运维负担，提高了开发效率。同时，阿里云也在推动 CI/CD 系统的演进，希望加速应用从完成到上线的过程