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....
