广告活动网站的策划,黄冈贴吧,50篇经典软文100字,怎么样建设自己网站在美国的大学课程中#xff0c;101是所有课程中的第一门#xff0c;是新生入学后的必修课程。阿里巴巴中间件技术专家刘振东在上周的Apache RocketMQ开发者沙龙北京站的活动上#xff0c;进行了主题为《ApacheRocketMQ 101》的分享#xff0c;帮助开发者从0开始学习 Apache…在美国的大学课程中101是所有课程中的第一门是新生入学后的必修课程。阿里巴巴中间件技术专家刘振东在上周的Apache RocketMQ开发者沙龙北京站的活动上进行了主题为《ApacheRocketMQ 101》的分享帮助开发者从0开始学习 Apache RocketMQ除了一些基础的入门内容外还有很多是在社区未发表过的个人所感所悟首次对外分享。分享内容包括RocketMQ的起源、RocketMQ概念模型、存储模型、部署模型和最佳实践总结其中最佳实践的内容是阿里中间件技术类岗位的必考面试题。 嘉宾介绍刘振东阿里巴巴中间件技术专家Apache RocketMQ PMC/Committer2016年中间件性能挑战赛亚军具有丰富的分布式系统设计和优化经验目前负责Apache RocketMQ新航道探索和创新。 一、RocketMQ的起源
通常每个产品的诞生都源于一个具体的需求或问题RocketMQ也不例外。起初产品的原型像一个巨石把所有需要实现的程序和接口都罗列到一起。但随着公司业务的发展所有的系统和功能都在这个巨石上开发当覆盖几百上千名开发人员的时候瓶颈就出来了。这时候就需要我们把系统进行分解。 图释巨石 - 分布式
分解后就出现了上图中的分布式架构这类架构最大的特点就是解耦而RocketMQ的异步解耦意味着底层的重构不会影响到上层应用的功能。RocketMQ另一个优势是削峰填谷在面临流量的不确定性时实现对流量的缓冲处理。此外RocketMQ的顺序设计特性使得RocketMQ成为一个天然的排队引擎例如三个应用同时对一个后台引擎发起请求排队引擎的特性可以确保不会引起“撞车”事故。 二、RocketMQ的概念模型
对于任何一款中间件产品而言清晰的概念模型是帮助开发者正确理解使用它的关键。从RocketMQ的概念模型来看Topic是用于存储逻辑的地址的Producer是信息的发送Consumer是信息的接收者。 图释最基本的概念模型
这只是一个基础的概念模型在实际的生产中结构会更复杂例如我们需要对中间的Topic进行分区出现多个有关联的Topic再如同一个信息的发送方会有多个订阅者同一个需求方会有多个发送方出现一对多、多对一的情况。 图释扩展后的概念模型
上图就是对Topic、Producer、Consumer扩展后的概念模型。RocketMQ中可以接触到的所有概念都可以在这个概念模型图中找到。左边有两个Producer中间就是两个分布式的Topic用于存储逻辑地址的两个Topic中分别有两个用于存储物理存储地址的Message QueueBroker是实际部署过程的对应的一台设备右边则是两个ConsumerConsumer Group是代表两个Consumer可共享相互之间的订阅。不同的Consumer Group相互独立。一句话总结就是不同的Group是广播订阅的同一个Group则是负载订阅的。图中的连线表示各模块之间的关系例如Consumer Group A中的Consumer1对应着Message Queue0和Message Queue1的两个队列分布在BrokerA这一台设备上。 三、RocketMQ的存储模型
RocketMQ的消息的存储是由ConsumeQueue和CommitLog 配合来完成的ConsumeQueue中只存储很少的数据消息主体都是通过CommitLog来进行读写。 图释存储模型
CommitLog是消息主体以及元数据的存储主体对CommitLog建立一个ConsumeQueue每个ConsumeQueue对应一个概念模型中的MessageQueue所以只要有Commit Log在Consume Queue即使数据丢失仍然可以恢复出来。
Consume Queue是一个消息的逻辑队列存储了这个Queue在CommitLog中的起始offsetlog大小和MessageTag的hashCode。每个Topic下的每个Queue都有一个对应的ConsumerQueue文件例如Topic中有三个队列每个队列中的消息索引都会有一个编号编号从0开始往上递增。并由此一个位点offset的概念有了这个概念就可以对Consumer端的消费情况进行队列定义。 四、RocketMQ的部署模型
在实际的部署过程中Broker是实际存储消息的数据节点Nameserver则是服务发现节点Producer发送消息到某一个Topic并给到某个Consumer用于消费的过程中需要先请求Nameserver拿到这个Topic的路由信息即Topic在哪些Broker上有每个Broker上有哪些队列拿到这些请求后再把消息发送到Broker中相对的Consumer在消费的时候也会经历这个流程。 图释部署模型 五、RocketMQ最佳实践总结
这是我们在实践过程的总结同时我们也把其中一些普适性的总结作为阿里中间件技术岗的面试题目的是帮助大家更深刻的理解我们在设计分布式消息系统的一些思考和探索。
Q1分布式消息系统中如何避免消息重复
造成消息重复的根本原因是网络不可靠。只要通过网络交换数据就无法避免这个问题。所以解决这个问题的办法就是绕过这个问题。那么问题就变成了如果消费端收到两条一样的消息应该怎样处理
a. 消费端处理消息的业务逻辑保持幂等性;
b. 保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现。
通过幂等性不管来多少条重复消息可以实现处理的结果都一样。再利用一张日志表来记录已经处理成功的消息的ID如果新到的消息ID已经在日志表中那么就可以不再处理这条消息避免消息的重复处理。
Q2顺序消息扩容的过程中如何在不停写的情况下保证消息顺序
1. 成倍扩容实现扩容前后同样的keyhash到原队列或者hash到新扩容的队列
2. 扩容前记录旧队列中的最大位点
3. 对于每个Consumer Group保证旧队列中的数据消费完再消费新队列也即先对新队列进行禁读即可
Q3分布式消息系统中如何对消息进行重放
消费位点就是一个数字把Consumer Offset改一下就可以达到重放的目的了。 Apache RocketMQ部分开发者合影
原文链接 本文为云栖社区原创内容未经允许不得转载。
