消息中间件

从初代开源音讯队列崛起，到 PC 互联网、挪动互联网爆发式倒退，再现在 IoT、云计算、云原生引领了新的技术趋势，消息中间件的倒退曾经走过了 30 多个年头。 目前，消息中间件在国内许多行业的要害利用中扮演着至关重要的角色。随着数字化转型的深刻，客户在应用音讯技术的过程中往往同时波及穿插场景，比方同时进行物联网音讯、微服务音讯的解决，同时进行利用集成、数据集成、实时剖析等，企业须要为此保护多套音讯零碎，付出更多的资源老本和学习老本。 在这样的背景下，2022 年，RocketMQ 5.0 的正式版正式公布，绝对于 RocketMQ 4.0，架构走向云原生化，并且笼罩了更多的业务场景。想要把握最新版本 RocketMQ 的利用，就须要进行更加体系化的深刻理解。 基于此，阿里云音讯产品线负责人、Apache RocketMQ PMC Member 林清山老师（花名：隆基） 为你深刻分析 RocketMQ 5.0 的外围原理，分享不同场景下的最佳实际。 课程分为两个模块。 第一模块：外围探索 回顾 RocketMQ 的诞生背景和倒退历程，带你理解 RocketMQ 5.0 诞生背地云原生、IoT、实时数据等等的场景诉求，从整体技术架构上学习 RocketMQ 5.0 的云原生架构、一体化架构，把握音讯服务背地的外围原理。 第二模块：场景拆分 从业务场景切入，具体介绍 RocketMQ5.0 在不同的业务场景提供的能力和关键技术原理，包含业务音讯、流解决、物联网以及面向云时代的事件驱动场景。 课程会构建你对 RocketMQ5.0 的全新认知，更对以后时代背景下的音讯诉求有更粗浅的了解。课程可收费支付，欢送大家报名学习。 课程信息 讲师介绍： 林清山（花名：隆基），Apache RocketMQ 联结创始人，阿里云资深技术专家，阿里云音讯产品线负责人。国内音讯领域专家，致力于音讯、实时计算、事件驱动等方向的钻研与摸索，推动 RocketMQ 云原生架构、超交融架构的演进。 适宜人群： 1-5 年后端开发人员 极客工夫地址： https://time.geekbang.org/opencourse/videointro/100546401 阿里云开发者社区地址： https://developer.aliyun.com/learning/course/1257

本文作者：李伟，社区里大家叫小伟，Apache RocketMQ Committer，RocketMQ Python客户端我的项目Owner ，Apache Doris Contributor，腾讯云RocketMQ开发工程师。 最近忽然感觉：很多软件、硬件在设计上是有root reason的，不是by desgin如此，而是解决了那时、那个场景的那个需要。一旦理解后，就会感觉在和设计者对话，理解他们的思路，学习他们的办法，思维同屏：活到老学到老。 1大家思考 1.1 Consumer Queue Offset是间断的吗， 为什么？ 1.2 Commit Log Offset是间断的吗， 为什么？ 1.3 Java写的文件，默认是大端序还是小端序，为什么？ 2Commit Log实在散布 在大家思考之际， 咱们回忆下commit log是怎么散布的呢? 在Broker配置的存储根目录下，通过查看Broker理论生成的commit log文件能够看到相似上面的数据文件散布： Broker实在数据文件存储散布 能够看到，实在的存储文件有多个， 每一个都是以一串相似数字的字符串作为文件名的，并且大小1G。 咱们联合源码能够晓得，理论的形象模型如下： Commit Log存储文件散布形象 由上图得悉： Commit Log是一类文件的称说，实际上Commit Log文件有很多个， 每一个都能够称为Commit Log文件。如图中示意了总共有T个Commit Log文件，他们依照由过来到当初的创立工夫排列。 每个Commit Log文件都保留音讯， 并且是依照音讯的写入程序保留的，并且总是在写创立工夫最大的文件，并且同一个时刻只能有一个线程在写。 如图中第1个文件，1，2，3，4...示意这个文件的第几个音讯，能够看到第1234个音讯是第1个Commit Log文件的最初一个音讯，第1235个音讯是第2个Commit Log的第1个音讯。 阐明1：每个Commit Log文件里的全副音讯理论占用的存储空间大小<=1G。这个问题大家自行思考下起因。 阐明2：每次写Commit Log时， RocketMQ都会加锁，代码片段见https://github.com/apache/rocketmq/blob/7676cd9366a3297925deabcf27bb590e34648645/store/src/main/java/org/apache/rocketmq/store/CommitLog.java#L676-L722 append加锁 咱们看到Commit Log文件中有很多个音讯，依照既定的协定存储的，那具体协定是什么呢， 你是怎么晓得的呢？ 3Commit Log存储协定 对于Commit Log存储协定，咱们问了下ChatGPT， 它是这么回复我的，尽管不对，然而这个回复格局和阐明曾经十分靠近答案了。 ChatGPT回复 咱们翻看源码，具体阐明下：https://github.com/apache/rocketmq/blob/rocketmq-all-4.9.3/store/src/main/java/org/apache/rocketmq/store/CommitLog.java#L1547-L1587 ...

本文作者：周波，阿里云智能高级开发工程师， Apache RocketMQ Committer 。 01 从问题中来的RocketMQ Connect 在电商零碎、金融零碎及物流零碎，咱们常常能够看到 RocketMQ 的身影。起因不难理解，随着数字化转型范畴的扩充及过程的放慢，业务零碎的数据也在每日暴增，此时为了保证系统的稳固运行，就须要把运行压力分担进来。RocketMQ就负责着这样的角色，它的异步音讯解决与高并发读写能力，决定了零碎底层的重构不会影响下层利用的性能。而RocketMQ的另一个劣势——可伸缩能力，使零碎在面临流量的不确定性时，实现对流量的缓冲解决。此外，RocketMQ的程序设计个性使其成为一个人造的排队引擎，例如，三个利用同时对一个后盾引擎发动申请，确保不引起“撞车”事变。因而，RocketMQ被用在异步解耦、削峰填谷以及事务音讯等场景中。 然而，数字化转型浪潮也带来了更多用户对数据价值的关注——如何让数据产生更大利用价值？RocketMQ本身不具备数据分析能力，然而有不少用户心愿从 RocketMQ Topic 中获取数据并进行在线或离线的数据分析。然而，应用市面上的数据集成或数据同步工具，将 RocketMQ Topic 数据同步到一些剖析零碎中尽管是一种可行计划，却会引入新的组件，造成数据同步的链路较长，时延绝对较高，用户体验不佳。 举个例子，假如业务场景中应用 OceanBase 作为数据存储，同时心愿将这些数据同步到 Elasticsearch进行全文搜寻，有两种可行的数据同步计划。 计划一：从 OceanBase 中获取数据，写入 Elasticsearch组件并进行数据同步，在数据源较少时此计划没什么问题，一旦数据增多，开发和保护都非常复杂，此时就要用到第二种计划。 计划二：引入消息中间件对上下游进行解藕，这能解决第一种计划的问题，然而一些较为简单的问题还没有齐全解决。比方，如何将数据从源数据同步到指标零碎并保障高性能，如果保障同步工作的局部节点挂掉，数据同步仍然失常进行，节点复原仍然能够断点续传，同时随着数据管道的增多，如何治理数据管道也变得十分困难。 总的来说，数据集成过程中的挑战次要有五个。 挑战一： 数据源多，市面上可能有上百个数据源，且各数据源的零碎差别较大，实现任意数据源之间的数据同步工作量较大，研发周期很长。 挑战二： 高性能问题，如何高效地从源数据系统同步到目标数据系统，并保障其性能。 挑战三： 高可用问题，即Failover能力，当一个节点挂掉是否这个节点的工作就进行了，工作重新启动是否还能够断点续传。 挑战四： 弹性扩缩容能力，依据零碎流量动静减少或缩小节点数量，既能通过扩容满足高峰期业务，也能在低峰期缩减节点，节省成本。 挑战五： 数据管道的治理运维，随着数据管道的增多，运维监控的数据管道也会变得越来越简单，如何高效治理监控泛滥的同步工作。 面对上述挑战 RocketMQ 如何解决？ 第一，标准化数据集成 API （Open Messaging Connect API）。在 RocketMQ 生态中减少 Connect 组件，一方面对数据集成过程形象，形象规范的数据格式以及形容数据的 Schema，另一方面对同步工作进行形象，工作的创立、分片都形象成一套标准化的流程。 第二，基于规范的 API 实现 Connect Runtime。Runtime提供了集群治理、配置管理、位点治理、负载平衡相干的能力，领有了这些能力，开发者或者用户就只须要关注数据如何获取或如何写入，从而疾速构建数据生态，如与OceanBase、MySQL、Elasticsearc等疾速建设连贯，搭建数据集成平台。整个数据集成平台的构建也非常简单，通过 Runtime 提供的 RESTFull API 进行简略调用即可。 第三，提供欠缺的运维工具，方便管理同步工作，同时提供丰盛的Metrics 信息，不便查看同步工作的TPS，流量等信息。 02 RocketMQ Connect 两大应用场景 ...

自建MQTT迁徙IoT物联网平台实战前言随着业务增长，自建MQTT集群保护老本越来越高，连贯稳定性，音讯时延一直遇到下层业务挑战，迁徙阿里云IoT物联网平台是十分理智的最佳抉择。 现有业务背景企业基于自建MQTT集群的数据交互如下图：设施端publish业务数据到MQTT集群，流转到后端业务服务器解决；业务服务器把指令公布到MQTT集群，触达到设施端。具体业务数据定义如下： 架构计划当咱们从本人MQTT集群迁徙到IoT物联网平台，咱们能够采纳以下技术计划，实现低成本的疾速迁徙，缩小设施端和业务零碎的革新。 IoT设施迁徙上云三步走： 设施做固件降级，批改接入域名为IoT平台Endpoint调整现有通信topic为IoT物联网平台产品自定义Topic配置规定引擎，把设施数据流转到服务端订阅AMQP生产组，业务服务器实时接管到设施数据设施迁徙上云实战创立产品首先，咱们接入物联网平台控制台，左侧栏抉择产品，创立新产品：充电宝机柜。如下图： 所属品类：自定义品类节点类型：直连设施连网形式：WiFi （这里能够依据理论状况抉择）数据格式：ICA 规范数据格式 JSON（这里也能够选 透传/自定义）而后，把现有零碎业务Topic映射到自定义通信的Topic类，如下表：最初，咱们接入产品详情，抉择Topic类列表，点击自定义Topic，增加Topic如下图：至此，咱们实现了在IoT物联网平台的产品创立和通信定义。 注册设施咱们基于产品，创立一个具体设施，获取到设施身份认证信息（三元组），如下图： 数据流转配置当咱们创立实现产品，注册好设施之后，就须要在IoT平台配置数据流转计划了。 服务端订阅AMQP生产组首先，咱们要在控制台的服务端订阅，创立咱们充电宝业务的AMQP生产组，用来生产设施生成的数据。如下图：而后，咱们进入生产组详情，查看生产组状态。因为咱们设施端和服务端都没有连贯到平台，数据都是为空。如下图：规定引擎接下来咱们要做的是配置规定引擎解决数据，并流转到已创立的生产组上。咱们抉择云产品流转，点击创立规定，抉择二进制格局（二进制泛指非JSON构造数据）。如下图：而后，咱们编写SQL，让IoT物联网平台解决设施数据，并携带设施信息。如下图： SELECT deviceName() as deviceName,timestamp() as timestamp ,payload() as payload FROM "/a********E/+/user/data/up"接下来，咱们增加数据转发操作到指定的AMQP生产组，如下图：残缺的规定引擎配置如下图所示：最初，咱们在规定引擎列表，启动规定。如下图： 设施开发在实现了云上控制台的配置工作后，咱们要做的就是设施端业务开发。这里咱们在Mac上用nodejs脚本模仿设施业务行为，设施MQTT连贯，数据上报，指令接管。残缺代码如下： // 引入依赖mqtt库，或本人实现const mqtt = require('aliyun-iot-mqtt');// 设施身份var options = { productKey: "设施pk", deviceName: "设施dn", deviceSecret: "设施ds", regionId: "cn-shanghai"};// 1.建设连贯const client = mqtt.getAliyunIotMqttClient(options);// 2.设施接管云端指令数据client.on('message', function(topic, message) { console.log("topic " + topic) console.log("message " + message)})// 3. 设施订阅指令的Topicclient.subscribe(`/${options.productKey}/${options.deviceName}/user/cmd/down`)// 4. 模仿设施 上报数据（原始报文）setInterval(function() { client.publish(`/${options.productKey}/${options.deviceName}/user/data/up`, getPostData(),{qos:1});}, 1000);// 模仿 设施原有报文格式function getPostData() { let payload = "DE02,"+Math.floor((Math.random() * 20) + 10) +","+Math.floor((Math.random() * 20) + 10) +",011101010,am024,1d478f"; console.log("payload=[ " + payload+" ]") return JSON.stringify(payload);}至此，咱们实现了设施端业务开发。 ...

IoT物联网平台20条实用手册查看账号的阿里云UID传送门 ：https://account.console.aliyu...查看通信的Topic传送门 ：https://iot.console.aliyun.com产品性能定义应用传送门 ：https://iot.console.aliyun.com 查看上行数据Topic和Payload详情上行数据流转时延排查能够通过指定deviceName和时间段排查规定引擎+AMQP生产组流转排查设施网络时延检测8. 物模型JSON属性上报日志9. 上行控制指令消息日志 QoS=1同步RRPC调用日志排查设施高低线行为查看物模型二进制解析过程日志实时监控查看实时在线设施发送到平台的音讯量  平台收回的音讯量规定引擎音讯流转次数设施身份三元组查看获取阿里云账号accessKey网络UIS控制台流量监控https://uis.console.aliyun.com/通过pop api获取数据https://api.aliyun.com/?#/?pr...服务端订阅AMQP生产状况规定引擎+AMQP流转日志①设施上报数据到IoT平台②IoT平台流转规定引擎解决数据③规定引擎解决后流转目的地：AMQP生产组④IoT平台随机推送音讯到一个AMQP生产端⑤企业AMQP生产端回复ack到IoT平台自定义Topic数据解析脚本日志增加设施标签物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

1.概述随着新型冠状病毒疫情倒退，社区居家隔离成为无效伎俩，而体温排查是社区工作的重中之重！借助IoT物联网技术能够不便的实现居民体温实时监控和历史数据的残缺追溯。 2.技术架构计划基于稳定性，高并发，低时延的考量咱们抉择阿里云IoT物联网平台搭建整套零碎。首先手持测温枪通过蓝牙连贯到DTU模块，DTU模块以MQTT协定接入物联网平台。数据上云后，通过规定引擎流转服务端订阅的AMQP生产组，实时推送到咱们业务服务器。管理人员应用手机小程序即可实时看到出入人员的体温数据。 3.云端开发3.1 产品创立进入物联网平台控制台，创立产品。 在产品详情Topic列表，减少用于数据传输的Topic，如下： 3.2 注册设施产品定义好后，咱们基于这个产品创立一个具体设施，获取到设施身份三元组。 3.3 创立生产组接下来，咱们要在服务端订阅创立用来接收数据的生产组，查看下图： 3.4 配置规定引擎最初，咱们通过规定引，把设施上报的数据做业务解决后，流转到咱们服务器的生产组，从而实现企业本人的设施采集的业务数据达到企业本人的后盾服务器的流转过程。 4.设施开发在实现了云上控制台的配置工作后，咱们要做的就是设施端业务开发。这里咱们在Mac上用nodejs脚本模仿设施业务行为，设施MQTT连贯，数据上报。残缺代码如下： // 引入依赖mqtt库，或本人实现const mqtt = require('aliyun-iot-mqtt');// 设施身份var options = { productKey: "设施pk", deviceName: "设施dn", deviceSecret: "设施ds", regionId: "cn-shanghai"};// 1.建设连贯const client = mqtt.getAliyunIotMqttClient(options);// 2.设施接管云端指令数据client.on('message', function(topic, message) { console.log("topic " + topic) console.log("message " + message)})// 3. 模仿设施 上报数据（原始报文）setInterval(function() { client.publish(`/${options.productKey}/${options.deviceName}/user/data`, getPostData(),{qos:1});}, 1000);// 模仿 设施原有报文格式function getPostData() { let payload = { temperature:Math.floor((Math.random() * 20) + 10) }; console.log("payload=[ " + payload+" ]") return JSON.stringify(payload);}至此，咱们实现了设施端业务开发。 ...

