Apache RocketMQ

021. 分布式消息中间件设计篇

风格不统一 提交于 2020-10-06 02:01:31
1. 单体架构 2. 分布式系统架构 3. 基于消息中间件的分布式系统架构 4. 消息中间件概述 1. 什么是消息中间件 利用高效可靠的消息传递机制进行平台无关的数据交流。 并基于数据通信来进行分布式系统的集成。 通过提供消息传递和消息排队模型,它可以在分布式环境下扩展进程间的通信。 2. 消息中间件的应用场景 跨系统数据传递。 高并发流量削峰。 数据异步处理。 ... 3. 常用的消息中间件 ActiveMQ RabbitMQ Kafka RocketMQ 5. 消息中间件核心设计 1. 本质 一种具有接收数据、保存数据、发送数据等功能的网络应用。 和一般网络应用程序的区别是它主要负责数据的接收和传递,所以性能一般都高于普通程序。 2. 5 大核心组成 协议 持久化机制 消息分发机制 高可用设计 高可靠设计 6. 协议 1. 协议是什么 协议是计算机之间通信时共同遵守的一组约定,都遵守相同的约定,计算机之间才能相互交流。 是对数据格式和计算机之间交互数据时必须遵守的规则的正式描述。 协议三要素: 语法:即数据与控制信息的结构或格式; 语义:即需要发出何种控制信息,完成何种动作以及做出何种响应; 时序(同步):即事件实现顺序的详细说明。 2. 常见协议 HTTP 三要素举例: 语法:http 规定了请求报文和响应报文的具体格式。 语义:客户端主动发起的操作称为请求。 时序

汽车产业云上多地域高可用消息系统的构建

怎甘沉沦 提交于 2020-10-04 05:00:30
汽车产业互联网平台大搜车由姚军红创立于2012年12月,先后获得阿里巴巴集团、蚂蚁金服、晨兴资本、华平投资、春华资本等机构超过12亿美元融资。2017年12月,大搜车列入由硅谷全球数据研究机构PitchBook评选的“2017年全球新晋独角兽”名单。 目前,大搜车已经搭建起比较完整的汽车产业互联网协同生态。随着业务业务的快速发展,大搜车遇到了一系列的问题: 大量微服务系统,总数在2000以上,这些系统之间的异步通信全部都需要通过消息队列MQ,导致消息量大幅增加,日均消息TPS在6000以上,消息系统的稳定性成为云上业务稳定保障的重中之重。 由于有杭州和北京两大研发中心,客户在杭州和北京都部署了大量业务系统,多地域应用的消息同步需要有稳定可靠的机制。 物联网设备的管理和接入对消息系统提出了更高的要求。 大数据领域大量应用Kafka,需要更稳定可靠的商业版Kafka产品,减少运维工作量。 为了更好地支撑业务,大搜车利用云上MQTT+消息队列RocketMQ+全球消息路由+消息队列Kafka构建了完整的云上消息系统。 通过全球消息路由功能将杭州地域的消息同步到北京地域,做到业务分地区就近部署。 独立消息队列实例管理不同业务,可用性更高。 利用消息队列Kafka对接大数据生态,即开即用,快速扩容,可靠性更高。物联网设备通过MQTT进行接入,后台开发物联网设备管理平台,通过MQTT连接设备端

来千寻三个月感受

元气小坏坏 提交于 2020-10-03 06:54:09
自6月3日入职后,到今天已经快3个月了,此时窗外蒙蒙细雨,感触颇多,写下此篇,为总结,为记录 首先先简单介绍下千寻(位于上海),不是千与千寻哦,千寻位置主要是基于北斗卫星提供高精度定位的,平时工作996很少,基本上985,福利待遇可以与其它大厂看齐,工作上与之前公司差别蛮大,我上家965,来这之前已经做好了996心里准备,公司用的技术为dubbo、RocketMq这些,基本为市面上常见的技术框架。并发也挺大,毕竟华为P40已经接入我们公司高精度定位服务,公司的大牛很多,同事也不错,对我的帮助也蛮多,很幸运能进入这家公司。时间过的真快,除了工作上的忙碌,业余时间也看了一丢丢书,记录下吧,希望大家一起加油学习呀 领导的一些思维值得学习: 1.做这件事体现了你哪些能力,工作基本都能完成,你做了那些不同的地方,你的能力如何体现 2.要善于输出,抛出自己的想法,不管能不能推进,至少要有自己的想法 3.要量化,最好体现在具体数据上,具体数据的变化背后的原因 顺便说下读的书吧,俗话说人丑多读书,高富帅与我无缘, 《Vue.js快跑》 刚入职时负责的项目需要前端后端都做,前端用VUE,自己之前只会点JS、HTML,然后便读了这本书,这本书讲述的是VUE基础,容易上手 《硅谷钢铁侠:埃隆·马斯克冒险的人生》 讲述马斯克传奇的人生,PayPal的创始人、卖掉PayPal后赚了2亿多美元

