4.23文创礼盒,买2个减5元 读书月福利
欢迎光临中图网 请 | 注册
> >>
RocketMQ分布式消息中间件(核心原理与最佳实践)

RocketMQ分布式消息中间件(核心原理与最佳实践)

作者:李伟
出版社:电子工业出版社出版时间:2020-08-01
开本: 16开 页数: 264
中 图 价:¥51.4(6.5折) 定价  ¥79.0 登录后可看到会员价
加入购物车 收藏
运费6元,满69元免运费
?快递不能达地区使用邮政小包,运费14元起
云南、广西、海南、新疆、青海、西藏六省,部分地区快递不可达
本类五星书更多>

RocketMQ分布式消息中间件(核心原理与最佳实践) 版权信息

  • ISBN:9787121392672
  • 条形码:9787121392672 ; 978-7-121-39267-2
  • 装帧:一般胶版纸
  • 册数:暂无
  • 重量:暂无
  • 所属分类:>>

RocketMQ分布式消息中间件(核心原理与最佳实践) 本书特色

适读人群 :对RocketMQ有了解、使用的经验后,想要深入源码而无从下手的人员。 ?? 希望学习消息队列和分布式系统的开发人员。 ?? 企业消息中间件维护和支持人员。 ?? RocketMQ代码贡献者。 ?? 支持开源的技术工作者。编辑推荐 权威:Apache RocketMQ Committer编著 实用:本书分享笔者近年来在企业中治理RocketMQ的经验和所踩的坑 全面:笔者根据实践整理了RocketMQ的核心组件配置项和其说明,包含: Namesrv全部配置项(17个) Broker全部配置项(141个) Prometheus Exporter核心监控指标(82个) 图文+源码:大量图文+代码快分析,读者更易理解RocketMQ原理与代码实现逻辑

RocketMQ分布式消息中间件(核心原理与最佳实践) 内容简介

本书源码以RocketMQ 4.2.0和RocketMQ 4.3.0为基础,从RocketMQ的实际使用到RocketMQ的源码分析,再到RocketMQ企业落地实践方案,逐步讲解。使读者由浅入深地了解RocketMQ。本书在源码分析过程中,先讲整体流程,再按模块、步骤进行详细讲解,希望读者在阅读时能举一反三,能知其然且知其所以然。本书总共九章,分为五部分,部分讲解消息队列入门和RocketMQ生产、消费原理与很好实践;第二部分从整体角度讲解RocketMQ架构;第三部分讲解RocketMQ各个组件的基本原理;第四部分深入RocketMQ,讲解如何阅读源代码、如何进行企业实践;第五部分是附录,包含Namesrv、Broker的核心参数配置说明和Exporter监控指标注释。希望读者在平时的工作中能熟悉、借鉴、参考RocketMQ的很好设计理念,在技术能力上更进一步,在工作中更好地服务公司。希望读者在平时的工作中能熟悉、借鉴、参考RocketMQ的很好设计理念,在技术能力上更进一步,在工作中更好地服务公司。

RocketMQ分布式消息中间件(核心原理与最佳实践) 目录

目  录