华南1(深圳) 物联网平台实例化开发实战明天，阿里云IoT物联网平台在华南1(深圳)节点正式上线！对于华南地区的设施接入延时能够做到<10ms，比跨地区接入延时缩小了3倍以上，同时反对通过规定引擎接入其余阿里云产品。 10毫秒是什么概念？这么说吧，咱们每次实现眨眼的动作须要... 100毫秒的工夫... 根本业务链路   按需开明实例    咱们登录IoT物联网控制台，在左上角，切换到华南1(深圳)节点，即可在华南创立IoT物联网平台实例，如下图： 在实例规格页面的地区和可用区，抉择华南1(深圳)节点，其余规格能够依据理论业务状况抉择，如下图： 在线领取后，稍等几分钟，实例初始化实现。 在实例设置页面，咱们能够切换实例，查看实例MQTT，CoAP，HTTP，AMQP，云端API的接入点信息，以及VPC内网接入点信息。   设施接入实战    咱们以冷链运输追踪器为例，实现IoT设施接入华南1节点的开发实战。 1.创立产品和设施在实例中，咱们创立产品，抉择直连设施，以设施秘钥形式认证身份。 在产品详情的Topic类列表创立用于业务通信的Topic，具体如下图： 而后，咱们注册一个设施。在设施详情，能够看到设施处于未激活，区域为华南1（深圳）。 2.配置业务数据流转规定首先，咱们创立服务端订阅生产组，用来生产设施产生的业务数据，如下图： 而后，咱们配置规定引擎，把数据流转到刚刚创立的生产组，如下图：    开发编码   3.设施端开发咱们以Nodejs为例，设施接入代码残缺过程，如下： const mqtt = require('aliyun-iot-mqtt');var options = { productKey: "xxxxx", deviceName: "xxxx", deviceSecret: "xxxxxxxx", host: "iot-cn-xxxxx.mqtt.iothub.aliyuncs.com"};// 1. 建设连贯const client = mqtt.getAliyunIotMqttClient(options);// 2. 监听云端指令client.subscribe(`/${options.productKey}/${options.deviceName}/user/config`)client.on('message', function(topic, message) { console.log("topic " + topic) console.log("message " + message)})setInterval(function() { // 3.上报车厢数据 client.publish(`/${options.productKey}/${options.deviceName}/user/data/post`, getPostData(), { qos: 0 });}, 1000);function getPostData() { const payloadJson = { temperature: Math.floor((Math.random() * 20) + 10), humidity: Math.floor((Math.random() * 20) + 10), speed: Math.floor((Math.random() * 20) + 30), } console.log("payloadJson " + JSON.stringify(payloadJson)) return JSON.stringify(payloadJson);}4.服务端AMQP订阅实例化下AMQP的接入域名： ...

随着Apache RocketMQ 被越来越多用于各行业所应用，广泛应用于异步解耦、数据同步、削峰填谷等场景中，帮忙企业或个人用户解决辣手问题。 为了更好的反哺开源社区，让这些实际案例被更多社区开发者看到，分享应用过程中的成功经验与踩坑经验，为老手和用户提供牢靠参考，Apache RocketMQ社区发动「优良实际案例征集」流动，激励大家将本人的实践经验分享进去。 获选「优良实际案例」的选手不仅能取得社区纪念品，还有机会被举荐加入 RocketMQ Summit、 ApacheCon，取得向海量开发者分享本人的见解！ 01流动详情 流动主题：Apache RocketMQ 优良实际案例征集流动工夫：2023 年 2 月 7 日-2023 年 9 月 30 日参加形式：在提交案例截止日期之前，提交文档至邮箱 baiyu.gxf@alibaba-inc.com，文件格式Word、Markdown、在线文档均可；邮件格局：用户案例+企业名称/集体姓名；审核通过后将收到社区邮件告诉，优良案例在社区公众号、InfoQ、CSDN等不同技术渠道公布；案例提交人将在流动后果公示后取得社区纪念品；提交案例截止工夫：2023 年 9 月 30 日 24:00提交案例要求：企业名称/集体姓名曝光：文中需写明应用 Apache RocketMQ 的企业名称，集体案例不要求公开姓名。企业案例公开公布需取得企业受权，提交案例前请确认已取得企业批准；内容格局：需至多包含【问题阐明】、【解决方案】、【后果阐明】相干内容，字数 1000-3000 字，激励技术详解；因为用户案例撰写、审核和评审比拟耗时，揭示大家早做布局，纪念品无限，尽快动笔开始撰写哦！后果公示：2023 年 10 月02流动处分 「优良实际案例」取得社区周边纪念品，如社区定制鲁班锁、帽衫等纪念品；获举荐加入 RocketMQ Summit、 ApacheCon、RocketMQ社区沙龙。 03口头起来！ 流动曾经开始，入手写下本人的实际经验，分享并帮忙更多有须要的开发者吧！ 案例提交: baiyu.gxf@alibaba-inc.com

业务数据流程我的传感设施，IoT平台，业务服务器，App之间是什么关系？ 上行数据链路：·设施以MQTT协定建设和 IoT 物联网平台的长连贯，异步PUBLISH数据（Topic和Payload）到 IoT 平台·IoT 平台依据配置的规定引擎，解决数据后，流转到 数据库DB，音讯队列MQ，函数计算FC 或者 通过AMQP协定流转到你的ECS服务器上 上行数据链路：·ECS服务器程序调用HTTPS的Pub API，发送数据到 IoT 平台·IoT 平台通过MQTT协定，PUBLISH数据到设施端（指定Topic和Payload） FAQ1.为什么设施无奈上报数据？您须要先定义具备公布权限的通信Topic 2.为什么设施无奈接收数据？您须要先定义具备订阅权限的通信Topic，并且设施被动subscribe此通信Topic定义Topic设施订阅Topic胜利 3.设施肯定要事后烧录三元组吗？不须要，参考这个计划 https://developer.aliyun.com/... 4.接入电信NB-IoT设施能对接到阿里云IoT吗？能够，参考这个计划https://developer.aliyun.com/...! 5.存量设施，不降级革新，能对接到阿里云IoT吗？能够，参考这个计划https://developer.aliyun.com/... 6.设施上线/离线日志链路：设施→IoT平台(上线)、设施→IoT平台(离线) 7.物模型-属性上报处理过程的日志音讯链路：设施→IoT平台→物模型校验→物模型数据存储 8.自定义音讯规定引擎流转音讯链路：设施→IoT平台→规定引擎→服务端订阅AMQP→业务服务器ECS→服务端订阅AMQP(ACK响应) 9.上行控制指令日志音讯链路：业务服务器ECS(Pub API)→IoT平台(Publish)→设施→IoT平台(PubAck响应) 10.公有协定脚本解析解决日志音讯链路：设施→IoT平台→自定义协定脚本解析→规定引擎→服务端订阅AMQP 【往期回顾】1.自建MQTT集群迁徙阿里云IoT平台https://mp.weixin.qq.com/s?sp...2.IoT时代：WiFi配网技术分析https://mp.weixin.qq.com/s?sp...3.微信小程序和IoT智能家居实际https://mp.weixin.qq.com/s?sp...4.IoT云端通用数据解析脚本实际https://mp.weixin.qq.com/s?sp... 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

简介：阿里云云原生 阿里云音讯队列MNS定位是RocketMQ轻量版，提供轻量模型、轻量 HTTP RESTful 协定，运维轻量、计费轻量，具备易集成等特点。阿里云云原生 阿里云音讯队列MNS定位是RocketMQ轻量版，提供轻量模型、轻量 HTTP RESTful 协定，运维轻量、计费轻量，具备易集成等特点。 为了帮忙大家由浅入深的对阿里云音讯队列MNS有更加全面的理解，同时冀望音讯队列MNS可能帮忙大家解决日常工作和生产的问题，特推出音讯队列MNS产品训练营课程，课程中不仅有对产品简略形象的介绍，还有“首秀”的入手实际学习课程。 参营播种参加本次音讯队列MNS训练营，您能够学习并播种到： 音讯队列MNS的根底概念及个性音讯队列MNS的最佳实际及案例基于MNS，0根底轻松构建Web Client 除了学习层面的播种，流动期间，实现所有参营工作且考试通过的前20名同学可取得（若问题雷同按考试工夫程序排名），即可收费取得小米充电宝。 流动工夫8月10日-8月31日（工作日期间） 参加形式（举荐PC端登陆体验） 扫描海报二维码 / 点击下方链接 https://developer.aliyun.com/trainingcamp/1091392f83464404a407920226a9df17 快来报名加入吧～https://developer.aliyun.com/trainingcamp/1091392f83464404a407920226a9df17 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：本文介绍了异步工作解决零碎是如何解决业务长耗时、高并发难题的。作者：不瞋 （阿里云 Serverless 技术负责人） 当咱们构建一个利用，总是心愿它是响应迅速，老本低廉的。而在理论中，咱们的零碎却面临各种各样的挑战，例如不可预测的流量顶峰，依赖的上游服务变得迟缓，大量申请却耗费大量 CPU/内存资源。这些因素经常导致整个零碎被拖慢，甚至不能响应申请。为了让应用服务总是响应迅速，很多时候不得不预留更多的计算资源，但大部分时候，这些计算资源都是闲置的。一种更好的做法是将耗时迟缓，或者须要耗费大量资源的解决逻辑从申请解决主逻辑中剥离进去，交给更具资源弹性的零碎异步执行，岂但让申请可能被迅速解决返回给用户，也节俭了老本。 一般来说，长耗时，耗费大量资源，或者容易出错的逻辑，非常适合从申请主流程中剥离进去，异步执行。例如新用户注册，注册胜利后，零碎通常会发送一封欢送邮件。发送欢送邮件的动作就能够从注册流程中剥离进去。另一个例子是用户上传图片，图片上传后通常须要生成不同大小的缩略图。但图片解决的过程不用蕴含在图片上传解决流程中，用户上传图片胜利后就能够完结流程，生成缩略图等解决逻辑能够作为异步工作执行。这样应用服务器防止被图片解决等计算密集型工作压垮，用户也能更快的失去响应。常见的异步执行工作包含： 发送电子邮件/即时消息查看垃圾邮件文档解决（转换格局，导出，……）音视频，图片解决（生成缩略图，加水印，鉴黄，转码，……）调用内部的三方服务重建搜寻索引导入/导出大量数据网页爬虫数据荡涤……Slack，Pinterest，Facebook 等公司都宽泛的应用异步工作，实现更好的服务可用性，更低的老本。依据 Dropbox 统计，他们的业务场景中一共有超过100种不同类型的异步工作。一个性能齐备的异步工作解决零碎能带来显著的收益： 更快的零碎响应工夫。将长耗时的，重资源耗费的逻辑从申请解决流程中剥离，在别的中央异步执行，能无效的升高申请响应延时，带来更好的用户体验。更好的解决大量突发性申请。在电商等很多场景下，经常有大量突发性申请对系统造成冲击。同样的，如果将重资源耗费逻辑从申请解决流程中剥离，在别的中央异步执行，那么雷同资源容量的零碎能响应更大峰值的申请流量。更低的老本。异步工作的执行时长通常在数百毫秒到数小时之间，依据不同的工作类型，正当的抉择工作执行工夫和更弹性的应用资源，就能实现更低的老本。更欠缺的重试策略和错误处理能力。工作保障被牢靠的执行（at-least-once），并且依照配置的重试策略进行重试，从而实现更好的容错能力。例如调用第三方的上游服务，如果能变成异步工作，设置正当的重试策略，即便上游服务偶然不稳固，也不影响工作的成功率。更快的实现工作解决。多个工作的执行是高度并行化的。通过伸缩异步工作解决零碎的资源，海量的工作可能在正当的老本内更快的实现。更好的工作优先级治理和流控。工作依据类型，通常依照不同的优先级解决。异步工作管理系统能帮忙用户更好的隔离不同优先级的工作，既让高优先级工作能更快的被解决，又让低优先级工作不至于被饿死。更多样化的工作触发形式。工作的触发形式是多种多样的，例如通过 API 间接提交工作，或是通过事件触发，或是定时执行等等。更好的可观测性。异步工作解决零碎通常会提供工作日志，指标，状态查问，链路追踪等能力，让异步工作更好的被观测、更容易诊断问题。更高的研发效率。用户专一于工作解决逻辑的实现，任务调度，资源扩缩容，高可用，流控，工作优先级等性能都由工作解决零碎实现，研发效率大幅提高。工作解决零碎架构工作解决零碎通常包含三局部：工作 API 和可观测，工作散发和工作执行。咱们首先介绍这三个子系统的性能，而后再探讨整个零碎面临的技术挑战和解决方案。 工作 API/Dashboard该子系统提供一组工作相干的 API，包含工作创立、查问、删除等等。用户通过 GUI，命令行工具，后者间接调用 API 的形式应用零碎性能。以 Dashboard 等形式出现的可观测能力也十分重要。好的工作解决零碎该当包含以下可观测能力： 日志：可能收集和展现工作日志，用户可能疾速查问指定工作的日志。指标：零碎须要提供排队工作数等要害指标，帮忙用户疾速判断工作的执行状况。链路追踪：工作从提交到执行过程中，各个环节的耗时。比方在队列中排队的工夫，理论执行的工夫等等。下图展现了 Netflix Cosmos 平台的 tracing 能力。 工作散发工作散发负责工作的调度散发。一个能利用于生产环境的工作散发零碎通常要具备以下性能： 工作的牢靠散发：工作一旦提交胜利后，无论遇到任何状况，零碎都该当保障该工作被调度执行。工作的定时/延时散发：很多类型的工作，心愿在指定的工夫执行，例如定时发送邮件/音讯，或者定时生成数据报表。另一种状况是工作能够延时较长一段时间执行也没问题，例如上班前提交的数据分析工作在第二天下班前实现即可，这类工作能够放到凌晨资源耗费低峰的时候执行，通过错峰执行降低成本。工作去重：咱们总是不心愿工作被反复执行。除了造成资源节约，工作反复执行可能造成更重大的结果。比方一个计量工作因为反复执行算错了账单。要做到工作只执行一次（exactly-once），须要在工作提交，散发，执行全链路上的每个环节都做到，包含用户在实现工作解决代码时也要在执行胜利，执行失败等各种状况下，做到 exactly-once。如何实现残缺的 exactly-once 比较复杂，超出了本文的探讨范畴。很多时候，零碎提供一个简化的语义也很有价值，即工作只胜利执行一次。工作去重须要用户在提交工作时指定工作 ID，零碎通过 ID来判断该工作是否曾经被提交和胜利执行过。工作谬误重试：正当的工作重试策略对高效、牢靠的实现工作十分要害。工作的重试要思考几个因素：1）要匹配上游工作执行零碎的解决能力。比方收到上游工作执行零碎的流控谬误，或者感知到工作执行成为瓶颈，须要指数退却重试。不能因为重试反而加大了上游零碎的压力，压垮上游；2）重试的策略要简略清晰，易于用户了解和配置。首先要对谬误进行分类，辨别不可重试谬误，可重试谬误，流控谬误。不可重试谬误是指确定性失败的谬误，重试没有意义，比方参数谬误，权限问题等等。可重试谬误是指导致工作失败的因素具备必然性，通过重试工作最终会胜利，比方网络超时等零碎外部谬误。流控谬误是一种比拟非凡的可重试谬误，通常意味着上游曾经满负荷，重试须要采纳退却模式，管制发送给上游的申请量。工作的负载平衡：工作的执行工夫变化很大，短的几百毫秒，长的数十小时。简略的 round-robin 形式散发工作，会导致执行节点负载不均。实际中常见的模式是将工作搁置到队列中，执行节点依据本身工作执行状况被动拉取工作。应用队列保留工作，让依据节点的负载把工作散发到适合的节点上，让节点的负载平衡。工作负载平衡通常须要散发零碎和执行子系统配合实现。工作按优先级散发：工作解决零碎通常对接很多的业务场景，他们的工作类型和优先级各不相同。位于业务外围体验相干的工作执行优先级要高于边缘工作。即便同样是音讯告诉，淘宝上买家收到一个商品评论告诉的重要性必定低于新冠疫情中的核酸检测告诉。但另一方面，零碎也要放弃肯定水平的偏心，不要让高优先级工作总是抢占资源，而饿死低优先级工作。工作流控：工作流控典型的应用场景是削峰填谷，比方用户一次性提交数十万的工作，冀望在几个小时内缓缓解决。因而零碎须要限度工作的散发速率，匹配上游工作执行的能力。工作流控也是保障系统可靠性的重要伎俩，某类工作提交量忽然爆发式增长，零碎要通过流控限度其对系统的冲击，减小对其余工作的影响。批量暂停和删除工作：在理论生产环境，提供工作批量暂停和删除十分重要。用户总是会呈现各种情况，比方工作的执行呈现了某些问题，最好能暂停后续工作的执行，人工查看没有问题后，再复原执行；或者长期暂停低优先级工作，开释计算资源用于执行更高优先级的工作。另一种状况是提交的工作有问题，执行没有意义。因而零碎要能让用户十分不便的删除正在执行和排队中的工作。工作的暂停和删除须要散发和执行子系统配合实现。工作散发的架构可分为拉模式和推模式。拉模式通过工作队列散发工作。执行工作的实例被动从工作队列中拉取工作，处理完毕后再拉取新工作。绝对于拉模式，推模式减少了一个分配器的角色。分配器从工作队列中读取工作，进行调度，推送给适合的工作执行实例。 拉模式的架构清晰，基于 Redis 等风行软件能够疾速搭建工作散发零碎，在简略工作场景下体现良好。但如果要反对工作去重，工作优先级，批量暂停或删除，弹性的资源扩缩容等简单业务场景须要的性能，拉模式的实现复杂度会迅速减少。实际中，拉模式面临以下一些次要的挑战： 资源主动伸缩和负载平衡简单。工作执行实例和工作队列建设连贯，拉取工作。当工作执行实例规模较大时，对工作队列的连贯资源会造成很大的压力。因而须要一层映射和调配，工作实例只和对应的工作队列连贯。下图是 Slack 公司的异步工作解决零碎架构。Worker 节点只和局部 Redis 实例相连。这解决了 worker 节点大规模扩大的能力，然而减少了调度和负载平衡的复杂度。 从反对工作优先级，隔离和流控等需要的角度思考，最好能应用不同的队列。但队列过多，又减少了治理和连贯资源耗费，如何均衡很有挑战。工作去重，工作批量暂停或者删除等性能依赖音讯队列性能，但很少有音讯类产品能满足所有需要，经常须要自行开发。例如从可扩展性的角度，通常做不到每一类工作都对应独自的工作队列。当工作队列中蕴含多种类型的工作时，要批量暂停或者删除其中某一类的工作，是比较复杂的。工作队列的工作类型和工作解决逻辑耦合。如果工作队列中蕴含多种类型的工作，要求工作解决逻辑也要实现相应的解决逻辑，对用户不敌对。在实践中，A 用户的工作解决逻辑不会预期接管到别的用户工作，因而工作队列通常由用户自行治理，进一步减少了用户的累赘。推模式的核心思想是将工作队列和工作执行实例解耦，平台侧和用户的边界更加清晰。用户只须要专一于工作解决逻辑的实现，而工作队列，工作执行节点资源池的治理都由平台负责。推模式的解耦也让工作执行节点的扩容不再受工作队列的连贯资源等方面的限度，可能实现更高的弹性。但推模式也引入了很多的复杂度，工作的优先级治理，负载平衡，调度散发，流控等都由分配器负责，分配器须要和上下游零碎联动。 总的来说，当工作场景变得复杂后，无论拉还是推模式，零碎复杂度都不低。但推模式让平台和用户的边界更清晰，简化了用户的应用复杂度，因而有较强技术实力的团队，实现平台级的工作解决零碎时，通常会抉择推模式。 工作执行工作执行子系统治理一批执行工作的 worker 节点，以弹性、牢靠的形式执行工作。典型的工作执行子系统需具备如下性能： 工作的牢靠执行。工作一旦提交胜利，无论任何状况，零碎该当保障工作被执行。例如执行工作的节点宕机，工作该当调度到其余的节点执行。工作的牢靠执行通常是工作散发和工作执行子系统独特配合实现。共享资源池。不同类型的工作解决资源共享对立的资源池，这样能力削峰填谷，进步资源利用效率，降低成本。例如把计算密集，io密集等不同类型的任务调度到同一台 worker 节点上，就能更充沛的利用节点上的CPU，内存，网络等多个维度的资源。共享资源池对容量治理，工作资源配额治理，工作优先级治理，资源隔离提出了更高的要求。资源弹性伸缩。零碎能依据负载的执行状况伸缩执行节点资源，降低成本。伸缩的机会和数量十分要害。常见的依据工作执行节点的 CPU，内存等资源水位状况伸缩，工夫较长，不能满足实时性要求高的场景。很多零碎也应用排队工作数等指标进行伸缩。另一个值得关注的点是执行节点的扩容须要匹配上下游零碎的能力。例如当工作散发子系统应用队列来散发工作时，worker 节点的扩容要匹配队列的连贯能力。工作资源隔离。在 worker 节点上执行多个不同的工作时，资源是互相隔离的。通常应用容器的隔离机制实现。工作资源配额。用户的应用场景多样，经常蕴含多种工作类型和优先级。零碎要反对用户为不同优先级的工作或者处理函数设置资源配额，为高优先级工作预留资源，或者限度低优先级工作能应用的资源。简化工作解决逻辑的编码。好的工作解决零碎，可能让用户专一于实现单个工作解决逻辑，零碎主动并行、弹性、牢靠的执行工作。平滑降级。底层零碎的降级不要中断长时工作的执行。执行后果告诉。实时告诉工作执行状态和后果。对于执行失败的工作，工作的输出被保留到死信队列中，不便用户随时手动重试。工作执行子系统通常应用 K8s 治理的容器集群作为资源池。K8s 可能治理节点，将执行工作的容器实例调度到适合的节点上。K8s 也内置了作业（Jobs）和定时作业（Cron Jobs）的反对，简化了用户应用 Job 负载的难度。K8s 有助于实现共享资源池治理，工作资源隔离等性能。但 K8s 次要能力还是在POD/实例治理上，很多时候须要开发更多的性能来满足异步工作场景的需要。例如： ...

