RabbitMQ大型电商网站实践

1 .RabbitMQ大型电商网站实践 朱小厮 

2 .主要内容 Producer Consumer Broker 

3 .RabbitMQ简介 RabbitMQ Broker Queue1 Consumer1 Producer1 Exchange1 Consumer2 Queue2 Producer2 Exchange2 Consumer3 

4 .客户端——Producer 发送的消息是否正确 的送达到Broker中？ 

5 .客户端——Producer 解决：AMQP协议——事务机制 使用事务机制会“吸干”RabbitMQ的性能， 那么有没有更好的解决方案？ 

6 .客户端——Producer 

7 .客户端——Producer 2500 2000 1500 1000 500 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 事务机制 发送方确认机制 

8 .客户端——Producer 

9 .客户端——Producer 16000 14000 12000 10000 8000 6000 4000 2000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 事务 普通confirm 批量confirm 异步confirm 单Queue的QPS达到上限了嚒？还能再优化么？ 

10 .性能优化（1）——合并&压缩 CPU 

11 .性能优化（2）——Lazy Queue 25000 20000 15000 10000 5000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 222324 25 26 27 282930 31 323334 35 default lazy RabbitMQ3.6.0才引入的Lazy Queue 

12 .性能优化（3）——HiPE 16000 14000 +20% 14000 13500 12000 13000 10000 12500 8000 hipe 12000 6000 default 13384.58 11500 4000 11000 11210.56 2000 10500 7 0 10000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 1 2 default hipe 

13 .性能优化（3）——HiPE 25000 25000 +29% 20234.38 20000 20000 +72% 15661.18 15000 15000 10000 10000 9106.763 5000 5000 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 0 default lazy lazy+hipe 1 2 3 default lazy lazy+hipe Erlang的版本不能低于18.x 

14 .性能优化（4）——流控链 {{credit_from, B}, value} {{credit_from, C}, value} {{credit_from, xxx}, value} {{credit_to, xxx}, value} {{credit_to, A}, value} {{credit_to, B}, value} Process A Process B Process C 

15 .性能优化（4）——流控链 Network rabbit_reader rabbit_amqqueue rabbit_channel rabbit_msg_store (Connection) _process Connection进程 其中的各个进程为： Channel进程 • rabbit_reader：Connection的处理进程，负责接收、解析AMQP协 议数据包等。 • rabbit_channel：Channel的处理进程，负责处理AMQP协议的各 Queue进程 种方法、进行路由解析等。 • rabbit_amqqueue_process：队列的处理进程，负责实现队列的所 有逻辑。 消息存储 • rabbit_msg_store：负责实现消息的持久化。 设置的值太大会失去了流控的保护 

16 .性能优化（5）——“曲线救国” 将易造成性能瓶颈的多个rabbitmq_amqqueue_process对外包装成一个队列。 类比Kafka中的partitions。 rabbit_amqqueue _process rabbit_amqqueue _process rabbit_reader rabbit_channel rabbit_msg_store (Connection) rabbit_amqqueue _process rabbit_amqqueue _process 

17 .客户端——Producer封装 queue_0 message queue_1 in slot0 slot1 Channel Channel queue_2 (delivery) slot2 (publish) slot3 queue_3 message out 60000 50000 40000 30000 单个队列 4个队列 20000 10000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 

18 .Basic.Qos的思考 channel.basicQos( int prefetch_count) 

19 .Basic.Qos的思考 (50ms+50ms+4ms=104ms) vs. (4ms) 消息堆积 

20 .消息堆积的治理 方案1: 丢弃策略：设置消息保留时间或者保留大小（可以是个数或者占 用大小），超过就丢弃。 方案2: Lazy Queue 方案3: “移花接木” 

21 .消息堆积的治理——“移花接木” 运行集群cluster1 queue1 原集群 原集群 Shovel1 备份集群cluster2 Shovel2 queue2 原集群 原集群 其他用途？ 

22 .Shovel应用——集群迁移 对于RabbitMQ运维层面来说，扩容和迁移是必不可少的。 客户端 原集群 Shovel producer Cluster1 原集群 (原集群) consumer 原集群 Cluster2 原集群 (新集群) 为了消息不丢失，一般先迁移producer的连接，然后再迁移consumer的 连接。 

23 .集群故障 机器 硬件 掉电 网络 故障 挖断 进程 假死 网络 分区 Others 

24 .网络分区 出现网络分区时，不同分区里的节点会认为不属于自身所在分区的节点都已经挂 了（down），对于队列、交换器、绑定的操作仅对当前分区有效。 A B (master) (slave1) D C (slave3) (slave2) 网络延迟/波动 如何判定？ 

25 .网络分区——判定 RabbitMQ集群节点内部通信端口默认为25672，两两节点之间都会有信 息交互。如果某节点出现网络故障，亦或者是端口不通，则会致使与此 节点的交互出现中断，这里就会有个超时判定机制，既而判定网络分 区。 1.25*ticktime 0.75*ticktime 将连续4次的tick时间记为T，那么T的取 值范围为：0.75*net_ticktime < T < 1.25*net_ticktime。 有何影响？ 

26 .网络分区——影响 [A,B] => [A],[B] client broker mirror-queue 如何监控？ 

27 .网络分区 

28 .Thank You!