Apache RocketMQ

分布式之分布式事务、分布式锁、分布式Session

拟墨画扇 提交于 2021-02-17 12:48:35
点击上方 " 程序员小乐 "关注, 星标或置顶一起成长 每天凌晨00点00分, 第一时间与你相约 每日英文 It is our choices... that show what we truly are, far more than our abilities.J. K. Rowling . 决定我们一生的,不是我们的能力,而是我们的选择。 每日掏心 话 没有不能改变的事,因为自己改变了,状况也就跟着转变。 来自 : ava未来的大佬 | 责编:乐乐 链接:cnblogs.com/heqiyoujing/p/10917102.html 程序员小乐(ID:study_tech) 第 959 次推文 图源:百度 往日回顾: 程序员吐槽:入职两周,怀疑自己进了假百度!跟传说中完全不一样 正文 一、分布式session   session 是啥?浏览器有个 cookie,在一段时间内这个 cookie 都存在,然后每次发请求过来都带上一个特殊的 jsessionid cookie ,就根据这个东西,在服务端可以维护一个对应的 session 域,里面可以放点数据。   一般的话只要你没关掉浏览器,cookie 还在,那么对应的那个 session 就在,但是如果 cookie 没了,session 也就没了。常见于什么购物车之类的东西,还有登录状态保存之类的。   这个不多说了,懂

Sping Boot入门到实战之实战篇(一):实现自定义Spring Boot Starter——阿里云消息队列服务Starter

