RocketMQ集群高可用之双主双从 2020-01-07 机器列表 server1 ssh root@192.168.159.133 部署nameServer Broker-a server2 ssh root@192.168.159.130 部署nameServer Broker-a-s server3 ssh root@192.168.159.131 Broker-b server4 ssh root@192.168.159.132 Broker-b-s 修改 RocketMQ 启动内存配置 4 个机器都要修改, 其中 runbroker.sh 修改 4 个,runserver.sh 修改 2 个 # 解决NameServer内存不满足4G的报错:修改2个 vim /test/rocketmq/distribution/target/apache-rocketmq/bin/runserver.sh #修改JAVA_OPT JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn256m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m" #....
分布式事务消息 2020-01-07 分布式事务 单体应用被拆为分布式应用,一个借口需要调用多个服务,且操作不同的数据库,数据一致性难以保障。 常见解决方案 2PC : 两阶段提交, 基于 XA 协议 TCC : Try、Confirm、Cancel 框架 GTS -> 开源 Fescar 链接 LCN 链接 RocketMQ4.X 分布式事务消息架构 RocketMQ 事务消息 RocketMQ 提供分布事务功能,通过 RocketMQ 事务消息能达到分布式事务的最终一致。 半消息 Half Message 暂不能投递的消息(暂不能消费),Producer 已经将消息成功发送到了 Broker 端,但是Broker 端未收到 Produce 对该消息的二次确认,此时该消息被标记成“暂不能投递”状态,处于该种状态下的消息即半消息。 消息回查 由于网络闪断、生产者应用重启等原因,导致某条事务消息的二次确认丢失,消息队列 RocketMQ 服务端通过扫描发现某条消息长期处于“半消息”时,需要主动向消息生产者询问该消息的最终状态(Commit 或是 Rollback),该过程即消息回查。 整体交互流程 ....
Offset、CommitLog、ZeroCopy 2020-01-07 消息偏移量 Offset 一个 Topic 下面有多个 message queue,message queue 是无限长的数组,一条消息进来下标就会涨 1,下标就是 offset(索引的位置),消息在某个 MessageQueue 里的位置,通过 offset 的值可以定位到这条消息,或者指示 Consumer 从这条消息开始向后处理。 message queue 中的 maxOffset 表示消息的最大 offset, maxOffset 并不是最新的那条消息的 offset,而是最新消息的 offset+1,minOffset 则是现存在的最小 offset。 fileReserveTime=48 默认消息存储 48 小时后,消息会被物理地从磁盘删除,message queue 的 min offset 也就对应增长。(1-5000,消息删除之后,1001-5000)所以比 minOffset 还要小的那些消息已经不在 broker 上了,就无法被消费。 Offset 的存储类型 本地文件类型:DefaultMQPushConsumer 的 BROADCASTING 模式,各....
RocketMQ消费者核心概念 2020-01-07 常见核心配置 consumeFromWhere 配置 参考 CONSUME_FROM_FIRST_OFFSET: 初次从消息队列头部开始消费,即历史消息(还储存在broker的)全部消费一遍,后续再启动接着上次消费的进度开始消费 CONSUME_FROM_LAST_OFFSET: 默认策略,初次从该队列最尾开始消费,即跳过历史消息,后续再启动接着上次消费的进度开始消费 CONSUME_FROM_TIMESTAMP : 从某个时间点开始消费,默认是半个小时以前,后续再启动接着上次消费的进度开始消费 allocateMessageQueueStrategy:负载均衡策略算法,即消费者分配到 queue 的算法,默认值是 AllocateMessageQueueAveragely 即取模平均分配。 offsetStore:消息消费进度存储器 offsetStore 有两个策略: * LocalFileOffsetStore : Consumer记录消息的消费进度。 * RemoteBrokerOffsetStor : Broker记录消息的消费进度。 广播模式默认使用Lo....
RocketMQ生产者核心概念 2020-01-07 常见核心配置 VIM /test/rocketmq/distribution/target/apache-rocketmq/conf/2m-2s-sync/broker-a.properties compressMsgBodyOverHowmuch :消息超过默认字节 4096 后进行压缩 retryTimesWhenSendFailed : 失败重发次数 maxMessageSize : 最大消息配置,默认 128k topicQueueNums : 主题下面的队列数量,默认是 4 autoCreateTopicEnable : 是否自动创建主题 Topic, 开发建议为 true,生产要为 false defaultTopicQueueNums : 自动创建服务器不存在的 topic,默认创建的队列数 autoCreateSubscriptionGroup: 是否允许 Broker 自动创建订阅组,建议线下开发开启,线上关闭 brokerClusterName : 集群名称 brokerId : 0 表示 Master 主节点 大于 0 表示从节点 brokerIP1 : Br....
RocketMQ集群高可用之主从模式 2020-01-07 常见集群模式 推荐方案 2、4、5 单节点 优点:本地开发测试,配置简单,如果采用同步刷盘,消息一条都不会丢。 缺点:不可靠,如果宕机,会导致服务不可用 主从(异步、同步双写) 优点:同步双写消息不丢失, 异步复制存在少量丢失 ,主节点宕机,从节点可以对外提供消息的消费,但是不支持写入。 缺点:主备有短暂消息延迟,毫秒级,目前不支持自动切换,需要脚本或者其他程序进行检测然后进行停止broker,重启让从节点成为主节点 双主 优点:配置简单, 可以靠配置RAID磁盘阵列保证消息可靠,异步刷盘丢失少量消息 缺点: master机器宕机期间,未被消费的消息在机器恢复之前不可消费,实时性会受到影响 双主双从,多主多从模式(异步复制) 优点:磁盘损坏,消息丢失的非常少,消息实时性不会受影响,Master 宕机后,消费者仍然可以从Slave消费 缺点:主备有短暂消息延迟,毫秒级,如果Master宕机,磁盘损坏情况,会丢失少量消息 双主双从,多主多从模式(同步双写) 优点:同步双写方式,主备都写成功,向应用才返回成功,服务可用性与数据可用性都非常高 缺点:性能比异步复制模式略低,主宕机后,....
Springboot整合RocketMQ 2020-01-07 Trouble Shooting 多网卡下为 rocketmq 指定 IP # 修改配置文件 vim /test/rocketmq/distribution/target/apache-rocketmq/conf/broker.conf brokerIP1=192.168.31.220 #新增内容 # 启动Broker命令命令 nohup sh /test/rocketmq/distribution/target/apache-rocketmq/bin/mqbroker -n 192.168.31.220:9876 -c /test/rocketmq/distribution/target/apache-rocketmq/conf/broker.conf & 控制台查看不了数据,提示连接 10909 错误 原因:Rocket默认开启了VIP通道,VIP通道端口为10911-2=10909 解决:阿里云安全组需要增加一个端口 10909 消息发送 添加 Maven 相关依赖 <dependency> <groupId>org.apache.rocket....