2020java面试总结

…衆ロ難τιáo~ 提交于 2020-10-02 08:02:08
博主背景:92年生,渣本毕业,java岗,经验接近6年,base上海 本文宗旨:本文旨在将博主最近的面试经历分享给大家,并作些总结,尽量为在准备面试的同学缩小面试准备的范围,或者至少让同学们知道现在企业都问些啥,以及一些面试的注意事项,希望对你有参考作用 本次面试情况:2020年7月中开始,持续3周多时间,面了13家,2家没过,1家意外,10家通过,如下: 1) 拍拍贷 ,业务岗资深技术专家+基础架构部资深技术专家,技术五面(这家经历比较特殊,两个岗位都通过了,所以技术面了5轮) 2) 平安普惠金融 ,职级C2,技术三面(通过) 3) 微众银行 ,技术两面(通过),博主现在的东家. 4) 北京什么值得买 ,架构师岗(一面没过) 5) soul ,高级java,技术三面(通过) 6) 多点small ,技术三面(通过) 7) 萨摩耶数科 ,技术三面(通过) 8) 中国电信 ,云计算部门,技术三面(挂在技术三面) 9) 哈罗单车 ,技术两面(通过) 10) 蚂蚁金服 ,国际事业群(就是出了意外的那家.....技术一面+做题,当场面试官反馈通过,第二天出了幺蛾子,说是我们公司算他们资方,不能招,我当然认为是扯淡,后续跟猎头了解到,蚂蚁对资方企业的员工简历有几个月的冷冻期,非常遗憾,没见识到蚂蚁面试官的厉害...) 11) 饿了么 ,风控部门,职级P7(饿了么P7只能对标阿里P6,P6+)

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

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

技术沙龙|实力赋能开发者,助力企业从容应对数字化转型难题

