两个台电脑 ● Mac OS ● 地址：192.168.166.20 ● Cent OS ● 地址：192.168.166.206 保证两台电脑在同一网段，端口是通的，可以关闭防火墙 需要开放的端口：NameServer的9876端口、Broker的10911、11011、10909、11009端口 Mac OS rocketmq配置文件 1、编辑 conf/2m-2s-async/broker-a

不不同云⼚厂商之间消息产品互操作性成本较⾼高，⽤用户跨云⼚厂商迁移难 • 云上与云下产品的⽆无缝衔接能⼒力力差 云原⽣生与业界标准 OpenMessaging AMQP • 简单灵活 • 云原⽣生 • ⼚厂商中⽴立 • 语⾔言⽆无关 • ⾯面向消息和流的标准 关注阿⾥里里巴巴中间件微信公众号，与技术同⾏行行。 关注RocketMQ中国开发者公众号

存储集群 高可用架构升级： • 秒级故障转移，多场景容灾支持 • 无外部依赖，节点间松散耦合 • 自建及云上异构 IaaS 基础设施支持，降低成本 轻量级SDK： • 全面支持云原生通信标准 gRPC 协议 • 无状态 Pop 消费模式，多语言友好，易集成 从业务走向数据： • 事件流场景支撑 • 面向 SQL 的轻量级实时计算引擎 可分可合的存储计算分离： • Broker 升级为真正的无状态服务节点，无 binding • Broker和Store节点分离部署、独立扩缩 • 可分可合，适应多种业务场景，降低运维负担 云原生基础设施： • 可观测性能力云原生化，OpenTelemetry 标准化 • Kubernetes 一键式部署扩容交付 W r i t e h e r e S o m e t h i n g Ab o u t 全新 POP 消费模型 服务端负载均衡 

time to recover. ???? = 1 seconds ???????????? = >?∗>?∗AB C D >?∗>?∗AB = 99.999% 1.4万亿 双十一当天高可用标准 0 200 400 600 800 1000 1200 1400 1600 1 6 11 16 21 26 31 36 41 46 51 56 61 66

time to recover. ???? = 1 seconds ???????????? = >?∗>?∗AB C D >?∗>?∗AB = 99.999% 1.4万亿 双十一当天高可用标准 0 200 400 600 800 1000 1200 1400 1600 1 6 11 16 21 26 31 36 41 46 51 56 61 66

[PC_SYNCHRONIZED]broker busy  [PCBUSY_CLEAN_QUEUE]broker busy 判断 pagecache 是否忙的依据就是在写入消息时，在向内存追加消息时加锁的时间， 默认的判断标准是加锁时间超过 1s，就认为是 pagecache 压力大，向客户端抛出相关的 错误日志。 发送线程池挤压的拒绝策略 在 RocketMQ 中处理消息发送的是一个只有一个线程的线程池，内部会维护一个有界 会有重试机制。 3. TIMEOUT_CLEAN_QUEUE 解决方案 由于如果出现 TIMEOUT_CLEAN_QUEUE 的错误，客户端暂时不会对其进行重试， 故现阶段的建议是适当增加快速失败的判断标准，即在 broker 的配置文件中增加如下配置： ＃该值默认为 200，表示 200ms waitTimeMillsInSendQueue=1000 温馨提示，关于 Broker busy，笔者发表过两篇文章，大家也可以结合着看：