简介：利用高可用服务 AHAS (Application High Availability Service) 是经阿里巴巴外部多年高可用体系积淀下来的云产品，以流量与容错为切入点，从流量管制、不稳固调用隔离、熔断降级、热点流量防护、零碎自适应爱护、集群流控等多个维度来帮忙保障服务的稳定性，同时提供秒级的流量监控剖析性能。作者：宿何 微服务的稳定性始终是开发者十分关注的话题。随着业务从单体架构向分布式架构演进以及部署形式的变动，服务之间的依赖关系变得越来越简单，业务零碎也面临着微小的高可用挑战。利用高可用服务 AHAS (Application High Availability Service) 是经阿里巴巴外部多年高可用体系积淀下来的云产品，以流量与容错为切入点，从流量管制、不稳固调用隔离、熔断降级、热点流量防护、零碎自适应爱护、集群流控等多个维度来帮忙保障服务的稳定性，同时提供秒级的流量监控剖析性能。AHAS 不仅在阿里外部淘宝、天猫等电商畛域有着宽泛的利用，在互联网金融、在线教育、游戏、直播行业和其余大型政央企行业也有着大量的实际。 流控是保障微服务稳定性最罕用也是最间接的一种管制伎俩。每个零碎、服务都有其能承载的容量下限，流控的思路非常简单，当某个接口的申请 QPS 超出肯定的下限后，回绝多余的申请，避免零碎被突发的流量打垮。市面上最常见的计划是单机维度的流控，比方通过 PTS 性能测试预估某个接口的容量下限是 100 QPS，服务有 10 个实例，则配置单机流控 10 QPS。但很多时候，因为流量散布的不确定性，单机维度的流量管制存在一些成果不佳的状况。 典型场景 1:准确管制对上游的调用总量 场景：服务 A 须要频繁调用服务 B 的查问接口，但服务 A 和 B 的容量存在差别，服务 B 约定最多给服务 A 提供总共 600 QPS 的查问能力，通过流控等伎俩进行管制。 痛点：若依照单机流控的策略配置，因为调用逻辑、负载平衡策略等起因，A 调用 B 达到每个实例的流量散布可能十分不均，局部流量较大的服务 B 实例触发单机流控，但总体限度量尚未达到，导致 SLA 未达标。这种不均的状况常常会产生在调用某个依赖服务或组件（如数据库拜访）的时候，这也是集群流控的一个典型场景：准确管制微服务集群对上游服务（或数据库、缓存）的调用总量。 典型场景 2：业务链路入口进行申请总量管制 场景：在 Nginx/Ingress 网关、API Gateway (Spring Cloud Gateway, Zuul) 进行入口流量管制，心愿准确管制某个或某组 API 的流量来起到提前爱护作用，多余流量不会打到后端系统。 痛点：如果依照单机维度配置，一方面不好感知网关机器数变动，另一方面网关流量不均可能导致限流成果不佳；而且从网关入口角度来讲，配置总体阈值是最天然的伎俩。 AHAS 集群流控AHAS 集群流控能够准确地管制某个服务接口在整个集群的实时调用总量，能够解决单机流控因流量不平均、机器数频繁变动、均摊阈值太小导致限流成果不佳的问题，联合单机流控兜底，更好地施展流量防护的成果。 ...

是不是平时听到说音讯队列啊，JMS啊，MQ啊 、kafka啊巴啦啦的一堆术语，听不懂？关系凌乱？明天就让咱们来一起来看看他们都是什么吧。 音讯队列介绍首先举个收快递的栗子，传统的收快递，快递小哥把咱们的快递送到咱们的手里。他须要什么条件嗯？ 快递小哥有工夫送，咱们有工夫取，快递小哥和咱们约定一个工夫地点。然而嗯。快递小哥有那么多的快递须要送，可能送我快递的时候，我不在家，可能我在家的时候，快递小哥送其余的中央的快递。所以嗯，这个时候，要么就是坐在家里等快递，要么就只能从新约个工夫点在送。那怎么办去防止这个状况嗯？ 于是嗯快递柜呈现了。快递小哥不必关怀我什么时候在家，因为快递小哥有工夫了，就把快递放快递柜，而我有工夫了，我就去快递柜取我的快递。 那么快递柜所起到的作用就是咱们明天要收的音讯队列。咱们能够把音讯队列比作是一个寄存快递的的快递柜，当咱们须要获取咱们快递的时候就能够从快递柜外面拿到属于咱们的快递。 什么是音讯队列咱们能够把音讯队列比作是一个寄存音讯的容器，当咱们须要应用音讯的时候能够取出音讯供本人应用。咱们看看维基百科上的形容：在计算机科学中，音讯队列（Message queue）是一种过程间通信或同一过程的不同线程间的通信形式，软件的贮列用来解决一系列的输出，通常是来自用户。 是不是很难了解，咱们换个说法来了解 咱们能够把音讯队列比作是一个寄存音讯的容器，当咱们须要应用音讯的时候能够取出音讯供本人应用。 音讯队列（Message queue）有什么用？音讯队列是分布式系统中重要的组件，应用音讯队列次要是为了通过异步解决进步零碎性能和削峰、升高零碎耦合性。罕用消息中间件17个维度全方位比照 通过异步解决进步零碎性能（削峰、缩小响应所需工夫）。 举个例子：咱们在某个网站进行注册账号，咱们须要做如下四件事： 填写咱们的注册信息；提交咱们的注册信息；咱们的邮箱收到注册信息；咱们的短信收到注册信息。如果采纳同步串行，所须要的工夫是：a+b+c+d 如果采纳同步并行，所须要的工夫是：a+b+max(c,d) 如果采纳音讯队列，所须要的工夫是：a+b+音讯队列 升高零碎耦合性举个例子，A公司做了某个零碎，B公司感觉A公司的某个性能很好，于是B公司和A公司的零碎进行了集成。这时C公司也感觉A公司的这个性能很好，于是，C公司也和A公司的零碎进行了集成。当前还有D公司…。 介于这种状况，A公司的零碎和其余公司的耦合度都很高，每集成一个公司的零碎，A公司都须要批改本人的零碎。如果采纳音讯队列，则变成了如下： 不论当前还有多少公司的应用程序想要用A公司的程序，都不须要和A公司进行集成，谁须要这个性能，谁就去音讯队列外面获取。 音讯队列的两种模式点对点模式应用程序由：音讯队列，发送方，接管方组成。 每个音讯都被发送到一个特定的队列，接收者从队列中获取音讯。队列保留着音讯，直到他们被生产或超时。 公布订阅模式用用程序有由：角色主题（Topic）、发布者(Publisher)、订阅者(Subscriber)形成。 发布者公布一个音讯，该音讯通过topic传递给所有的客户端。该模式下，发布者与订阅者都是匿名的，即发布者与订阅者都不晓得对方是谁。并且能够动静的公布与订阅Topic。Topic次要用于保留和传递音讯，且会始终保留音讯直到音讯被传递给客户端。 介绍完了音讯队列，接着咱们介绍JMS JMS介绍JMS即Java音讯服务（Java Message Service）利用程序接口，是一个Java平台中对于面向消息中间件（MOM）的API，相似于JDBC。用于在两个应用程序之间，或分布式系统中发送音讯，进行异步通信。它提供创立、发送、接管、读取音讯的服务。由Sun公司和它的合作伙伴设计的利用程序接口和相应语法，使得Java程序可能和其余音讯组件进行通信。 JMS是一个音讯服务的规范或者说是标准，容许应用程序组件基于JavaEE平台创立、发送、接管和读取音讯。它使分布式通信耦合度更低，音讯服务更加牢靠以及异步性。 介绍到这里，应该明确了音讯队列和JMS的区别了吧？音讯队列：计算机科学中，A和B进行通信的一种形式。JMS：java平台之间分布式通信的一种规范或者标准。换句话说，JMS就是java对于音讯队列的一种实现形式。JSM音讯模型点对点，公布订阅，音讯队列中曾经说的很分明了，这里就不反复说了。 JMS生产同步（Synchronous）订阅者/接管方通过调用 receive()来接管音讯。在receive（）办法中，线程会阻塞直到音讯达到或者到指定工夫后音讯仍未达到。 异步（Asynchronous）音讯订阅者需注册一个音讯监听者，相似于事件监听器，只有音讯达到，JMS服务提供者会通过调用监听器的onMessage()递送音讯。 JMS编程模型JMS编程模型十分相似于JDBC。回顾一下，咱们之前讲到的MyBatis。 SqlSessionFactoryBuilder去结构SqlSessionFactory会话工厂；SqlSessionFactory会话工厂给咱们关上SqlSession会话；SqlSession帮咱们去连贯数据库，接着咱们就能够执行增删查改。sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);SqlSession openSession = sqlSessionFactory.openSession(true);ProjectMapper mapper = openSession.getMapper(ProjectMapper.class);mapper.queryAllTaskByInit("init");JMS模型如下 Connection Factory给我创立Connection连贯;Connection连贯给咱们创立了Session会话；Session会话给咱们创立消费者和生产者；生产者生成音讯；消费者生产音讯； MQ介绍上文中，咱们说到了，JMS他并不是一种真正意义的技术，而是一种接口，一种标准。就想JDBC一样，无论是mybatis、hibernate，还是springJPA，不论你是那种技术实现，反正你得恪守JDBC的标准。 在Java中，目前基于JMS实现的音讯队列常见技术有ActiveMQ、RabbitMQ、RocketMQ。值得注意的是，RocketMQ并没有齐全恪守JMS标准，并且Kafka不是JMS的实现。 AMQP协定这里咱们以RabbitMQ为例介绍MQ，首先介绍下AMQP AMQP协定（Advanced Message Queuing Protocol，高级音讯队列协定）是一个过程间传递异步音讯的网络协议。 AMQP模型 AMQP工作过程发布者（Publisher）公布音讯（Message），经由交换机（Exchange）。交换机依据路由规定将收到的音讯分发给与该交换机绑定的队列、（Queue）。最初 AMQP 代理会将音讯投递给订阅了此队列的消费者，或者消费者依照需要自行获取。RabbitMQ是MQ产品的典型代表，是一款基于AMQP协定可复用的企业音讯零碎。 RabbitMQ模型RabbitMQ由两局部组成，别离是服务端和利用端； 服务端包含：队列和交换机。客户端包含：生产者和消费者。在rabbitmq server上能够创立多个虚构的message broker。每一个broker实质上是一个mini-rabbitmq server，别离治理各自的exchange，和bindings。 broker相当于物理的server，能够为不同app提供边界隔离，使得利用平安的运行在不同的broker实例上，相互之间不会烦扰。producer和consumer连贯rabbit server须要指定一个broker。音讯队列探秘 – RabbitMQ 音讯队列介绍 ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 案例导读：本案例介绍了清华大学能源互联网翻新研究院将 Apache Pulsar 落地能源互联网方向的实际。Pulsar 的云原生架构、Schema、Functions 等个性满足了相干业务需要，也加重了他们开发和运维累赘。浏览本文须要大概 8 分钟。 团队及业务简介能源互联网是电力与能源工业倒退的方向。随着信息、通信和互联网技术的飞速发展，可获取的数据量正以爆炸式形式迅猛增长，传统的数据处理办法已难以应答这些海量且增长极快的信息资产，大数据实践正是在这样的状态下应运而生。大数据处理技术能帮忙咱们透过海量数据疾速分辨其运行状态及发展趋势，在纷纷的世界中独具洞察力。 清华大学能源互联网翻新研究院能源大数据与凋谢生态钻研核心会集了国内外能源及电力大数据畛域的多位专家，致力于推动大数据基础理论和实际利用的全面翻新。能源大数据与凋谢生态钻研核心将大数据技术利用于能源互联网、智能电网和智慧用能等工程场景，联合高性能优化、并行计算和人工智能等先进技术，研发实用于能源电力行业特点的大数据 / 云计算平台，和基于数据驱动的能源电力系统的高级利用，从而实现大数据产业的倒退，造成以数据为外围的新型产业链，推动我国能源产业的转型与降级。 挑 战咱们团队的业务次要是与电力相干的物联网场景，旨在实现用户对传感器等设施数据的需要开发。咱们团队规模较小，但工作繁冗，心愿能更快更稳地实现客户的需要。 在整顿业务需要后，咱们提出当前端即服务（BaaS）为主、基于音讯的服务计划。在物联网畛域内，基于这样的解决方案，咱们能够共用更多基础设施服务，同时能够疾速应答不同需要进行业务开发。思考到非凡的业务需要，咱们的平台须要具备以下个性： 多租户：平台要实现业务拆散，服务不拆散，又能够确保安全审核，满足客户对数据安全性的敏感需要，就必须反对多租户。此外，还能够在通信、数据、业务这三方面提供一些根底服务，比方自定义数据结构的 Schema Registry，自定义数据归属的 ACL 权限治理（减少删改的 API 接口），以及实现各种业务的自定义函数引擎。Schema Registry：满足不同需要和利用场景下设施多变的数据结构，提供容许自定义数据结构的 Schema Registry。通用 API：提供蕴含减少删改的 HTTP RESTful APIs 和相应的 WebSocket 接口，确保在通信上提供根底服务，并基于这一根底服务进行扩大。ACL 权限治理：可自定义数据的 ACL 权限管制服务，保障数据安全。时序数据库：少数状况下，物联网场景都在和时序数据打交道，所以咱们抉择了基于 PostgreSQL 的开源 TimeScaleDB，并且依靠 TimeScaleDB 做了一系列时序数据的聚合查问接口。用户自定义 functions：实现各种业务的自定义函数引擎。之前咱们应用基于 RabbitMQ 和 Celery 的计划来实现用户自定义 functions 的函数引擎。这一计划的最后应用成果良好，但随着业务的增长，问题越来越多。咱们的小团队不得不花更多工夫来解决问题和优化整体计划。当 Celery 作为工作队列时，这些问题尤为重大。 咱们破费大量的工夫和精力解决的问题次要有两个： 须要认真配置 Celery 的 worker 和 task，防止执行工夫长的工作阻塞其余工作；Worker 更新时须要中断服务，更新工夫也绝对较长。此外，在非凡场景中，如果单个音讯比拟大且音讯解决工夫长时，Celery 和 RabbitMQ 的内存累赘都比拟大。 随着客户数量和我的项目数量的减少，这些问题变得日益突出，咱们决定找一个新产品代替原有计划。 ...