第1章 RoketMQ综述 1
1.1 什么是消息队列 2
1.2 为什么需要消息队列 4
1.2.1 削峰填谷 4
1.2.2 程序间解耦 5
1.2.3 异步处理 6
1.2.4 数据的*终一致性 6
1.3 常见消息队列 7
1.4 RocketMQ的发展史与未来 9
1.4.1 RocketMQ的发展史 9
1.4.2 Apache RocketMQ的未来 11
第2章 RocketMQ的生产者原理和*佳实践 14
2.1 生产者原理 15
2.1.1 生产者概述 15
2.1.2 消息结构和消息类型 16
2.1.3 生产者高可用 17
2.2 生产者启动流程 22
2.3 消息发送流程 32
2.4 发送消息*佳实践 36
2.4.1 发送普通消息 36
2.4.2 发送顺序消息 37
2.4.3 发送延迟消息 37
2.4.4 发送事务消息 38
2.4.5 发送单向消息 40
2.4.6 批量消息发送 41
2.5 生产者*佳实践总结 42
第3章 RocketMQ的消费流程和*佳实践 44
3.1 消费者概述 45
3.1.1 消费流程 45
3.1.2 消费模式 46
3.1.3 可靠消费 48
3.2 消费者启动机制 50
3.3 消费者的Rebalance机制 58
3.4 消费进度保存机制 65
3.5 消费方式 70
3.5.1 Pull消费流程 71
3.5.2 Push消费流程 72
3.6 消息过滤 86
3.6.1 为什么要设计过滤功能 86
3.6.2 RocketMQ支持消息过滤 86
3.7 消费者*佳实践总结 91
第4章 RocketMQ架构和部署*佳实践 94
4.1 RocketMQ架构 95
4.2 常用的部署拓扑和部署实践 96
4.2.1 常用的拓扑图 96
4.2.2 同步复制、异步复制和同步刷盘、异步刷盘 97
4.2.3 部署实践 98
第5章 Namesrv 102
5.1 Namesrv概述 103
5.1.1 什么是Namesrv 103
5.1.2 Namesrv核心数据结构和API 103
5.1.3 Namesrv和Zookeeper 105
5.2 Namesrv架构 106
5.2.1 Namesrv组件 106
5.2.2 Namesrv启动流程 108
5.2.3 Namesrv停止流程 110
5.3 RocketMQ的路由原理 111
5.3.1 路由注册 111
5.3.2 路由剔除 112
第6章 Broker存储机制 114
6.1 Broker概述 115
6.1.1 什么是Broker 115
6.1.2 Broker存储目录结构 116
6.1.3 Broker启动和停止流程 117
6.2 Broker存储机制 125
6.2.1 Broker消息存储结构 126
6.2.2 Broker消息存储机制 130
6.2.3 Broker读写分离机制 150
6.3 Broker CommitLog索引机制 155
6.3.1 索引的数据结构 155
6.3.2 索引的构建过程 158
6.3.3 索引如何使用 159
6.4 Broker过期文件删除机制 162
6.4.1 CommitLog文件的删除过程 162
6.4.2 Consume Queue、Index File文件的删除过程 166
6.5 Broker主从同步机制 167
6.5.1 主从同步概述 168
6.5.2 主从同步流程 169
6.6 Broker的关机恢复机制 174
6.6.1 Broker关机恢复概述 174
6.6.2 Broker关机恢复流程 177
第7章 RocketMQ特性――事务消息与延迟消息机制 182
7.1 事务消息概述 183
7.2 事务消息机制 184
7.2.1 生产者发送事务消息和执行本地事务 184
7.2.2 Broker存储事务消息 188
7.2.3 Broker回查事务消息 191
7.2.4 Broker提交或回滚事务消息 197
7.3 延迟消息概述 201
7.4 延迟消息机制 203
7.4.1 延迟消息存储机制 203
7.4.2 延迟消息投递机制 205
第8章 RocketMQ源代码阅读 208
8.1 RocketMQ源代码结构概述 209
8.2 RocketMQ源代码编译 212
8.3 如何阅读源代码 214
8.4 源代码阅读范例:通过消息id查询消息 216
第9章 RocketMQ企业*佳实践 224
9.1 RocketMQ落地概述 225
9.1.1 为什么选择RocketMQ 225
9.1.2 如何做RocketMQ的集群管理 226
9.2 RocketMQ集群管理 230
9.2.1 Topic管理 230
9.2.2 消费者管理 235
9.3 RocketMQ集群监控和报警 240
9.3.1 监控和报警架构 240
9.3.2 基于Grafana监控 242
9.3.3 基于Prometheus的报警 243
9.4 RocketMQ集群迁移 244
9.5 RocketMQ测试环境实践 245
9.6 RocketMQ接入实践 247
9.6.1 Spring接入RocketMQ 247
9.6.2 Python接入RocketMQ 249
附录 252

展开全部

RocketMQ分布式消息中间件(核心原理与最佳实践) 节选