依然范特西╮ 提交于 2020-10-01 19:21:34
今日,移动云TeaTalk·上海站,移动云2020年首场线下技术专场沙龙,在上海圆满结束。 近几年,云原生成为科技圈热词,应用范围逐步由互联网拓展至传统行业。中国移动云能力中心特此举办专场沙龙,围绕“Serverless、Kubernetes、消息服务”等云原生技术,助力开发者和企业从多维度理解云原生的技术基础与应用场景。会上还涉及移动云云原生产品规划、开发者社区、创客马拉松专题赛,以及云计算与大数据和创空间等内容介绍。 全链条规划 做懂用户、懂服务商的云原生产品 会上,中国移动云能力中心IaaS产品部总经理刘军卫表示,中国移动始终 站在用户、云服务商的角度理解云原生。 移动云云原生具备 开发者友好、多人协作、维护简单 等易用特性,产品丰富可一站式满足 互联网应 用、企业应 用、新型业务 等典型用户需求。移动云从IaaS产品线、容器策略、用户友好性等全链条进行云原生产品规划,对内加强产品“内功”,对外提供更优质服务。 中国移动云能力中心IaaS产品部总经理 刘军卫 从0到1,理解和运用serverless 降低成本、提升效率是云服务追求的目标之一,serverless应运而生——由云服务商提供主机管理、操作系统管理、资源分配等服务,用户可按需购买,开发者可专注产品代码编写本身。 移动云函数计算(基于事件驱动、自动伸缩、空闲时资源释放、代码镜像制作、对象存储、Redis触发器

北漂女程序员工作7年来面试要价26K,该不该要她?

戏子无情 提交于 2020-09-30 12:04:05
话说: 前段时间面试了一位程序媛,差不多下午3点左右来我们部门面试,于是老板喊人接待了她,我们来简单看看这位程序媛的简历吧。 提前说明这篇文章只是为了帮助大家应聘时应该注意哪些问题,可以跟自己的简历对比下,找找差距,也是帮助大家。 简历 姓名:张xx 性别:女 出生日期:1992年6月 民族:汉 籍贯:山东 工作意向:Java开发 教育背景:西安电子科技大学 软件xx专业 至于邮箱和QQ,电话这些,就不透露了。 个人技能 ● 熟悉spring mvc 、spring、mybatis 等框架 ● 熟悉 redis 、rocketmq、dubbo、zookeeper、netty 、nginx、tomcat、mysql。 ● 阅读过juc 中的线程池、锁的源码以及netty 中的主从多线程源码。 ● 了解 spring boot、spring cloud 、elasticsearch 、kafka 等。 ● 了解jvm 的内存模型、类加载机制等相关知识 整理了2020年最新大厂面试题。 链接: 点这个,点这个。 暗号:csdn,加入即得。 项目经验 xx系统 系统为银行客户提供优惠买单功能,激发银行各类卡用户的消费活跃度,以及通过优惠买单为银行拓展新的用户等。系统主要包括商户管理、订单管理、 用户管理、库存管理等子系统。(ssm 、dubbo 、rocketmq、redis、jdk1.7

分布式事务解决方案常见误区与实用建议

ぐ巨炮叔叔 提交于 2020-09-30 06:41:34
前言 ​ 最近,工作中要为现在的老系统做拆分和升级,刚好遇到了分布式事务、幂等控制、异步消息乱序和补偿方案等问题,刚好基于实践结合个人的看法记录一下一些方案和思路。 分布式事务 首先,做系统拆分的时候几乎都会遇到分布式事务的问题,一个仿真的案例如下: 项目初期,由于用户体量不大,订单模块和钱包模块共库共应用(大war包时代),模块调用可以简化为本地事务操作,这样做只要不是程序本身的BUG,基本可以避免数据不一致。 后面因为用户体量越发增大,基于容错、性能、功能共享等考虑,把原来的应用拆分为订单微服务和钱包微服务,两个服务之间通过非本地事务操(这里可以是HTTP或者消息队列等)作进行数据同步,这个时候就很有可能由于异常场景出现数据不一致的情况。 事务中直接RPC调用达到强一致性 以上面的订单微服务请求钱包微服务进行扣款并更新订单状态为扣款这个调用过程为例,假设采用HTTP同步调用,项目如果由经验不足的开发者开发这个逻辑,可能会出现下面的伪代码: [订单微服务请求钱包微服务进行扣款并更新订单状态] 处理订单微服务请求钱包微服务进行扣款并更新订单状态方法(){ [开启事务] 1、查询订单 2、HTTP调用钱包微服务扣款 3、更新订单状态为扣款成功 [提交事务] } 这是一个从肉眼上看起来没有什么问题的解决方法,HTTP调用直接嵌入到事务代码块内部,猜想最初开发者的想法是

从 BIO、NIO 聊到 Netty,最后还要实现个 RPC 框架!

流过昼夜 提交于 2020-09-30 06:04:57
大家好,我是 「后端技术进阶」 作者,一个热爱技术的少年。 文章目录 还是要从 BIO 说起 传统的阻塞式通信流程 一个简单的 demo 资源消耗严重的问题 线程池虽可以改善,但终究未从根本解决问题 再看 NIO 初识 NIO NIO 核心组件解读 NIO 为啥更好? 使用 NIO 编写代码太难了 重要角色 Netty 登场 Netty 特点 使用 Netty 能做什么? 哪些开源项目用到了 Netty? 后记 觉得不错的话,欢迎 star!ღ( ´・ᴗ・` )比心 Netty 从入门到实战系列文章地址: https://github.com/Snailclimb/netty-practical-tutorial 。 RPC 框架源码地址: https://github.com/Snailclimb/guide-rpc-framework 老套路,学习某一门技术或者框架的时候,第一步当然是要了解下面这几样东西。 是什么? 有哪些特点? 有哪些应用场景? 有哪些成功使用的案例? … 为了让你更好地了解 Netty 以及它诞生的原因,先从传统的网络编程说起吧! 还是要从 BIO 说起 传统的阻塞式通信流程 早期的 Java 网络相关的 API( java.net 包) 使用 Socket(套接字)进行网络通信,不过只支持阻塞函数使用。 要通过互联网进行通信,至少需要一对套接字:

消息队列之事务消息,RocketMQ 和 Kafka是如何做的?

放肆的年华 提交于 2020-09-29 07:03:24
作者 | 是Yes呀 责编 | 郑丽媛 来源 | yes的练级攻略(ID:yes_java ) 每个时代,都不会亏待会学习的人。 大家好,我是 yes。 今天我们来谈一谈消息队列的事务消息,一说起事务相信大家都不陌生,脑海里蹦出来的就是 ACID。 通常我们理解的事务就是为了一些更新操作要么都成功,要么都失败,不会有中间状态的产生,而 ACID 是一个严格的事务实现的定义,不过在单体系统时候一般都不会严格的遵循 ACID 的约束来实现事务,更别说分布式系统了。 分布式系统往往只能妥协到最终一致性 ,保证数据最终的完整性和一致性,主要原因就是实力不允许...因为可用性为王。 而且要保证完全版的事务实现代价很大,你想想要维护这么多系统的数据,不允许有中间状态数据可以被读取,所有的操作必须不可分割,这意味着一个事务的执行是阻塞的,资源是被长时间锁定的。 在高并发情况下资源被长时间的占用,就是致命的伤害,举一个有味道的例子,如厕高峰期,好了懂得都懂。 对了, ACID是什么还不太清楚的同学,赶紧去查一查,这里我就不展开说了。 分布式事务 那说到分布式事务,常见的有 2PC、TCC 和事务消息,这篇文章重点就是事务消息,不过 2PC 和 TCC 我稍微提一下。 2PC 2PC就是二阶段提交,分别有协调者和参与者两个角色,二阶段分别是准备阶段和提交阶段。