大家好，我是小菜。一个心愿可能成为 吹着牛X谈架构 的男人！如果你也想成为我想成为的人，不然点个关注做个伴，让小菜不再孤独！ 本文次要介绍 RabbitMQ的音讯失落问题 如有须要，能够参考 如有帮忙，不忘 点赞 ❥ 微信公众号已开启，小菜良记，没关注的同学们记得关注哦！ 是的，最终是对 RabbitMQ 下手了！ 面试中常见的RabbitMQ面试题也是多了去了，常见的如下： 音讯可靠性问题：如何确保发送的音讯至多被生产一次？提早音讯问题：如何实现音讯的提早投递？高可用问题：如何防止单点的MQ故障而导致的不可用问题？音讯沉积问题：如何解决数百万级以上音讯沉积，无奈及时生产问题？这几个问题又得让你脑壳疼一阵子，是不是也在网上看了挺多博文介绍这方面的解决方案，然而却看了又忘，理论便是因为短少实操，这篇小菜便重点讲述下 RabbitMQ 如何解决音讯失落问题~ 一、音讯可靠性问题音讯可靠性问题咱们又可能将其了解为如何避免音讯失落？那为什么音讯会失落呢？咱们能够先看看音讯投递的整个过程： 咱们从图中能够从三个阶段剖析可能造成音讯失落： publisher 发送音讯到 exchangeexchange 散发到 queuequeue 投递到 customer既然咱们晓得了哪些阶段可能造成数据失落，那咱们就能够从源头防备于未然~！ 工程构造 工程构造很简略，就是一个简略的 Spring Boot 我的项目，外面有个 消费者 和 生产者 两个模块 1、生产者发送失落RabbitMQ 中提供了 publisher confirm 机制来防止音讯发送到 MQ 的过程中失落的问题。音讯发送到 MQ 当前，会返回一个确认后果给生产者，用于示意音讯是否确认胜利。该确认后果存在两种申请： publisher-confirm该类型是 发送者确认 ，存在两种状况 音讯胜利投递到交换机，返回 ack音讯未投递到交换机，返回 nackpublisher-return该类型是 发送者回执 ，存在两种状况 音讯投递到交换机，且胜利散发到队列，返回 ack音讯投递到交换机，但未胜利散发到队列，返回 nack 留神：确认机制发送音讯时，须要给每个音讯设置一个全局惟一ID，以辨别不同音讯，防止ack抵触接下来咱们用代码来阐明具体的操作形式 1）配置文件咱们首先看下 生产者 的配置文件 后面几个配置 RabbitMQ 的连贯信息没啥好讲的，咱们来看几个比拟生疏的配置 publisher-confirm-type开启发送确认，这里能够反对两种类型 simple：同步期待 confirm 后果，直到超时correlated：异步回调，定义 ConfirmCallback，MQ返回后果时会回调这个 ConfirmCallbackpublisher-returns开启 public-return，同样是基于 CallBack 机制，不过是定义 ReturnCallback ...

简介：为了给云原生开发者提供更好的实战舞台，往年第二届云原生编程挑战赛正式启动，赛题降级，大咖坐镇，挑战 Serverless 极致翻新，与寰球开发者同场竞技，用技术解决理论问题！ 随同着企业由信息化阶段逐渐进入数字化时代，开发者的位置及角色也在发生变化：开发者的形成从最后以传统开发者为代表的群体，到逐步衰亡的云上开发者群体，再到日渐壮大的云原生开发者群体；开发者本身的使命也从已经的企业信息化策略执行者，转变为现在的数字化转型业务赋能者，将来将进一步成为数字翻新的技术引领者。时代召唤人人都应成为开发者，而云原生技术的倒退也为人人成为开发者奠定了根底。 云原生技术为开发者实现全云开发提供了可能，然而开发者也要苏醒地意识到，作为引领将来的云原生，不仅须要开发者好高鹜远，也要时常俯视星空，以前瞻视角聚焦云原生开发者技术能力要求，这样能力在把握正确的方向，做好实战的筹备。 为了给云原生开发者提供更好的实战舞台，往年第二届云原生编程挑战赛正式启动，赛题降级，大咖坐镇，挑战 Serverless 极致翻新，与寰球开发者同场竞技，用技术解决理论问题！ 赛题全新降级往年的云原生编程挑战赛围绕“挑战 Serverless 翻新实际”开展，将持续深度摸索 RocketMQ、Dubbo3、Serverless 三大热门技术畛域，为酷爱技术的年轻人提供一个挑战世界级技术问题的舞台。心愿选手们能用手中的技术，为全社会发明更大的价值。 本届云原生编程挑战赛共有 3 个赛道，理解更多具体的赛道规定及评审准则，可依据对应赛道扫码进行查看。 赛道一：针对冷热读写场景的 RocketMQ 存储系统设计Apache RocketMQ 作为的一款分布式的消息中间件，历年双十一承载了万亿级的音讯流转，为业务方提供高性能低提早的稳固牢靠的音讯服务。其中，实时读取写入数据和读取历史数据都是业务常见的存储拜访场景，而且会在同一时刻同时呈现，因而针对这个混合读写场景进行优化，能够极大的晋升存储系统的稳定性。同时英特尔® 傲腾™ 长久内存作为一款不同凡响的独立存储设备，能够放大传统内存与存储之间的差距，无望给 RocketMQ 的性能再次飞跃提供一个支点。 查看赛题详情： 赛道二：实现一个柔性集群调度机制Apache Dubbo 作为一款可拓展性极高的 RPC 框架，反对高度自定义化的集群调度机制，本次较量要求参赛者基于 Dubbo 提供的集群调度自定义化能力，辅以调用过滤链机制、自定义负载平衡机制等性能，设计一种柔性调度机制。 查看赛题详情： 赛道三：Less is more - Serverless翻新利用赛Serverless已不再局限利用于耦合性低、边缘利用或离线工作上，越来越多的企业将Serverless利用于人工智能、音视频解决、网站利用、电商零碎等生产外围链路。本赛道设置4个可选题目，包含充分发挥选手创意的自在赛题，以及在特定场景下，如高性价比音视频解决零碎、可视化工作流定义利用、阿里云衰弱仪表盘等，如何通过 Serverless 解决理论问题。 查看赛题详情： 瓜分603000元奖金池冠军：1支队伍/赛道，奖金10万，颁发获奖证书亚军：1支队伍/赛道，奖金5万，颁发获奖证书季军：1支队伍/赛道，奖金3万，颁发获奖证书优胜奖：7支队伍，每支队伍奖金3000元，颁发获奖证书鼓励奖：赛道1&赛道2：初赛B榜最终排名每赛道入围 TOP50 所在队伍的选手将取得大赛限量版公仔一件。参加奖：赛道1&赛道2：初赛B榜最终排名每赛道入围 TOP100 所在队伍的选手将取得大赛限量版留念T恤一件。赛道3：通过预选赛评比，升级半决赛的选手将取得大赛限量版留念T恤一件。取得与大咖面对面畅聊技术的机会： 大赛背景与往届回顾本次大赛由阿里云、Intel 主办，云原生利用平台、天池联结承办的云原生顶级品牌大赛。自 2015 年开始举办首届中间件性能挑战赛，在2020年中间件性能挑战赛全新降级为云原生编程挑战赛，超过10000 支团队报名参赛。 往届大赛毕业生是这样说的：上届冠军团队 greydog：感激举办方提供这样一个机会和平台，特地是复赛，应该动用了不少的机器评测。无论是初赛还是复赛，我感觉都是比拟乏味的，特地是赛道一。这次较量我学到了很多，比方 socket 编程、http 协定、grpc、proto、docker 相干常识，sse 指令优化，同时也意识了一些敌人，对阿里云的技术以及云原生有了更加粗浅的意识和理解。 上届亚军团队 ONE PIECE：初赛动静迁徙局部，一开始抉择间接迁徙这个计划，简略实现后发现并不现实，而后就放弃了，赛后才发现这个计划要更优，应该多做一些尝试。在较量中，学到了很多货色，也结识了很多大佬，感激官网举办这次较量。 上届亚军 睡衣小英雄：这次较量让我理解了阿里云函数计算这种最新的云计算模式，同时，通过对赛题的解读，对阿里云函数计算的根本工作模式有了初步的理解，让人受益匪浅。通过较量中的一次次尝试，对函数计算中的调度模块的性能和行为模式也有了更深刻的了解，初步意识了调度零碎的外围问题和艰难。是一场另人难忘而又不可多得的较量。 ...