喜夏-厌秋 提交于 2021-02-16 11:19:29
  在 Sping Boot入门到实战之入门篇(四):Spring Boot自动化配置 这篇中,我们知道Spring Boot自动化配置的实现,主要由如下几部分完成: @EnableAutoConfiguration注解 SpringApplication类 spring-boot-autoconfigure jar包 spring.factories文件   官方提供的starter,大多包含两个jar包: 一个starter——没有任何实现,只用来管理依赖(spring.providers文件声明),一个autoconfigure包——包含所有具体实现,包括自动配置类,及META-INF/spring.factories文件。自定义starter的时候,可以合并写到一个。   官方提供的starter,命名遵循spring-boot-starter-xx, 自定义starter,命名遵循xx-spring-boot-starter。   本文基于阿里云消息队列RocketMQ服务(https://help.aliyun.com/document_detail/43349.html?spm=a2c4g.11186623.3.2.Ui5KeU),实现一个自定义starter,以实现定时消息与延迟消息(如订单多久未支付自动关闭等)发送与接收功能的快速开发。源码地址: mq

行远自迩,不负韶华!2020年度博客之星TOP 20榜单揭晓

不羁的心 提交于 2021-02-15 09:38:36
技术领域风云迭起,行业浪潮纷至沓来,作为技术人该如何永葆纯粹的本心? CSDN一直以来都专注致力于为 IT技术人创造交流和成长的家园,用 走过的二十载岁月见证了一代又一代技术人的成长 。 对于笔耕不缀的技术人来说,文章不仅是他们分享心得、总结所获的体现,也是他们布道知识、精进技术的证明。在CSDN网站的博客频道,数万人长年在键盘后面专注编码,以乐于分享的精神助力IT产业发展......作为迄今为止CSDN官方规格最高、覆盖面最广、奖励力度最大的活动,“博客之星”每年都会组织广大网友和专家评委,共同遴选出年度最受欢迎的TOP博主,以表彰其优异的专业实力和长期伏案的精心创作。 诗歌合为事而作,文章合为时而著。2020年度评选,从2020年12月17日启动,历经海选报名、网友投票、专家团评审等阶段的激烈角逐,最终于今天落下帷幕。在这之中,我们紧紧依靠众多博主的鼎力支持,同时也赢得了众多新星博主的青睐和积极参与。同时,我们严防严控刷票行为,使技术回归到原本的严谨态度,提升博客专家投票特权,让结果变得更有含金量!未来,我们也会一如既往的坚持下去,成就更多的IT技术人。 2020年度博客之星TOP 20英雄榜,就让我们一起重磅揭晓! TOP1 敖 丙 “程序员真的是最容易改变命运的一个职业”,敖丙在自己的博文中写道,“生活如水,时而浑浊,时而清澈”,面对挫折我们可以短暂的迷失

RocketMQ中Broker的刷盘源码分析

与世无争的帅哥 提交于 2021-02-15 04:03:51
上一篇博客的最后简单提了下CommitLog的刷盘 【RocketMQ中Broker的消息存储源码分析】 (这篇博客和上一篇有很大的联系) Broker的CommitLog刷盘会启动一个线程,不停地将缓冲区的内容写入磁盘(CommitLog文件)中,主要分为异步刷盘和同步刷盘 异步刷盘又可以分为两种方式: ①缓存到mappedByteBuffer -> 写入磁盘(包括同步刷盘) ②缓存到writeBuffer -> 缓存到fileChannel -> 写入磁盘 (前面说过的开启内存字节缓冲区情况下) CommitLog的两种刷盘模式: 1 public enum FlushDiskType { 2 SYNC_FLUSH, 3 ASYNC_FLUSH 4 } 同步和异步,同步刷盘由GroupCommitService实现,异步刷盘由FlushRealTimeService实现,默认采用异步刷盘 在采用异步刷盘的模式下,若是开启内存字节缓冲区,那么会在FlushRealTimeService的基础上开启CommitRealTimeService 同步刷盘: 启动GroupCommitService线程: 1 public void run() { 2 CommitLog.log.info( this .getServiceName() + " service started" ); 3

源码分析RocketMQ刷盘机制

一个人想着一个人 提交于 2021-02-14 21:36:01
刷盘机制支持同步刷盘和异步刷盘。为了了解其具体事项,我们以Commitlog的存储为例来说明RocketMQ是如何进行磁盘读写。 Comitlog#putMessage 首先,主要是将消息写入到MappedFile,内存映射文件。然后根据刷盘策略刷写到磁盘,入口: CommitLog#putMessage handleDiskFlush CommitLog#handleDiskFlush public void handleDiskFlush(AppendMessageResult result, PutMessageResult putMessageResult, MessageExt messageExt) { // @1 // Synchronization flush if (FlushDiskType.SYNC_FLUSH == this.defaultMessageStore.getMessageStoreConfig().getFlushDiskType()) { // @2 final GroupCommitService service = (GroupCommitService) this.flushCommitLogService; if (messageExt.isWaitStoreMsgOK()) { GroupCommitRequest request

云原生|消息中间件的演进路线

三世轮回 提交于 2021-02-13 09:39:22
Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场,来谈谈云原生时代消息中间件的演进路线,但本文绝对不是“开局一张图,内容全靠编”。 从虚拟化技术诞生以来,IaaS/PaaS/SaaS 概念陆续被提了出来,各种容器技术层出不穷。到 2015 年, Cloud Native 概念应运而生,一时间,各种云厂商,云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考,传统的消息中间件需要做些什么才能加上云原生这个修饰词,这也是本文探讨的主题:传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生,云原生是一个天然适用于云计算的架构理念,实践云原生技术理念的应用可以最大化享受云计算的技术红利,包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素: 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施,是微服务架构应用的核心依赖,也是实践云原生的核心设计理念的关键技术,通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

云原生|消息中间件的演进路线

北城以北 提交于 2021-02-13 01:57:53
Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场,来谈谈云原生时代消息中间件的演进路线,但本文绝对不是“开局一张图,内容全靠编”。 从虚拟化技术诞生以来,IaaS/PaaS/SaaS 概念陆续被提了出来,各种容器技术层出不穷。到 2015 年, Cloud Native 概念应运而生,一时间,各种云厂商,云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考,传统的消息中间件需要做些什么才能加上云原生这个修饰词,这也是本文探讨的主题:传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生,云原生是一个天然适用于云计算的架构理念,实践云原生技术理念的应用可以最大化享受云计算的技术红利,包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素: 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施,是微服务架构应用的核心依赖,也是实践云原生的核心设计理念的关键技术,通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

云原生时代消息中间件的演进路线

笑着哭i 提交于 2021-02-13 01:45:53
简介: 本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》,主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 作者 | 周礼(不铭) 阿里巴巴集团消息中间件架构师 导读 :本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》,主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 引言 本文以一张云进化历史图开场,来谈谈云原生时代消息中间件的演进路线,但本文绝对不是“开局一张图,内容全靠编”。 从虚拟化技术诞生以来,IaaS / PaaS / SaaS 概念陆续被提了出来,各种容器技术层出不穷。到 2015 年,Cloud Native 概念应运而生,一时间,各种云厂商,云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考,传统的消息中间件需要做些什么才能加上云原生这个修饰词,这也是本文探讨的主题:传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 1. 什么是云原生 首先来谈谈什么是云原生,云原生是一个天然适用于云计算的架构理念,实践云原生技术理念的应用可以最大化享受云计算的技术红利,包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素: 采取 DevOps 领域的最佳实践来管理研发和运维流程; 通过 CICD

聊聊中间件开发

邮差的信 提交于 2021-02-10 16:49:44
最近频繁地在跟实习生候选人打交道,每次新接触一个候选人,都要花上一定的时间去介绍我们团队,候选人问的最多的一个问题就是「中间件部门一般是干嘛的?」,恰好我之前也接触过一些想从事中间件开发的小伙伴,问过我「现在转行做中间件开发还来得及吗?」诸如此类的问题,索性就写一篇文章,聊聊我个人这些年做中间件开发的感受吧。 什么是中间件开发? 我大四实习时,在一个 20 多人的软件开发团队第一次接触了中间件,当时项目的架构师引入了微博开源的 RPC 框架 Motan,借助于这个框架,我们迅速构建起了一个基于微服务架构的内部电商系统。接着在项目中,由于业务需求,我们又引入了 ActiveMQ...在这个阶段,我已经在使用中间件了,但似乎没有接触到中间件开发,更多的是使用层面上的接触。 我毕业后的第一份工作,公司有几百号研发,当时的 leader 看我对中间件比较感兴趣,有意把我分配在了基础架构团队,我第一次真正意义上成为了一名”中间件研发“,平时主要的工作,是基于开源的 Kong 和 Dubbo,进行一些内部的改造,以提供给业务团队更好地使用。这个阶段,做的事还是比较杂的,业务团队对某些中间件有定制化的需求,都需要去了解这个中间件,熟悉源码。这段时间,也是我成长最快的一个时期,我是在这个期间学会了 Docker、Neo4j、Kong 等以前从来没接触过的技术,并且更加深入地了解 Dubbo 这类

kafka rabbitMQ RockerMq 等消息中间件的对比 消息发送新能区别

删除回忆录丶 提交于 2021-02-08 12:59:53
kafka :Kafka是LinkedIn开源的分布式发布-订阅消息系统,目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输。0.8版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务。 RabbitMQ:是使用Erlang语言开发的开源消息队列系统,基于AMQP协议实现,主要特征是面向消息 队列 路由(点对点 和发布订阅)可靠性 安全性,对数据一致性 稳定性 高可靠行要求很高,对性能和 高吞吐量的要求次之 RocketMQ阿里的开源中间件,是纯Java开发,具有高吞吐量高可用性适合大规模分布式系统的应用特点,思路起源于kafka单并非完全copy kafka,在我看来是对消息的靠靠性以及事务性做了优化 测试目的 对比Kafka、RabbitMQ、RocketMQ发送小消息(124字节)的性能。这次压测我们只关注服务端的性能指标,所以压测的标准是: 不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。这时服务端已出现性能瓶颈,可以获得相应的系统最佳吞吐量。 测试场景 在同步发送场景中,三个消息中间件的表现区分明显: Kafka的吞吐量高达17.3w/s,不愧是高吞吐量消息中间件的行业老大