第9章RocketMQ企业*佳实践 前面几章介绍了RocketMQ各个组件的功能和基本原理,本章主要介绍RocketMQ如何在企业落地,主要内容如下: l RocketMQ集群管理。 l RocketMQ集群监控和报警。 l RocketMQ集群测试环境实践。 l Spring和Python如何接入RocketMQ? 9.1 RocketMQ落地概述 9.1.1 为什么选择RocketMQ 一款技术产品要在企业落地是非常困难的,笔者总结了几个要点,供读者在选择一款技术产品时参考:稳定可靠、运维与管理方便、低成本、性能考量。 接下来,我们对消息队列中间件的选型做详细分析。 业务需求永远是**需求。对业务而言,组件能够稳定、可靠、可持续地保障业务正常流转肯定是首要的需求。在经历过阿里巴巴、VIPKID、蚂蚁金服、微众银行等对于稳定性有极致需求的大厂洗礼后,稳定、可靠成为了RocketMQ的代言词。 作为技术人员,一款产品的管理、运维和开发的难易程度也是选型的重要参考指标。现代互联网公司不同于传统企业,快速迭代、快速把握市场才是王道。简单、方便的产品能快速支持业务起步,对开发者友好的或者自研的产品总是容易掌控,也能快速适应业务的发展和变化。 RocketMQ使用Java语言开发,做二次开发或集成到现有系统难度较低。RocketMQ社区也相当活跃,文档包含中英文,对国内开发者非常友好。同时,社区提供的管理平台功能完善,更新也比较活跃,RocketMQ的衍生产品也非常丰富,比如rocketmq-connect-es、rocketmq-flink、rocketmq-hbase等。 成本,对于商业公司是必须要考虑的。这里的成本包含硬成本和软成本,如图9-1所示。 下面,我们介绍一下硬成本。服务器成本:技术产品都需要部署在硬件服务器上才能提供服务,硬件包含内存、CPU、磁盘等耗材,配置越高花费越大。 软件授权成本:对开源产品而言,虽然企业付出的金钱成本为0,更多的却是责任。RocketMQ在阿里巴巴内部从一个普通技术项目到一个可靠的、可用的技术项目经历了11年(从2001年到2012年),从一个技术项目再到技术产品经历了4年(从2012年到2016年),从阿里巴巴走向Apache的开源之路又经历了4年(从2016年到现在2020年),总共经历了19年,阿里巴巴和社区的付出有多少我们难以想象。作为一个普通的技术从业者,“拿来主义”不提倡,投桃报李方可行。 对于软成本,笔者觉得比硬成本更重要,因为它是看不见的,往往被大家忽略。可能很多人追求技术的创新却忘记了软成本,导致留下无数的技术债,随着业务不断发展,技术壁垒也愈发明显。 *后一个重要的考虑:性能。2020年互联网行业仍然是流量的行业,高并发、大吞吐是当前面临的*大挑战之一。RocketMQ在阿里巴巴内部各个平台都广泛使用,并且成功支撑了多个双11万亿级别的消息流量,充分证明了RocketMQ强大的吞吐能力。 9.1.2 如何做RocketMQ的集群管理 RocketMQ的集群管理主要是对集群中Broker、Namesrv、Topic、生产者、消费者进行统一管控。 RocketMQ本身提供了一系列的管理接口,具体实现在org.apache.rocketmq.tools.admin. DefaultMQAdminExt.java文件中,源代码结构如图9-2所示。 一般在生成环境中严禁开放自动创建Topic和消费者组,需要通过API进行统一管理。下面简单列出了4.2.0版本支持的一些管理API,如表9-1所示,供大家在自研治理系统时参考。当然原生工具也提供命令行管理。 表9-1的大部分核心功能在社区提供的RocketMQ-Console管理平台中都有,笔者建议使用RocketMQ-Console或者像VIPKID一样自研一套管理平台替代命令行操作,这样更加安全可靠。如何搭建RocketMQ-Console在4.2.2节中有详细的描述,读者可以按照描述一步步操作搭建。 在VIPKID,我们基于RocketMQ开发了VKMQ(VIPKID消息队列),包含Broker、 Namesrv、游乐场管理平台、基于Prometheus的监控报警模块(Prometheus Exporter代码已经贡献给Apache社区,可以直接下载使用)等整套生态,负责中国、美国等世界几十个国家和地区之间的消息扭转,目前的生产环境已稳定地运行了两年多。 在VIPKID,*重要的不是知道如何管理集群,而是要知道在管理方法后面的每一个操作都需要有Double-Check。 接下来,笔者将基于社区版RocketMQ Console讲解企业在践行RocketMQ时遇到的问题较多的场景。 9.2 RocketMQ集群管理 9.2.1 Topic管理 Topic管理是集群管理中常见的操作,包括创建Topic、查看Topic路由、修改Topic配置、重置消费位点。 1.创建Topic 创建Topic的核心在于,你需要知道Topic和队列(Queue)的关系,也叫Topic路由分布,下面展示一个名为topicA的Topic路由关系,如图9-3所示。 如图9-3所示,topicA有4个Queue,分布在两台Broker上。当有消息发送的时候,默认会均匀地发送给这4个Queue。 接下来我们看看如何在RocketMQ Console上创建topicA。 我们进入Topic管理页面,单击“新增/更新”按钮,会出现如图9-4所示的弹窗。 下面将依次讲解每个输入框的含义。 集群名:RocketMQ集群名,和下一个选项BROKER_NAME二者选其一,如果选择集群名,则表示这个新建Topic的Queue会分布在这个集群的全部Broker中。 BROKER_NAME:RocketMQ Broker的名字,选择后新建Topic的Queue会分布在选中的Broker机器上。集群名和BROKER_NAME只需选择一个就可以。 主题名:Topic名字,字符串长度不能超过255,不能与系统默认名字冲突,还需要满足正则表达式:^[%|a-zA-Z0-9_-]+$。 读/写队列数量:每台Broker上Queue的数量,建议设置为相同值。 perm:Topic权限,这是一个常量,该常量的定义在org.apache.rocketmq.common. constant.PermName类中。2表示只写,4表示只读,6表示读写均可。 创建完成后,检查创建的Topic是否和我们预期的一致。刷新页面后,搜索刚刚创建的topicA,单击“路由信息”按钮,可以看到topicA的路由信息如图9-5所示。 更新Topic在实际业务场景中会经常用到,我们通过两个场景进行具体的讲解。 场景1:Topic扩容 如果在实际业务中发现当前的发送效率已经不能满足业务需求,那么扩容是一种常用的处理手段。如图9-3所示,接受topicA消息的全部压力都在master broker 1和master broker 2上,我们怎样才能用新机器分摊压力呢? **步:部署新的master broker 3、master broker 4机器,部署步骤详见4.2.2节。 第二步:回到RocketMQ Console平台的Topic管理页面,单击“新增/更新”按钮。 第三步:如图9-4所示,在BROKER_NAME输入框中选择新加的Broker。在输入Queue数量时要注意读、写Queue的数值表示在单台Broker中的数量,如果想将一半的流量分流到新的Broker中,那么读、写Queue数量都填2。扩容后topicA的发送效率将增加一倍,新旧2组机器压力承担比例为1:1,扩容后topicA的路由图变成如图9-6所示的样子。 场景2:Topic权限更改 如图9-6所示,如果扩容后Master Broker 4机器有问题,那么理论上topicA会有1/4的消息发送失败,此时可以更改topicA在Master Broker 4上的权限为0,表示不可读、不可写,如图9-7所示。 我们稍加分析可知,master broker 4在禁止读写后,topicA的路由会改变,全部的生产者在感知到路由变化后,不再将消息发送到master broker 4。 消费者在进行Rebalance后,也会感知topicA的路由发生变化,将不再从master broker 4拉取消息消费。

RocketMQ分布式消息中间件(核心原理与最佳实践) 作者简介

李伟 Apache RocketMQ北京社区联合发起人,RocketMQ项目Commiter,RocketMQ社区Python客户端项目负责人。目前就职于北京某在线教育公司,担任数据中间 件架构师,负责公司内部消息和数据流平台,对分布式存储系统设计和研发有丰富经验,热衷于知识分享和社区活动。 座右铭:Programming is not only a way to problems,but also to think! RocketMQ社区 RocketMQ是Apache软件基金会(Apache Software Foundation,简称ASF)运作的一个高级开源软件项目。 Apache软件基金会成立于1999年,是一个运作开源软件的非营利性组织。截至目前,拥有个人成员数730+、Commiter数7000+、ASF运营项目数350+,我们所熟知的开源项目有依赖管理工具Apache Maven,Web服务器Apache Tomcat,数据存储Apache HBase、Apache Hive,计算引擎Apache Flink、Apache Hadoop等。 欢迎加入Apache RocketMQ国内讨论钉钉群:

商品评论(0条)
暂无评论……
书友推荐
本类畅销
编辑推荐
返回顶部
中图网
在线客服