简介：本文整顿了一份IoT队列的干货常识，让物联网从业者更进一步理解IoT场景队列，一起探讨一个适宜于物联网零碎的音讯队列。传统的音讯队列（（Kafka、RocketMQ等）通过多年打磨，在高性能、海量沉积、音讯可靠性等诸多方面都曾经做得十分极致，但在物联网场景中，往往须要面临着海量的消息传递，传统的音讯队列体现的“力不从心”。 IoT畛域中，从应用服务器到嵌入式芯片，都须要传递事件音讯，比方共享充电宝的开柜子、开灯指令从服务器发到设施、工业网关高频音讯流等，在这些信息传递的过程中，队列最大意义在于让整个音讯事件在不可控的环境因素变成一个安稳运行的零碎，因为IoT设施时不时会因为故障或网络抖动会导致大量音讯洪峰。 阿里云AIoT作为物联网畛域的引领者和创新者，在音讯队列畛域一直深耕与积淀，为了让物联网从业者更进一步理解IoT场景队列，阿里云技术专家吕建文，整顿了一份IoT队列的干货常识，与大家一起探讨一个适宜于物联网零碎的音讯队列。 一、IoT队列和一般队列的差别点 1，上下行隔离拆分在IoT场景中，咱们把须要队列分为两个场景，一个是上行队列，一个是上行队列。 拆分之后，能够隔离上下行链路，管制一个设施，比方领取胜利要下发关上柜子等，上行出任何问题，千万不能影响到上行业务。另外，上下行两条链路的特点差别十分大。设施上行音讯，并发量十分高，但很多场景下对于可靠性和时延要求低，而设施上行音讯，并发量则比拟低，但上行音讯（个别是管制设施指令）要求达到成功率很高。 2，反对设施级的海量topic传统队列的外围诉求是，不管沉积多少不影响它的性能。kafka的topic一多，本来音讯程序写文件劣势就会导致一个broker要进化到随机写，失去劣势，另外要zookeeper来协调这么多topic也是有局限，所以这些队列自身有提供一个外挂代理桥接器对外入口是多个设施topic，再桥接映射到大量的理论kafka topic，这计划有肯定可行性，但做不到隔离成果，治标不治本。 通过，图1和图2对比拟显著，一个队列拥塞尽量减少对其它设施影响。咱们须要的是“海量topic尽量互相隔离，并且不影响整体性能”，尽量做到设施A的音讯沉积topic，不影响设施B。 3，实时生成音讯优先发送先举一个例子，一个快递柜业务的队列沉积，而后“此时此刻”在柜子旁边的用户死命的在旁边用手机点开柜子怎么也打不开（此时后端系统都复原了），问题就是队列外面还有几十万条的音讯，新来的音讯须要排队, 等着之前的那些音讯生产完，甭管这些音讯还有没有用。  因而，实时生成音讯优先发送，沉积的音讯进入降级模式。 二、IoT音讯队列诞生 1， IoT队列的设计思路 设计指标是为了打造一个反对上下行隔离、实时优先、及海量topic的队列网关，设计准则如下： 齐全follow开源生态、和传统队列互补兼容保序降级，实时优先，沉积进化；仅实时音讯绝对有序。海量topic，多租户隔离连贯、计算、存储拆散2， 音讯模式图片只是个片段，从这个模式能够看进去机制差异，大家都没有错，只是出发点不同。 3， 连贯、计算、存储拆散 broker不做连贯，连贯网关代理，broker只做流转散发，无状态+程度扩大；存储交给nosql DB，高吞吐写。 4， 音讯策略-推拉联合这个应该是队列的外围难点之一，和传统队列辨别在于，咱们思考为平台化模式，独享资源过于低廉。但带来问题是生产端不可控，所以应用联合模式，只有在消费者在线时会拉取沉积音讯，而拉取是由AMQP队列网关来做，给到用户接口始终是推送过来的onMessage回调。 broker不是间接让consumer来连贯，而是把队列网关剥离进去，  这样会更灵便，甚至对于局部用户咱们的queue能够切换到ons、kafka等实现。kafka、rocketmq做法是在连贯时会调配给客户端一个broker接入地址。broker实时音讯优先推送给consumer，失败才会落到queue ；这是一个残缺事件，如果没有实现则不给producer commit。异步ACK5， 线性扩大-离线音讯局部实时局部音讯采纳推形式，基本上不会成为瓶颈，生产不过去音讯进入沉积模式。因为底层依赖存储曾经帮咱们解决外围存储的扩大，剩下次要问题点在于如何打消写入热点和生产热点，这样broker能够齐全做到无状态。 三，一个思考——如何解决海量topic问题？ 首先面对“大量”的问题个别都是思考分区，单元化，分组等隔离和拆分，这里海量topic咱们探讨针对一个单实例模式下如何尽可能做到更多topic，齐全任意数量都能100%没问题必定是不事实的。 因为broker和存储曾经隔离，broker和topic曾经没有什么关系，或者说任何topic数据生成，broker做的事件就是写入和散发。 海量topic，每个topic无限数量订阅：  topic和订阅者关系应用redis缓存或本地缓存，针对mqtt topic匹配有个topic tree的树算法，hivemq有实现版本。单个topic 海量订阅：  这个场景其实是组播和播送，咱们不会思考在队列自身下面去做这个事件，而是在下层封装播送组件来协调工作和批量发送。 四， 阿里云AIoT音讯队列 目前阿里云AIoT队列，也叫服务端订阅，意思就是用户用服务端订阅他们设施音讯。为了升高接入老本，用户能够应用AMQP1.0协定接入，合乎开源生态。 同时兼容传统队列和新队列，交给用户按场景来抉择，用户即可抉择应用kafka、mq，也能够选用iot队列，甚至组合模式，比方按音讯特色规定来配置流转队列。 阿里云AIoT的场景队列实际，在现有mq队列、kafka队列交融之外，加了种自有的实时优先队列实现，同时，退出了队列网关代理，既能让用户抉择一般音讯队列，也能够抉择轻便的IoT音讯队列。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：ARMS企业级场景被集成场景介绍 通过本次最佳实际内容，您能够看到ARMS OpenAPI能够灵便的被集成到客户链路监控场景，并对其进行可视化图形展现监控信息。 1. 背景信息利用实时监控服务ARMS（Application Real-Time Monitoring Service）是一款利用性能治理产品，能帮忙你实现全栈式的性能监控和端到端的全链路追踪诊断，让利用运维更加高效。 本次最佳实际是基于调用ARMS OpenAPI的模式来实现客户利用场景链路监控的可视化图形展现，应用环境为专有云V3.10版本ASCM控制台，调用ARMS OpenAPI接口通过工具Postman进行测试，在第二章节具体介绍了测试环境及测试工具。第三章节通过一个查问所有利用ARMS OpenAPI接口形容调用过程，并且蕴含该接口须要申请传入的参数接口列表。最初一章节将对一个简单利用场景，获取链路监控信息应用到ARMSOpenAPI接口，对每个接口列表字段、调用过程及返回后果具体介绍。 最佳实际价值通过调用ARMS OpenAPI在利用场景的应用，直观给阅读者理解到ARMS产品的能力，及ARMS提供一套OpenAPI能够容易的集成到客户利用中，疾速实现简单的微服务链路监控能力，由ARMS监控服务能力涵盖范畴能力比拟广，蕴含浏览器、小程序、APP、分布式应用和容器环境，因而残缺的监控能力，开发过程中不须要集成多开源组件的模式，使微服务程序监控性能开发简略，让利用运维变得容易。 2. 环境在应用ARMS前您须要依照以下内容对以后的零碎环境进行查看。 本次最佳实际基于专有云企业版V3.10.0版本ARMS。 阐明：ARMS OpenAPI各个版本变动不大，应用形式保持一致，所以此文档也实用于公共云产品或专有云V3.7.0以上版本。专有云V3.10.0控制台称为ASCM，V3.10.0之前版本为Apsara Stack。 1.登录ASCM控制台。 2.将鼠标指向页面上方导航栏中的产品，单击企业级分布式应用服务EDAS。 图1：ASCM 阐明：因为ARMS监控利用数据，须要EDAS产品配合。本次测试先通过EDAS部署一个规范的Spring Boot利用，开明ARMS监控并失去监控数据。 图 2：EDAS控制台 图 3：ARMS控制台 3.测试工具查看。 本实际将会在专有云环境中创立win64虚拟机，而后在虚拟机中装置Postman进行测试。 图4：Postman测试 3. Open API应用调用URL确认OpenAPI接口均为REST服务，首先确认服务的URL。 每个专有云环境域名不同，会导致URL不同。请依据具体环境信息批改URL信息，前缀及端口不变。 [http://arms.console.example.com:8099/](http://arms.console.example.com:8099/) 名称接口数据集API/dataset/GeneralQuery.json要害利用性能指标/metric/Metric.json报警信息无利用监控-利用拓扑/trace/Dependecies.json事件集/eventset/EventList.json调用示例-查看所有利用： API阐明URL：[http://arms.console.example.com:8099/trace/Services.json](http://arms.console.example.com:8099/trace/Services.json) 参数列表 字段名称字段类型字段含意是否必选备注\_userIdString用户id是用户名称(如arms\_admin)返回格局示例{ "code": 200, "data": { "details": [ { "pid": "string", //利用对应的pid "regionId": "string", "serviceName": "string" //利用名称 } ], "services":[ //利用名称列表 "string", "string" ] }, "success": true}Postman调用后果 ...

之前应用过，电信NBIOT，电信音讯推送应用的是，Pulsar 做下记录 Apache Pulsar（未完待续） 特点： 跨地区复制多租户零数据失落零Rebalancing工夫对立的队列和流模型高可扩展性高吞吐量Pulsar Proxy函数Pulsar 中有四种订阅模式：官网文档 exclusive单消费者shared多消费者，音讯只会被一个消费者生产掉。failover多消费者，同时失效的消费者只有一个，其余为备胎。key_shared多消费者，音讯只会被一个消费者生产掉。基于设置的key，进行音讯散发

最近这个 Apache Pulsar 消息中间件十分的火，号称下一代音讯中件，明天，就一起来看看它到底有多牛逼？ 概述Apache Pulsar 是一个应用 Apache Bookkeeper 提供长久化的 pub/sub 音讯平台，是一个用于服务端到服务端的消息中间件，最后由Yahoo开发并在2016年开源，目前正在Apache基金会下孵化。它能够提供如下个性： 跨地区复制多租户零数据失落零Rebalancing工夫对立的队列和流模型高可扩展性高吞吐量Pulsar Proxy函数架构 Pulsar 应用分层构造，将存储机制与 broker 隔离开来。此体系结构为 Pulsar 提供以下益处： 独立扩大broker独立扩大存储（Bookies）更容易容器化Zookeeper, Broker and BookiesZooKeeper提供集群的配置和状态存储在 Pulsar 集群中，一个或多个代理解决和负载平衡来自生产者的传入音讯，将音讯分派给消费者，与 Pulsar 配置存储通信以解决各种协调工作，将音讯存储在 BookKeeper 实例（又名 bookies）中，依赖特定于集群的 ZooKeeper 集群工作等等。 由一个或多个 bookie 组成的 BookKeeper 集群解决音讯的长久存储。特定于该集群的 ZooKeeper 集群解决 Pulsar 集群之间的协调工作。 更多对于 Pulsar 的架构介绍请参阅：https://pulsar.apache.org/doc... 四种订阅模式Pulsar 中有四种订阅模式：exclusive、shared、failover和key\_shared。这些模式如下图所示。 具体介绍参阅：https://pulsar.apache.org/doc... 性能优于 KafkaPulsar 体现最出色的就是性能，Pulsar 的速度比 Kafka 快得多，与 Kafka 相比，Pulsar 的速度晋升了 2.5 倍，提早升高了 40％。 数据起源:https://streaml.io/pdf/Gigaom... 注：比照是针对 1 个分区的 1 个主题，其中蕴含 100 字节音讯，Pulsar 每秒可发送 220,000+ 条音讯。 ...

简介：咱们在几年前决定引入 MQ 时，市场上曾经有不少成熟的解决方案，比方 RabbitMQ , ActiveMQ，NSQ，Kafka 等。思考到稳定性、保护老本、公司技术栈等因素，咱们抉择了 RocketMQ。 背景介绍 为何抉择 RocketMQ 咱们在几年前决定引入 MQ 时，市场上曾经有不少成熟的解决方案，比方 RabbitMQ , ActiveMQ，NSQ，Kafka 等。思考到稳定性、保护老本、公司技术栈等因素，咱们抉择了 RocketMQ ： 纯 Java 开发，无依赖，应用简略，呈现问题能 hold ；通过阿里双十一考验，性能、稳定性能够保障；性能实用，发送端：同步、异步、单边、延时发送；生产端：音讯重置，重试队列，死信队列；社区沉闷，出问题能及时沟通解决。 应用状况 次要用于削峰、解耦、异步解决；已在火车票、机票、酒店等外围业务宽泛应用，扛住微小的微信入口流量；在领取、订单、出票、数据同步等外围流程宽泛应用；每天 1000+ 亿条音讯周转。 下图是 MQ 接入框架图 因为公司技术栈起因，client sdk 咱们提供了 java sdk ；对于其余语言，收敛到 http proxy ，屏蔽语言细节，节约保护老本。依照各大业务线，对后端存储节点进行了隔离，互相不影响。 MQ 双核心革新 之前单机房呈现过网络故障，对业务影响较大。为保障业务高可用，同城双核心革新提上了日程。 为何做双核心 单机房故障业务可用；保证数据牢靠：若所有数据都在一个机房，一旦机房故障，数据有失落危险；横向扩容：单机房容量无限，多机房可分担流量。 双核心计划 做双核心之前，对同城双核心计划作了些调研，次要有冷（热）备份、双活两种。（过后社区 Dledger 版本还没呈现，Dledger 版本齐全可做为双核心的一种可选计划。） 1）同城冷（热）备份 两个独立的 MQ 集群, 用户流量写到一个主集群，数据实时同步到备用集群，社区有成熟的 RocketMQ Replicator 计划，须要定期同步元数据，比方主题，生产组，生产进度等。 2）同城双活 ...

简介：在 1.13 中，针对流批一体的指标，Flink 优化了大规模作业调度以及批执行模式下网络 Shuffle 的性能，以及在 DataStream API 方面欠缺无限流作业的退出语义。 本文由社区志愿者苗文婷整顿，内容起源自阿里巴巴技术专家高赟(云骞) 在 5 月 22 日北京站 Flink Meetup 分享的《面向流批一体的 Flink 运行时与 DataStream API 优化》。文章次要分为 4 个局部： 回顾 Flink 流批一体的设计介绍针对运行时的优化点介绍针对 DataStream API 的优化点总结以及后续的一些布局。GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 1. 流批一体的 Flink1.1 架构介绍首先看下 Flink 流批一体的整体逻辑。Flink 在晚期的时候，尽管是一个能够同时反对流解决和批处理的框架，然而它的流解决和批处理的实现，不论是在 API 层，还是在底下的 Shuffle、调度、算子层，都是独自的两套。这两套实现是齐全独立的，没有特地严密的关联。 在流批一体这一指标的疏导下，Flink 当初曾经对底层的算子、调度、Shuffle 进行了对立的形象，以对立的形式向上反对 DataStream API 和 Table API 两套接口。DataStream API 是一种比拟偏物理层的接口，Table API 是一种 Declearetive 的接口，这两套接口对流和批来说都是对立的。 1.2 长处 代码复用 基于 DataStream API 和 Table API，用户能够写同一套代码来同时解决历史的数据和实时的数据，例如数据回流的场景。 ...

MQTT QoS（服务质量）介绍 MQTT QoS 等级MQTT 设计了 3 个 QoS 等级。 QoS 0：音讯最多传递一次，如果过后客户端不可用，则会失落该音讯。QoS 1：消息传递至多 1 次。QoS 2：音讯仅传送一次。 工作原理QoS 0 - 最多散发一次当 QoS 为 0 时，音讯的散发依赖于底层网络的能力。发布者只会公布一次音讯，接收者不会应答音讯，发布者也不会贮存和重发消息。音讯在这个等级下具备最高的传输效率，但可能送达一次也可能基本没送达。Qos 1 - 至多散发一次当 QoS 为 1 时，能够保障音讯至多送达一次。MQTT 通过简略的 ACK 机制来保障 QoS 1。发布者会公布音讯，并期待接收者的 PUBACK 报文的应答，如果在规定的工夫内没有收到 PUBACK 的应答，发布者会将音讯的 DUP 置为 1 并重发消息。接收者接管到 QoS 为 1 的音讯时应该回应 PUBACK 报文，接收者可能会屡次承受同一个音讯，无论 DUP 标记如何，接收者都会将收到的音讯当作一个新的音讯并发送 PUBACK 报文应答。QoS 2 - 只散发一次当 QoS 为 2 时，发布者和订阅者通过两次会话来保障音讯只被传递一次，这是最高等级的服务质量，音讯失落和反复都是不可承受的。应用这个服务质量等级会有额定的开销。发布者公布 QoS 为 2 的音讯之后，会将公布的音讯储存起来并期待接收者回复 PUBREC 的音讯，发送者收到 PUBREC 音讯后，它就能够平安抛弃掉之前的公布音讯，因为它曾经晓得接收者胜利收到了音讯。发布者会保留 PUBREC 音讯并应答一个 PUBREL，期待接收者回复 PUBCOMP 音讯，当发送者收到 PUBCOMP 音讯之后会清空之前所保留的状态。 ...

消息中间件(未完待续)作用 解耦合（生产、生产隔离开）削峰填谷（异步化）Kafka次要用于解决沉闷的流式数据,大数据量的数据处理上。 RabbitMQ应用AMQP协定的消息中间件。独立部署，可做队列、PubSub模式。亦可实现延时队列以实现非凡业务场景。 MQTT实用物联网等网络不稳固、大量数据传输。头小，仅需2byteQOS 0、1、2别离对应： 只传输一次，不关系是否解决胜利可能会导致数据失落。至多传输一次可能会导致反复数据生产，需客户端自行去重有且仅有一次音讯代价高

简介：Matrix 通过一年多的建设，目前已具备多渠道对立接入、第三方生态互联互通、基金特色交易场景化封装等性能个性。Matrix 通过建设有品质、有温度的陪伴，从技术上和体验上，让用户了解危险，了解投资，进而为客户继续发明价值。作者｜伍振河 博时基金互联网金融部架构师 、曾志 博时基金互联网金融部开发主管 随着近两年业绩的抢眼，公募基金迎来了乘风破浪式的倒退，截至 2021 年 1 月底，资产治理规模已破 20 万亿，创下了历史新高。 在中国新经济高质量及科技翻新倒退的背景下，泛滥金融类的互联网平台与基金公司开展单干。互联网金融科技与传统金融业务的交融，促使传统金融公司的信息技术零碎更加凋谢。 据此，2020 年，博时基金互联网金融部启动了互联网开放平台 Matrix 的建设工作。 博时基金互联网开放平台 Matrix 建设背景与指标 1、传统金融架构遇到的问题与挑战 传统的金融零碎架构受到了互联网化的挑战，次要体现在以下几个方面： 1) 互联网入口不足管控 有多个团队提供不同模式的互联网服务，接口协议和权限管控形式不统一。当服务和接口越来越多时，API 管控能力有余的问题将会突显。 2) 零碎较为关闭，凋谢能力有余 传统基金行业零碎生态较为关闭，与合作伙伴凋谢生态的能力有待晋升。 3) 金融场景化封装能力有余 传统基金行业零碎广泛依赖于底层数据库提供的 ACID 个性实现事务一致性。微服务化之后，这套机制对金融场景化的产品包装能力显得顾此失彼。 2、零碎建设指标 1）多渠道对立平安接入 为自有零碎与经营厂商提供标准化对立接入，实现内外部 API 对立的管控。 Matrix 凋谢给通过博时互联网平台资质认证后的第三方平台应用，须要依据第三方平台辨认的不同身份，进行接口级别权限管控。 2）提供凋谢能力 搭建开放平台，与合作伙伴共建凋谢生态。在失去 Matrix 平台的受权后，第三方平台开发者能够通过调用博时基金互联网开放平台的接口能力，为第三方平台提供基金产品信息查问、注册开户、积分兑换、基金申赎、资产查问、联结登录等全方位服务；第三方平台能够依据本身理论状况自由选择或组合 APP 、微信公众号、微信小程序、H5 等前端形式对接。 3）封装基金行业特色性能 应用层实现分布式事务框架以保障整体事务的一致性。基于此，封装优惠购、投资陪伴等简单的金融场景化性能，让开发者专一于业务开发，晋升客户的投资体验。 Matrix 建设思路 1、总体架构 1）互联网架构图 ...

简介：随着公司业务的一直倒退，流量也在一直增长。咱们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。 作者｜梁勇 背景 哈啰已进化为包含两轮出行（哈啰单车、哈啰助力车、哈啰电动车、小哈换电）、四轮出行（哈啰逆风车、全网叫车、哈啰打车）等的综合化挪动出行平台，并向酒店、到店团购等泛滥本地生活化生态摸索。 随着公司业务的一直倒退，流量也在一直增长。咱们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。 本文就哈啰在音讯流量和微服务调用的治理中踩过的坑、积攒的教训进行分享。 作者介绍 梁勇 ( 老梁 ) ，《 RocketMQ 实战与进阶》专栏联结作者、参加了《 RocketMQ 技术底细》审稿工作。ArchSummit 寰球架构师大会讲师、QCon 案例研习社讲师。 以后次要在后端中间件方向，在公众号【瓜农老梁】已陆续发表百余篇源码实战类文章，涵盖 RocketMQ 系列、Kafka 系列、GRPC 系列、Nacosl 系列、Sentinel 系列、Java NIO 系列。目前就任于哈啰出行，任职高级技术专家。 聊聊治理这件事 开始之前先聊聊治理这件事件，上面是老梁集体了解： 治理在干一件什么事？ 让咱们的环境变得美妙一些须要晓得哪些地方还不够好？ 以往教训用户反馈业内比照还须要晓得是不是始终都是好的？ 监控跟踪告警告诉不好的时候如何再让其变好？ 治理措施应急计划目录 打造分布式音讯治理平台RocketMQ 实战踩坑和解决打造微服务高可用治理平台背景 裸奔的 RabbitMQ 公司之前应用 RabbitMQ ，上面在应用 RabbitMQ 时的痛点，其中很多事变因为 RabbitMQ 集群限流引起的。 积压过多是清理还是不清理？这是个问题，我再想想。积压过多触发集群流控？那是真的影响业务了。想生产前两天的数据？请您重发一遍吧。要统计哪些服务接入了？您要多等等了，我得去捞IP看看。有没有应用危险比方大音讯？这个我猜猜。裸奔的服务已经有这么一个故障，多个业务共用一个数据库。在一次晚顶峰流量陡增，把数据库打挂了。 数据库单机降级到最高配仍然无奈解决重启后缓一缓，不一会就又被打挂了如此循环着、煎熬着、默默期待着顶峰过来思考：无论音讯还是服务都须要欠缺的治理措施 打造分布式音讯治理平台 设计指南 哪些是咱们的要害指标，哪些是咱们的主要指标，这是音讯治理的首要问题。 设计指标 旨在屏蔽底层各个中间件（ RocketMQ / Kafka ）的复杂性，通过惟一标识动静路由音讯。同时打造集资源管控、检索、监控、告警、巡检、容灾、可视化运维等一体化的音讯治理平台，保障消息中间件安稳衰弱运行。 音讯治理平台设计须要思考的点 提供简略易用 API有哪些关键点能掂量客户端的应用没有安全隐患有哪些要害指标能掂量集群衰弱不衰弱有哪些罕用的用户/运维操作将其可视化有哪些措施应答这些不衰弱尽可能简略易用 设计指南 把简单的问题搞简略，那是能耐。 ...

简介：介绍EMR高平安集群如何应用Kerberos和Apache Ranger进行鉴权和拜访受权治理 中转最佳实际：【EMR集群平安认证和受权治理】 最佳实际频道：【点击查看更多上云最佳实际】 这里有丰盛的企业上云最佳实际，从典型场景入门，提供一系列我的项目实际计划，升高企业上云门槛的同时满足您的需要！ 场景形容阿里云EMR服务Kafka和Hadoop平安集群应用Kerberos进行用户平安认证，通过ApacheRanger服务进行拜访受权治理。本最佳实际中以ApacheWeb服务器日志为例，演示基于Kafka和Hadoop的生态组件构建日志大数据仓库，并介绍在整个数据流程中，如何通过Kerberos和Ranger进行认证和受权的相干配置。 解决问题1.创立基于Kerberos的EMRKafka和Hadoop集群。 2.EMR服务的Kafka和Hadoop集群中Kerberos相干配置和应用办法。 3.Ranger中增加Kafka、HDFS、Hive和Hbase服务和拜访策略。 4.Flume中和Kafka、HDFS相干的平安配置。 产品列表E-MapReduce专有网络VPC云服务器ECS云数据库RDS版 中转最佳实际 》》 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：自动化营销能够将Quick Audience的营销渠道串联起来，将受众和营销动作进行匹配组合，简略且高效的实现营销目标！-更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index Quick Audience 数据可视化剖析平台 定位智能用户增长，实现全方位洞察，多渠道触达的增长闭环，实现以人为核心的消费者全生命周期洞察经营。 自动化营销（MA）为Quick Audience用户营销下的一个功能模块，通过这个模块，能够将QA侧的营销渠道全副串联起来，将受众和营销动作进行匹配组合，简略且高效的实现营销目标。 比方，在某次营销流动，须要将指标受众同时推送至天攻智投、巨量引擎、腾讯广告、百度信息流，则能够在自动化营销中抉择复制多分支，匹配上述几个推送渠道组件即可实现营销目标，这大大缩减了通过私有化营销模块创立单个渠道营销工作的工作量，在工作治理上也更加不便。 自动化营销功能模块在产品中的定位，见下图。 现有性能简介自动化营销功能模块的具体操作形式：客户抉择在用户洞察侧圈选好的受众，通过组件库抉择不同类型的流程组件，以构建流程图的形式创立自动化营销工作，实现本人的营销目标。 目前组件库反对以下几种类型组件： 营销动作组件：包含邮件发送、短信发送、数字短信、天攻智投、巨量引擎、腾讯广告、百度信息流、趣媒体、生成受众等营销动作组件。条件管制组件：包含事件多分支、工夫多分支、标签多分支、复制分支、随机分支等条件管制组件。流程管制组件：包含期待、完结两个流程管制组件 降级性能汇总基于现有的性能，本次降级将减少以下性能点： 流程起始条件减少实时事件（事件起源可为App、H5页面以及小程序），可配置基于某一事件触发的自动化营销流程，营销动作蕴含push营销、短信营销、数字短信、邮件营销以及微信营销；条件管制组件减少事件多分支组件；流程配置将反对基于某一周期（日、周、月或自定义周期）设置；营销动作组件减少发push音讯、发微信营销音讯、推送kafka以及发优惠券；降级后的自动化营销能够反对基于一方采集的用户行为事件进行自动化营销流程的配置，同时，在受众进行周期更新后，通过配置周期营销流程能够在同一个自动化营销流程中，实现基于最新筛选的受众进行营销。 应用场景围绕用户经营的三种典型场景：转化、促活、沉睡激活，QA用户营销提供了几种流程配置参考案例，通过点击自动化营销模块右上角案例介绍即可获取。 1、转化场景a. 用户精准推送促转化针对不同渠道入会的会员，符合不同的扫码入会场景能够进行营销内容的调整，比方某快消品牌为线上扫码入会的会员和线下门店扫码入会的会员发送不同场景的入会问候短信。 针对线上入会的会员通过优惠券发送进行转化，而线下门店入会的会员则会更多的应用门店流动告诉揭示。采纳不同形式实现用户精准推送并转化。 用户精准推送促转化的流程配置指引： b. 加购未购用户转化数据表明加购过的客户，转化为购买用户的可能性较高，能够通过抉择曾经圈选好的加购未购用户进行购买揭示的短信音讯推送，期待一段时间后若未购买，可再进行购买揭示推送。 加购未购用户转化流程配置指引： c. 已购用户转粉对于在线上渠道产生过购买行为的用户，能够通过公众号二维码推送的模式将其转化为公众号粉丝. 已购用户转粉流程配置指引： 2、促活场景a. 复购营销对于肯定购买频次，如最近1年内购买2次以上或者最近90天内购买1次以上的用户进行复购营销，通过设置条件筛选出指标受众，将定制的优惠礼包通过数字短信推送至指标受众，进行复购营销。 复购营销流程配置指引： 3、沉睡激活场景a. 濒临沉睡用户激活通过用户生命周期治理，对于行将散失的用户，能够依据不同的工夫点对其进行短信问候，升高用户流概率。 濒临沉睡用户激活流程配置指引： 我想理解更多：https://dp.alibaba.com/consult数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。 目前正通过阿里云对外输入系列解决方案，包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。 其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包含： - Dataphin，一站式、智能化的数据构建及治理平台；- Quick BI，随时随地 智能决策；- Quick Audience，全方位洞察、全域营销、智能增长；- Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；- Quick Stock， 智能货品经营平台；- Quick Decision，智能决策平台；官方站点： 数据中台官网 https://dp.alibaba.com 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：介绍 b 站的机器学习工作流平台 ultron 在 b 站多个机器学习场景上的利用。分享嘉宾：张杨，B 站资深开发工程师 导读：整个机器学习的过程，从数据上报、到特色计算、到模型训练、再到线上部署、最终成果评估，整个流程十分简短。在 b 站，多个团队都会搭建本人的机器学习链路，来实现各自的机器学习需要，工程效率和数据品质都难以保障。于是咱们基于 Flink 社区的 aiflow 我的项目，构建了整套机器学习的规范工作流平台，减速机器学习流程构建，晋升多个场景的数据实效和准确性。本次分享将介绍 b 站的机器学习工作流平台 ultron 在 b 站多个机器学习场景上的利用。 目录： 1、机器学习实时化 2、Flink 在 B 站机器学习的应用 3、机器学习工作流平台构建 4、将来布局 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、机器学习实时化 首先讲下机器学习的实时化，次要是分为三局部： 第一是样本的实时化。传统的机器学习，样本全部都是 t+1，也就是说，明天模型用的是昨天的训练数据，每天早上应用昨天的全天数据训练一次模型；第二是特色的实时化。以前的特色也根本都是 t+1，这样就会带来一些举荐不精确的问题。比方，明天我看了很多新的视频，但给我举荐的却还是一些昨天或者更久之前看到的内容；第三就是模型训练的实时化。咱们有了样本的实时化和特色的实时化之后，模型训练也是齐全能够做到在线训练实时化的，能带来更实时的举荐成果。传统离线链路 上图是传统的离线链路图，首先是 APP 产生日志或者服务端产生 log，整个数据会通过数据管道落到 HDFS 上，而后每天 t+1 做一些特色生成和模型训练，特色生成会放到特色存储外面，可能是 redis 或者一些其余的 kv 存储，再给到下面的 inference 在线服务。 传统离线链路的有余 那它有什么问题呢？ 第一是 t+1 数据模型的特色时效性都很低，很难做到特地高时效性的更新；第二是整个模型训练或者一些特色生产的过程中，每天都要用天级的数据，整个训练或者特色生产的工夫十分长，对集群的算力要求十分高。实时链路 上图咱们进行优化之后整个实时链路的过程，红叉的局部是被去掉的。整个数据上报后通过 pipeline 间接落到实时的 kafka，之后会做一个实时特色的生成，还有实时样本的生成，特色后果会写到 feature store 外面去，样本的生成也须要从 feature store 外面去读取一些特色。 ...

简介：Flink+Hologres亿级用户实时UV准确去重最佳实际UV、PV计算，因为业务需要不同，通常会分为两种场景： 离线计算场景：以T+1为主，计算历史数据实时计算场景：实时计算日常新增的数据，对用户标签去重针对离线计算场景，Hologres基于RoaringBitmap，提供超高基数的UV计算，只需进行一次最细粒度的预聚合计算，也只生成一份最细粒度的预聚合后果表，就能达到亚秒级查问。具体详情能够参见往期文章>>Hologres如何反对超高基数UV计算(基于RoaringBitmap实现) 对于实时计算场景，能够应用Flink+Hologres形式，并基于RoaringBitmap，实时对用户标签去重。这样的形式，能够较细粒度的实时失去用户UV、PV数据，同时便于依据需要调整最小统计窗口（如最近5分钟的UV），实现相似实时监控的成果，更好的在大屏等BI展现。相较于以天、周、月等为单位的去重，更适宜在流动日期进行更细粒度的统计，并且通过简略的聚合，也能够失去较大工夫单位的统计后果。 主体思维Flink将流式数据转化为表与维表进行JOIN操作，再转化为流式数据。此举能够利用Hologres维表的_insertIfNotExists_个性联合自增字段实现高效的uid映射。Flink把关联的后果数据依照工夫窗口进行解决，依据查问维度应用RoaringBitmap进行聚合，并将查问维度以及聚合的uid寄存在聚合后果表，其中聚合出的uid后果放入Hologres的RoaringBitmap类型的字段中。查问时，与离线形式类似，间接依照查问条件查问聚合后果表，并对其中要害的RoaringBitmap字段做or运算后并统计基数，即可得出对应用户数。解决流程如下图所示 计划最佳实际1.创立相干根底表1）创立表uid\_mapping为uid映射表，用于映射uid到32位int类型。 RoaringBitmap类型要求用户ID必须是32位int类型且越浓密越好（即用户ID最好间断）。常见的业务零碎或者埋点中的用户ID很多是字符串类型或Long类型，因而须要应用uid\_mapping类型构建一张映射表。映射表利用Hologres的SERIAL类型（自增的32位int）来实现用户映射的主动治理和稳固映射。因为是实时数据, 设置该表为行存表，以进步Flink维表实时JOIN的QPS。BEGIN;CREATE TABLE public.uid_mapping (uid text NOT NULL,uid_int32 serial,PRIMARY KEY (uid));--将uid设为clustering_key和distribution_key便于疾速查找其对应的int32值CALL set_table_property('public.uid_mapping', 'clustering_key', 'uid');CALL set_table_property('public.uid_mapping', 'distribution_key', 'uid');CALL set_table_property('public.uid_mapping', 'orientation', 'row');COMMIT;2）创立表dws\_app为根底聚合表，用于寄存在根底维度上聚合后的后果。 应用RoaringBitmap前须要创立RoaringBitmap extention，同时也须要Hologres实例为0.10版本CREATE EXTENSION IF NOT EXISTS roaringbitmap;为了更好性能，倡议依据根底聚合表数据量正当的设置Shard数，但倡议根底聚合表的Shard数设置不超过计算资源的Core数。举荐应用以下形式通过Table Group来设置Shard数--新建shard数为16的Table Group，--因为测试数据量百万级，其中后端计算资源为100core，设置shard数为16BEGIN;CREATE TABLE tg16 (a int); --Table Group哨兵表call set_table_property('tg16', 'shard_count', '16'); COMMIT;相比离线后果表，此后果表减少了工夫戳字段，用于实现以Flink窗口周期为单位的统计。后果表DDL如下：BEGIN;create table dws_app( country text, prov text, city text, ymd text NOT NULL, --日期字段 timetz TIMESTAMPTZ, --统计工夫戳，能够实现以Flink窗口周期为单位的统计 uid32_bitmap roaringbitmap, -- 应用roaringbitmap记录uv primary key(country, prov, city, ymd, timetz)--查问维度和工夫作为主键，避免反复插入数据);CALL set_table_property('public.dws_app', 'orientation', 'column');--日期字段设为clustering_key和event_time_column，便于过滤CALL set_table_property('public.dws_app', 'clustering_key', 'ymd');CALL set_table_property('public.dws_app', 'event_time_column', 'ymd');--等价于将表放在shard数为16的table groupcall set_table_property('public.dws_app', 'colocate_with', 'tg16');--group by字段设为distribution_keyCALL set_table_property('public.dws_app', 'distribution_key', 'country,prov,city');COMMIT;2.Flink实时读取数据并更新dws\_app根底聚合表残缺示例源码请见alibabacloud-hologres-connectors examples ...

简介： bilibili 万亿级传输散发架构的落地，以及 AI 畛域如何基于 Flink 打造一套欠缺的预处理实时 Pipeline。 本文由 bilibili 大数据实时平台负责人郑志升分享，本次分享外围解说万亿级传输散发架构的落地，以及 AI 畛域如何基于 Flink 打造一套欠缺的预处理实时 Pipeline。本次分享次要围绕以下四个方面： 一、B 站实时的前世与今生 二、Flink On Yarn 的增量化管道的计划 三、Flink 和 AI 方向的一些工程实际 四、将来的倒退与思考 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、B 站实时的前世与今生1. 生态场景辐射说起实时计算的将来，关键词就在于数据的实效性。首先从整个大数据倒退的生态上，来看它的外围场景辐射：在大数据倒退的初期，外围是以面向天为粒度的离线计算的场景。 那时候的数据实效性少数都是以运算以天为单位，它更加重视工夫和老本的均衡。 随着数据利用，数据分析以及数据仓库的遍及与欠缺，越来越多的人对数据的实效性提出了更高的要求。比方，当须要做一些数据的实时举荐时，数据的实效将决定它的价值。在这种状况下，整个实时计算的场景就广泛诞生。 但在理论的运作过程当中，也遇到了很多场景 ，其实并没有对数据有十分高的实时性要求，在这种状况下必然会存在数据从毫秒，秒或者天的新的一些场景，实时场景数据更多是以分钟为粒度的一些增量计算的场景。对于离线计算，它更加重视老本；对实时计算，它更加重视价值实效；而对于增量计算，它更加重视去均衡老本，以及综合的价值和工夫。 2. B 站的时效性在三个维度上，B 站的划分是怎么的？对于 B 站而言 ，目前有 75% 的数据是通过离线计算来进行撑持的，另外还有 20% 的场景是通过实时计算， 5% 是通过增量计算。 对于实时计算的场景， 次要是利用在整个实时的机器学习、实时举荐、广告搜寻、数据利用、实时渠道剖析投放、报表、olap、监控等；对于离线计算，数据辐射面广，次要以数仓为主；对于增量计算，往年才启动一些新的场景，比如说 binlog 的增量 Upsert 场景。 3. ETL 时效性差对于实效性问题 ，其实晚期遇到了很多痛点 ，外围集中在三个方面： 第一，传输管道不足计算能力。晚期的计划，数据根本都是要按天落到 ODS ，DW 层是凌晨过后的第二天去扫描前一天所有 ODS 层的数据，也就是说，整体数据没方法前置荡涤；第二，含有大量作业的资源集中暴发在凌晨之后，整个资源编排的压力就会十分大；第三、实时和离线的 gap 是比拟难满足的，因为对于大部分的数据来说，纯实时的老本过高，纯离线的实效又太差。同时，MySQL 数据的入仓时效也不太够。举个例子，好比 B 站的弹幕数据 ，它的体量十分夸大，这种业务表的同步往往须要十几个小时，而且十分的不稳固。 ...

简介：今天下午三点整开播，阿里云高级研发工程师在线解密云原生下如何高效开发！直播主题：云原生下如何高效开发？ 直播工夫：2021.05.13 15点 讲师：纳海，阿里云高级研发工程师 简介：在云原生架构中，咱们的微服务利用、数据库、音讯队列等组件都运行在云端，因为本地网络和云上网络不互通，开发者无奈在本地实现开发、测试、联调和代码修复的研发闭环。本次直播介绍端云互联开发者工具，通过此工具可使得本地利用拜访云端数据库和音讯队列等组件，并且可跟云端微服务双向互通，同时还反对多人精准联调、疾速链路诊断等高级个性，可无效进步开发效率。 直播间链接：https://yqh.aliyun.com/live/detail/23917 .png") 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：本文配套可交互教程已登录阿里云知口头手实验室，PC 端登录 start.aliyun.com 在浏览器中立刻体验。 作者 | 洛夜 起源 | 阿里巴巴云原生公众号 在 Spring 生态中玩转 RocketMQ 系列文章： 《如何在 Spring 生态中玩转 RocketMQ？》《罗美琪和春波特的故事...》《RocketMQ-Spring 毕业两周年，为什么能成为 Spring 生态中最受欢迎的 messaging 实现？》《应用 rocketmq-spring-boot-starter 来配置、发送和生产 RocketMQ 音讯》《Spring Cloud Stream 体系及原理介绍》本文配套可交互教程已登录阿里云知口头手实验室，PC 端登录 start.aliyun.com 在浏览器中立刻体验。 Spring Cloud Bus 对本人的定位是 Spring Cloud 体系内的音讯总线，应用 message broker 来连贯分布式系统的所有节点。Bus 官网的 Reference 文档 比较简单，简略到连一张图都没有。 这是最新版的 Spring Cloud Bus 代码构造(代码量比拟少)： Bus 实例演示在剖析 Bus 的实现之前，咱们先来看两个应用 Spring Cloud Bus 的简略例子。 1. 所有节点的配置新增Bus 的例子比较简单，因为 Bus 的 AutoConfiguration 层都有了默认的配置，只须要引入消息中间件对应的 Spring Cloud Stream 以及 Spring Cloud Bus 依赖即可，之后所有启动的利用都会应用同一个 Topic 进行音讯的接管和发送。 ...

简介：云原生这个概念曾经越来越深入人心，但对“云原生到底是什么？”这个问题，依然是各种各样的解读，最近对云原生具体是什么有了点感触，于是写下来分享和探讨下。本文转载自公众号：HelloJava。 云原生这个概念曾经越来越深入人心，但对“云原生到底是什么？”这个问题，依然是各种各样的解读，最近对云原生具体是什么有了点感触，于是写下来分享和探讨下。 我当初认为云原生其实是让泛滥的公司，通过基于云的产品迅速取得在构建一个当初这个时代的利用（是不是有点像 AWS 始终讲的 Modern Applications）所必须的各种根底能力（如：极强的规模伸缩性、极高的可用性、极低的翻新/经营老本、大数据的剖析/经营能力等等），而不须要像以前的很多公司，为了具备这些能力，投入微小，或者用另外一句话说：云原生就是业余的根底能力普惠化，顺手可得。 当今时代的利用和多年前的利用面临的情况差异太大，这个差别和当今业务面临的强烈竞争和玩法有很大的关系，我以前始终感觉像阿里在倒退过程中积攒的很多能力，里面很少有公司会须要，就像当年百亿、千亿美金的公司是如许难才呈现，但当初看来则齐全不一样，所以这也奠定了当今时代的利用在技术层面能力的要求也远不一样，简略说几个点： 对可用性的要求远高于以前的利用：当初的利用通常一上线对可用性要求就曾经不低了，因为一旦出问题就很容易把用户送给竞对；对伸缩性的能力要求也远比以前高，次要体现在两个方面：一是团队规模，当初的业务公司很容易迅速倒退到百人以上，而百人以上的研发效率如何放弃尽量不降落，这对系统的伸缩能力有着很高的要求；二是用户规模，当初泛滥业务的用户规模能够很快地冲破百万、千万规模，这就要求零碎必须能依据用户规模疾速地伸缩；翻新和经营的老本必须低：业务竞争无比强烈，快是要害，所以怎么在不须要太大投入的状况下疾速上线各种业务，是无比重要的；另一个方面就是经营的老本，这个是和当初利用的用户规模、强烈竞争密切相关的；大数据的玩法：当初的很多业务对获客、举荐、搜寻等的大数据化要求还是相当高的。阿里是一家在本身倒退过程中，逐渐碰到上述的挑战（当年的竞争环境根本还不会要求一个业务上来就把各种能力具备好），但以前也没有云可用，所以在倒退过程中一直积攒各种能力，当初通过开源、云商业化对外输入这些能力，使得即便到了当初这样的竞争环境下，各种有业务翻新想法的同学们，还是能够像当年一样疾速上线业务，而不是要先投入巨多力量、破费巨多工夫把须要的根底能力打磨进去。 我本人并没有齐全经验阿里的倒退过程，接下来次要还是简略说下我本人经验的一些。 在 2007 年，淘宝在根底能力上面临的最大问题是伸缩性，两个景象过后都呈现了：用户数量大量减少，加机器曾经根本要加到瓶颈了；研发人员大量增长，研发效率下滑非常明显。在这个阶段，淘宝做了一轮十分重要的架构革新，磨难出了例如服务框架、消息中间件、分库分表计划、分布式文件系统、分布式缓存等根底技术产品，联合业务架构的从新设计，很好地解决掉了伸缩性的问题。在 2009 年，淘宝面临了可用性问题，常常出各种故障，于是开始积攒各种监控、疾速复原、tracing、零碎设计里如非关键门路异步化等技能。可用性这块的投入始终在继续，到起初为解决 双11 这种非凡状况的可用性、确定性诉求而发明的全链路压测；通过同城双活、异地多活的多机房体系构建的强容灾能力以及疾速恢复能力等；以及在线下场景退出起初面临的不一样的可用性计划等。各种场景的高可用计划的积攒，也使得业务的可用性越来越有保障。2011 年左右，阿里开始感觉将来在资源投入上的经营老本可能会很夸大，于是在 2011 年开始通过容器化来晋升机器应用效率、继续进行老本优化，起初又继续通过云资源弹性来解决 双11 这类型的短时顶峰的老本投入问题，通过在线离线混部解决大数据机器投入越来越大、在线机器集群利用率不高产生节约的问题，通过多年致力，使得业务在高速增长的状况下，机器资源投入上的经营老本还是绝对可控的。如上文所讲，阿里是依附微小的人力投入、场景打磨和多年的继续投入才逐步造成了齐备的能力。而当初的业务，则能够用云原生的形式构建，使本身一上来就具备这些能力，至多可能让本人在现在强烈且要求更高的业务竞争环境中，不会在这些根底能力上拖后腿，以此能够花更多的精力、工夫、资源在真正的业务翻新上。这样具象化的云原生对整个社会的翻新还是相当有价值的。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：MQTT于4.29日正式公布的轻量级版本，能够满足客户业务规模与整体音讯量大，音讯可靠性要求不高，但业务连续性不受单条音讯发送失败而影响的场景。微音讯队列MQTT版是阿里云推出的一款面向挪动互联网以及物联网畛域的轻量级消息中间件，通过对 MQTT、WebSocket 等协定的全面反对，连接端和云之间的双向通信，实现 C2C、C2B、B2C 等业务场景之间的音讯通信，可撑持千万级设施与音讯并发。 如何在微音讯队列MQTT版和物联网平台做抉择？相比于物联网平台，微音讯队列MQTT版提供稳固、轻量、高价的云端通信通道，并与阿里云上音讯产品无缝适配，对于有研发团队及能力并有布局建设企业本身云上物联网平台的客户是最佳之选。同时微音讯队列MQTT版采纳开源MQTT SDK，未对音讯格局做额定的限度，除物联网平台外同时实用于有音讯播送，订阅，P2P的场景，如群聊，视频/新批发的信令等业务场景。 如何抉择最适宜本人业务的计费模式？在理论利用中，业务与音讯流量有明确工夫关联的场景下，如：智能餐饮业务在午饭和晚饭时间段内，音讯量比拟集中，而闲时音讯量则较小，这种场景在连接数，音讯总量上应用按量计费的形式更加划算。 对于音讯流量业务安稳的场景，如：共享单车业务，音讯流量集中的工夫片段更小，每日音讯总量十分大，适宜TPS 包年包月的计费模式。 MQTT于4.29日正式公布的轻量级版本，能够满足客户业务规模与整体音讯量大，音讯可靠性要求不高，但业务连续性不受单条音讯发送失败而影响的场景，如在共享单车业务中，设施每秒中发一次定位音讯，供APP端生产订阅，单条音讯发送失败能够进行从新投递，并不会间接影响整体业务。采纳轻量级版本能够大幅升高应用老本。 对于价格 等同规格，价格是标准版的一半；性能差别 音讯保留工夫：无； 设施高低线告诉：无；规定治理：无；仅反对qos = 0 cleansession = ture版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：探秘RocketMQ源码——Series1：Producer视角看事务音讯 1. 前言Apache RocketMQ作为广为人知的开源消息中间件，诞生于阿里巴巴，于2016年捐献给了Apache。从RocketMQ 4.0到现在最新的v4.7.1，不论是在阿里巴巴外部还是内部社区，都博得了宽泛的关注和好评。 出于趣味和工作的须要，近期自己对RocketMQ 4.7.1的局部代码进行了研读，其间产生了很多困惑，也播种了更多的启发。 本文将站在发送方视角，通过浏览RocketMQ Producer源码，来剖析在事务音讯发送中RocketMQ是如何工作的。须要阐明的是，本文所贴代码，均来自4.7.1版本的RocketMQ源码。本文中所探讨的发送，仅指从Producer发送到Broker的过程，并不蕴含Broker将音讯投递到Consumer的过程。 2. 宏观概览RocketMQ事务音讯发送流程： 图1 联合源码来看，RocketMQ的事务音讯TransactionMQProducer的sendMessageInTransaction办法，理论调用了DefaultMQProducerImpl的sendMessageInTransaction办法。咱们进入sendMessageInTransaction办法，整个事务音讯的发送流程清晰可见： 首先，做发送前查看，并填入必要参数，包含设prepare事务音讯。 源码清单-1 public TransactionSendResult sendMessageInTransaction(final Message msg, final LocalTransactionExecuter localTransactionExecuter, final Object arg) throws MQClientException { TransactionListener transactionListener = getCheckListener(); if (null == localTransactionExecuter && null == transactionListener) { throw new MQClientException("tranExecutor is null", null); } // ignore DelayTimeLevel parameter if (msg.getDelayTimeLevel() != 0) { MessageAccessor.clearProperty(msg, MessageConst.PROPERTY_DELAY_TIME_LEVEL); } Validators.checkMessage(msg, this.defaultMQProducer); SendResult sendResult = null; MessageAccessor.putProperty(msg, MessageConst.PROPERTY_TRANSACTION_PREPARED, "true"); MessageAccessor.putProperty(msg, MessageConst.PROPERTY_PRODUCER_GROUP, this.defaultMQProducer.getProducerGroup());进入发送解决流程： ...

简介：5 月 15 日 成都站 | 云原生中间件 Meetup 凋谢报名！ 首期亮点速递美菜网如何在多语言等简单场景着落地 RocketMQ 以及如何保障产品稳定性和易用性、实现双活的计划。中型电商平台如何利用 Sentinel 进行限流降级，保障电商服务稳定性。Dubbo 3.0 对于拥抱云原生改革的思考和新版本提供的个性。Seata-golang 如何兼容 Java 版 Seata 的通信协议，为 Seata 减少了跨语言的个性。直播观看形式Bilibili 直播间：http://live.bilibili.com/22730538微信视频号：视频号中搜寻【阿里巴巴云原生】阿里云开发者社区：https://developer.aliyun.com/live/246663防疫须知：咱们珍视您和其余流动参会者的衰弱，依据疫情防控须要，近 14 天去过中高风险地区的开发者请勿报名。流动现场须要您被动出示绿码、进行体温测量并全程佩戴口罩，感谢您的配合。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：本文将 rocktmq-spring-boot 的设计实现做一个简略的介绍，读者能够通过本文理解将 RocketMQ Client 端集成为 spring-boot-starter 框架的开发细节，而后通过一个简略的示例来一步一步的解说如何应用这个 spring-boot-starter 工具包来配置，发送和生产 RocketMQ 音讯。 作者 | 辽天 起源 | 阿里巴巴云原生公众号 导读：本文将 rocktmq-spring-boot 的设计实现做一个简略的介绍，读者能够通过本文理解将 RocketMQ Client 端集成为 spring-boot-starter 框架的开发细节，而后通过一个简略的示例来一步一步的解说如何应用这个 spring-boot-starter 工具包来配置，发送和生产 RocketMQ 音讯。 在 Spring 生态中玩转 RocketMQ 系列文章： 《如何在 Spring 生态中玩转 RocketMQ？》《罗美琪和春波特的故事...》《RocketMQ-Spring 毕业两周年，为什么能成为 Spring 生态中最受欢迎的 messaging 实现？》本文配套可交互教程已登录阿里云知口头手实验室，PC 端登录 start.aliyun.com 在浏览器中立刻体验。 通过本文，您将理解到： Spring 的音讯框架介绍rocketmq-spring-boot 具体实现应用示例前言上世纪 90 年代末，随着 Java EE(Enterprise Edition) 的呈现，特地是 Enterprise Java Beans 的应用须要简单的描述符配置和死板简单的代码实现，减少了宽广开发者的学习曲线和开发成本，由此基于简略的 XML 配置和一般 Java 对象（Plain Old Java Objects）的 Spring 技术应运而生，依赖注入（Dependency Injection）, 管制反转（Inversion of Control）和面向切面编程（AOP）的技术更加敏捷地解决了传统 Java 企业及版本的有余。 ...

简介：随着 Serverless 在业界各云平台落地，阿里外部 Serverless 研发平台、各种研发模式也在业务中逐渐落地，热火朝天。在此契机下，淘系团队启动了轻店 Serverless 研发模式降级战斗，基于阿里团体底层设施建设、下层技术体系，解决在淘系轻店业务场景下碰到的系列问题，并借此推动现有前后端合作模式转变。 一、前言随着 Serverless 在业界各云平台落地，阿里外部 Serverless 研发平台、各种研发模式也在业务中逐渐落地，热火朝天。在此契机下，淘系团队启动了轻店 Serverless 研发模式降级战斗，基于阿里团体底层设施建设、下层技术体系，解决在淘系轻店业务场景下碰到的系列问题，并借此推动现有前后端合作模式转变。 二、背景轻店业务是淘系新型业务，目前处于摸索试错阶段，如何能以较低人力老本配合业务疾速试错，是团队以后须要思考的问题。Serverless 重要的特点之一“only focus your business”。因而，拥抱 Serverless，轻店业务势在必行。本篇次要介绍，Serverless 技术在轻店前端团队如何落地，以及如何推动轻店研发模式降级，晋升研发效率。在此基础上，同时摸索前端职能转变成为利用开发的可能性。 三、研发模式降级本文首先调研阿里团体内外 Serverless 现状，联合本身业务特点做技术选型；随后在轻店域内进行业务落地，在落地过程中逐渐落实以下能力：以 sidecar&bottle 作为底层撑持，以一体化研发模式联合公共服务层、原子能力层、根底 SDK 来晋升研发效率；最初通过轻店规范研发链路来保障业务稳定性；最终造成轻店 FaaS 体系，初步实现研发模式提效降级。 1. 技术现状阿里团体各 BU 过来一年里在 Serverless 畛域做了很多工作，次要集中在根底建设、研发模式、逻辑编排、稳定性建设、以及将 faas 链路买通并落地到 B 侧和 C 侧业务场景，如下图所示。各业务依赖的 Serverless 平台集中在 C 平台 / F 平台（PS：阿里外部 Serverless 平台）。 2. 技术选型以后阿里团体 Serverless 平台和 midway-faas 团队深度单干，定制了基于阿拉丁 FaaS 计划，依靠袋鼠为业务网关，承载申请散发的职责，并且有容灾、兜底等通用能力。袋鼠以天马体系（PS：指以对立模块标准为根底的搭建体系）为根底底座，然而轻店业务底层依赖装修体系。因而，咱们须要从新选型实现基于轻店场景的 faas 解决方案。除此之外，轻店业务外围依赖各种中台服务。这些中台服务大部分是以富客户端（PS：指集成了本地能力的二方包）模式提供，如何在 nodeFaaS 体系中应用富客户端，是咱们技术计划须要思考的重点。上面是 C 平台计划（PS：阿里外部的 Serverless 平台） 和 G 平台计划（PS：阿里外部的 Serverless 平台）的链路比照图。 ...

简介：网易游戏流式 ETL 建设实际及调优教训分享～ 网易游戏资深开发工程师林小铂为大家带来网易游戏基于 Flink 的流式 ETL 建设的介绍。内容包含： 业务背景专用 ETLEntryX 通用 ETL调优实际将来布局一. 业务背景网易游戏 ETL 服务详情网易游戏的根底数据次要日志形式采集，这些日志通常是非结构化或半结构化数据，须要通过数据集成 ETL 才能够入库至实时或离线的数据仓库。尔后，业务用户才能够不便地用 SQL 实现大部分数据计算，包含实时的 Flink SQL 和离线的 Hive 或 Spark。 网易游戏数据集成的数据流与大多数公司大同小异，次要有游戏客户端日志、游戏服务端日志和其余周边根底的日志，比方 Nginx access log、数据库日志等等。这些日志会被采集到对立的 Kafka 数据管道，而后经由 ETL 入库服务写入到 Hive 离线数据仓库或者 Kafka 实时数据仓库。 这是很常见的架构，但在咱们在需要方面是有一些比拟非凡的状况。 网易游戏流式 ETL 需要特点 首先，不同于互联网、金融等行业根本罕用 MySQL、Postgres 等的关系型数据库，游戏行业经常应用 MongoDB 这类 schema-free 的文档型数据库。这给咱们 ETL 服务带来的问题是并没有一个线上业务的精确的 schema 能够依赖，在理论数据处理中，多字段或少字段，甚至一个字段因为玩法迭代变更为齐全不同的格局，这样的状况都是可能产生的。这样的数据异构问题给咱们 ETL 的数据荡涤带来了比拟高的老本。 其次，也是因为数据库选型的起因，大部分业务的数据库模式都遵循了反范式设计，会刻意以简单内嵌的字段来防止表间的 join。这种状况给咱们带来的一个益处是，在数据集成阶段咱们不须要去实时地去 join 多个数据流，害处则是数据结构可能会非常复杂，多层嵌套非常常见。 而后，因为近年来实时数仓的风行，咱们也同样在逐渐建设实时数据仓库，所以复用现有的 ETL 管道，提取转换一次，加载到实时离线两个数据仓库，成为一个很天然的倒退方向。 最初，咱们的日志类型多且变更频繁，比方一个玩法简单的游戏，可能有 1,000 个以上的日志类型，每两周可能就会有一次发版。在这样的背景下 ETL 出现异常数据是不可避免的。因而咱们须要提供欠缺的异样解决，让业务能够及时得悉数据异样和通过流程修复数据。 日志分类及特点 为了更好地针对不同业务应用模式优化，咱们对不同日志类型的业务提供了不同的服务。咱们的日志通常分为三个类型：经营日志、业务日志和程序日志。 ...

作者 | 罗松（西流）起源 | 阿里巴巴云原生公众号 导读：本文将通过分析一个个具体的场景案例，以冀望给相干的游戏开发同学带来共鸣，同时也心愿能给非游戏行业的同学带来一些启发。 一、前言1. 游戏客户上云关注点游戏行业是一个富裕创意又竞争强烈的市场，被称为第九艺术。游戏客户上云次要关注以下 4 个方面： 疾速迭代，寰球部署疾速迭代是游戏行业的通用需要，包含开发效率、运维效率、架构解耦；同时游戏可能也会出海，所以也须要海内部署或寰球部署策略。 高并发、高弹性每个游戏上线时都会经验新开服、经营拉新等阶段，游戏自身也有日常峰谷，再加上偶然的流动经营，也会产生峰值，因而在游戏行业高并发高弹性也是一个通用需要。 稳固、牢靠、平安要保障游戏的公平性和用户的玩家体验，避免舞弊，所以须要保障游戏的稳固牢靠与平安。 数据、运维、老本管制游戏上线后，通过日志收集数据对用户行为进行剖析，依据剖析后果针对不同的玩家施行不同的运维策略，将经营重点放在两头的摇晃玩家上，从而做到精准定位、管制老本。 2. 意识函数计算下文将要介绍的案例次要与函数计算相干，因而在此先对阿里云 Serverless 产品——函数计算做一下简略介绍。 函数计算：只须要专一业务代码，面向函数极简编程（各种编程语言），丰盛的云产品间集成与事件驱动形式提供端到端解决方案。专一业务代码 如上图所示，对于游戏开发者来说，应用函数计算，就只须要抉择一个你最善于的代码，编写这段代码，上传到计算平台，就能够实现开发工作。之后能够通过 API/SDK 调用这个函数，也能够通过云产品事件源去触发函数。 上图是一个简略的例子，用 Java 函数写一个“Hello World”，把它设置成 Java8 的执行环境，256MB 的内存，设置完上传到函数计算，开发工作就实现了，之后被动调用函数即可，无需关注任何基础设施。 这里独自介绍一下“云产品事件源触发函数”。除了被动触发函数，还能够用云产品来触发。比方应用阿里云的对象存储 OSS，上传一个 zip 包到 OSS Bucket 的某个目录，心愿上传之后能够主动触发一个函数，而后这个函数能够把 zip 包主动进行解压，云产品事件源触发就能够实现这种成果。另外还有其余很多事件源，比方日志的事件源、 MNS 音讯事件源、定时触发事件源等。 100< 代码量面向函数极简编程，只须要关注外围代码。还反对各种编程语言，对开发者十分敌对，开发者能够选一个本人最善于的语言，写完后上传到函数计算即可。 100ms 极致弹性如果触发函数，同时过去 10 个、 100 个、1000 个甚至 1 万个申请都不必放心，函数计算会百毫秒级弹出执行环境，每个执行环境去执行函数逻辑代码，再把函数执行的后果返回，帮忙在线业务应答各种突发流量。 100% 资源利用率在计费方面，函数计算是按执行环境的内存和执行工夫计费，计费粒度可达毫秒级，只为申请产生的资源耗费买单，资源利用率达 100%，降低成本。 二、Serverless 游戏场景实际案例1. 高弹性战斗结算业务战斗结算是强 CPU 密集型，结算零碎每日须要大量的计算力，尤其是开服或者流动期间忽然涌入的大量玩家，导致须要的计算量霎时几倍增长，同时须要结算零碎保持稳定的延时来保障玩家的用户体验。 以 SLG 游戏或者回合制游戏场景为例，一场战斗完结后，为了用户体验，客户端须要后行结算，展现这一回合的后果，比方打赢了弹出胜利动画，打输了弹出失败动画。如果纯正依赖客户端，很可能会呈现客户端舞弊的状况（比方作弊器），所以最初的结算必定还是由服务器做结算。 随着游戏策动团队想法的减少，游戏越来越简单，比方 buff、debuff、暴击等等。随着游戏越来越好玩，结算零碎会越来越简单，游戏过程很可能会呈现卡顿景象，而最好的解决方案就是把战斗结算这一 CPU 密集型的逻辑抽离进去。这一计划也尤其实用于新开服、流动期间以及每日有日常峰谷的状况等。 ...

沙龙简介本次沙龙邀请了携程、中通的资深架构师他们在消息中间件的设计和实际上都有着丰盛的教训在沙龙上将会为大家分享教训，和大家独特学习交换 沙龙主题：《消息中间件核心技术揭秘与最佳实际》举办工夫：2020/12/12举办地点：上海市浦东新区国创核心 出品方信也科技布道师FTE（FINV technology evangelist）是一个酷爱技术摸索，并热衷于流传技术的团队通过一系列的技术沙龙与各种模式的分享交换让更多的人理解金融科技技术能力传递信也工程师们在科技上的钻研与深刻沉闷在技术圈内外 流动嘉宾曹东 曹东，现就职于携程游览，是框架架构部的资深架构师。负责音讯队列和监控。涉猎网络协议、web开发，对云原生相干技术感兴趣。 丁威 丁威，现就职于中通科技，是技术平台部资深架构师。同时也是《RocketMQ技术底细》联结作者、RocketMQ社区优良布道师、现负责中通科技技术平台部资深架构师、负责消息中间件、全链路压测、缓存、数据同步等，善于JAVA支流中间件畛域。 李乘胜 开源音讯零碎PMQ作者。目前负责信也科技音讯零碎，微服务相干的工作 流动亮点亮点1： 零距离接触外企国企民企上市公司等不同格调大咖，大咖来自携程游览、中通科技、信也等不同类型公司；零距离接触大咖 亮点2： 全方位探讨消息中间件外围原理揭秘与最佳实际，案例详实，干货满满 亮点3： 理解行业境况，用一场流动拓宽人脉，播种教训，积攒人脉 流动议程 名额有限快来报名！ 1.报名形式：扫描下方二维码进行报名2.报名须知：凭流动行【电子票】验票签到入场 往期技术沙龙状况 2019年12月21日一贯低调的信也技术首次对外的亮相邀请到了金融科技业内大咖和骨干专家独特探讨了金融科技的最新落地场景和案例，以及行业改革与翻新 2020年7月18日邀请了来自eBay、安全、iHerb、信也等不同类型公司的不同格调大咖大家分享K8S在公司内的落地教训，和大家独特学习交换。

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。 以后已有泛滥国内外大型互联网和传统行业公司采纳 Apache Pulsar，案例散布在人工智能、金融、电信运营商、直播与短视频、物联网、批发与电子商务、在线教育等多个行业，如美国有线电视网络巨头 Comcast、Yahoo！、腾讯、中国电信、中国移动、BIGO、VIPKID 等。 对于 Pulsar SummitPulsar Summit 是由 StreamNative 组织的 Apache Pulsar 社区年度盛会，它将散布在世界各地的 Apache Pulsar 我的项目 Contributor、Commiter 和各企业 CTO/CIO、开发者、架构师、数据科学家，以及音讯和流计算社区的精英招集在一起。于此盛会，大家分享实践经验、交换想法、探讨对于 Pulsar 我的项目和社区的常识，切磋互动。 Pulsar Summit Asia 旨在汇集亚洲地区 Pulsar 开发者和贡献者，促成 Apache Pulsar 在亚洲地区的倒退。Pulsar Summit Asia 2020 将于 11 月 28-29 日以线上直播模式发展。 从明天开始，咱们将陆续对 Pulsar Summit Asia 2020 中英文专场及分论坛议题予以具体介绍，帮忙大家更好地理解行将到来的 Pulsar 社区盛会分享什么、有哪些亮点。明天为大家带来 Pulsar Summit Asia 2020 主题演讲的信息。 备注：上面演讲工夫及内容不能保障为最终版本，请关注 Pulsar Summit Asia 2020 官网获取最新动静 https://pulsar-summit.org/en/event/asia-2020 。 ...

主流消息中间件 架构模式 Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。 架构模式 依赖zookeeper RocketMQ是阿里开源的消息中间件，目前也已经 孵化为Apache顶级项目，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于kafka，它对消息的可靠输出及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景 集群拓扑 RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。 集群架构