首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

腾讯开源万亿分布消息中间件 TubeMQ

beMQ 是腾讯在 2013 年自研的分布消息中间件系统,专注服务大数据场景下海量数据的高性能存储和传输,经过近 7 年上万亿的海量数据沉淀,目前日均接入量超过 25 万亿条。...变更及查询实现了完整的自动化闭环管理,减轻了系统维护的复杂度; 服务器侧消费负载均衡 Tube MQ 采用的是服务侧负载均衡的方案,而不是客户端侧操作,提升系统的管控能力同时简化客户端实现,更便于均衡算法升级; 系统行锁操作...对于 Broker 消息读写中存在中间状态的并发操作采用行锁,避免重复问题; Offset 管理调整 Offset 由各个 Broker 独自管理,ZK 只作数据持久化存储用(最初考虑完全去掉 ZK...依赖,考虑到后续的功能扩展就暂时保留); 消息读取机制的改进 Tube MQ 采用的是消息随机读取模式, 同时为了降低消息时延又增加了内存缓存读写, 对于带 SSD 设备的机器, 增加消息滞后转 SSD...消费时延分级保证、消费限流控制,以及数据拉取频率控制等; 系统安全管控 根据业务不同的数据服务需要,以及系统运维安全的考虑,Tube MQ 系统增加了 TLS 传输层加密管道,生产和消费服务的认证、授权,以及针对分布式访问控制的访问令牌管理

1.5K60

腾讯万亿分布消息中间件TubeMQ正式开源

TubeMQ是腾讯在2013年自研的分布消息中间件系统,专注服务大数据场景下海量数据的高性能存储和传输,经过近7年上万亿的海量数据沉淀,目前日均接入量超过25万亿条。...系统行锁操作 对于Broker消息读写中存在中间状态的并发操作采用行锁,避免重复问题; 5. ...消息读取机制的改进 Tube MQ采用的是消息随机读取模式,同时为了降低消息时延又增加了内存缓存读写,对于带SSD设备的机器,增加消息滞后转SSD消费的处理,解决消费严重滞后时吞吐量下降以及SSD磁盘容量小...系统安全管控 根据业务不同的数据服务需要,以及系统运维安全的考虑,Tube MQ系统增加了TLS传输层加密管道,生产和消费服务的认证、授权,以及针对分布式访问控制的访问令牌管理,满足业务和系统运维在系统安全方面的需求...采用连接复用模式,减少连接资源消耗;通过逻辑分区构造,减少系统对文件句柄数的占用,通过服务器端过滤模式,减少网络带宽资源使用率;通过剥离对Zookeeper的使用,减少Zookeeper的强依赖及瓶颈限制; 11

1.1K72
您找到你想要的搜索结果了吗?
是的
没有找到

抗千万调用的电商服务架构实现

电商是典型的促销拉动式场景,也是价格战驱动的场景。618和11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下,对秒杀、抢购是很热衷的玩法。 促销式的拉动对系统的挑战是什么呢?...大型电商系统的架构 基础架构层 这层实际上是中间件和服务,包括MQ的消息、Job的调试中心、sso联合登陆,还有发消息的,分布式的文件存储,用户上传的一些图片等等,除此之外还有应用监控的整个体系、自动发布...消息队列的应用 应用消息队列是做服务解耦的好方法。但也要考虑消息失败和重试的场景,需要来做一些补偿处理。...一般很多的场景能做到的是最终一致性,大型的电商系统和金融系统场景非常不一样,在设计分布式系统时,这是常用的方式。 高可用的架构设计 高可用的架构设计,对于电商来说,已经是最基本的要求了。...从app里用户的每一个操作,这个操作经过网络、服务层、中间件,整个链路要可以监控。对于快速的定位问题是非常有帮助的,尤其是移动电商性能的优化,第一步就是埋点。

2.3K20

钉钉的开工利是,会成为企业市场的11吗?

正是因为此,钉钉选择从元宵节后第一个工作日到月底的这个时间做开工利是活动,来吸引中小企业。不过,钉钉这个活动不能看成是一次简单的促销,它很可能会在企业市场形成双11效应,引发连锁反应。...开工利是会成企业市场的11 2009年,天猫前身的淘宝在单身节这一天决定来一场促销,规则很简单就是打五折,此后这个活动成长为一个庞然大物,11不再只是天猫的促销节,而是整个零售业的促销节。...比交易额本身更重要的是,11直接推动了电商在中国的普及和配套的技术、物流、金融等等服务的成熟。...运营驱动的阿里是比较擅长造节的,钉钉的开工利是活动虽然名字不叫11,但本质是一样的:通过促销和造节,来促进用户使用产品服务,我想它未来一定会像企业的开工利是一样成为约定俗成的玩法,一年一年地玩下去。...长期来看,钉钉开工利是这个活动,对于行业的价值有望像11一样:一是促进更多中小企业应用移动智能办公应用,人财物事上钉钉,提高效率;二是促进企业服务市场的生态繁荣,就像11对物流、金融、技术的推进一样

18.1K40

前1号店技术总监黄哲铿揭秘:微服务架构在千万级别日调用量、亿别海量数据场景下的应用实践

上周,前1号店技术总监、海尔农业电商CTO,《技术管理之巅》作者黄哲铿为大家带来了一场关于微服务架构的分享,包含了微服务架构在千万级别日调用量、亿别海量数据场景下的应用实践;从领域驱动设计、服务依赖治理...电商是促销拉动式的场景,也是价格战驱动的场景。618和11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下,对秒杀、抢购是很热衷的玩法。 ? 促销式的拉动对系统的挑战是什么呢?...基础架构层 这层实际上是中间件和服务,包括MQ的消息、job的调试中心、sso联合登陆,还有发消息的,分布式的文件存储,用户上传的一些图片等等,除此之外还有应用监控的整个体系、自动发布的框架,支持到AB...消息队列的应用 消息队列的应用,是做服务解耦的好方法。也要考虑消息失败和重试的场景,需要来做一些额外补偿来防止数据丢失。还有一个机制是数据的校验和补偿。...很多的场景能做到的是最终一致性,大型的电商系统和金融系统场景非常不一样,在设计分布式系统时,这是常用的方式。在电商中大多数情况只要实现最终一致性就可以了。

1.1K10

前1号店技术总监黄哲铿揭秘:微服务架构在千万级别日调用量、亿别海量数据场景下的应用实践

上周,前1号店技术总监、海尔农业电商CTO,《技术管理之巅》作者黄哲铿为大家带来了一场关于微服务架构的分享,包含了微服务架构在千万级别日调用量、亿别海量数据场景下的应用实践;从领域驱动设计、服务依赖治理...电商是促销拉动式的场景,也是价格战驱动的场景。618和11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下,对秒杀、抢购是很热衷的玩法。 ? 促销式的拉动对系统的挑战是什么呢?...基础架构层 这层实际上是中间件和服务,包括MQ的消息、job的调试中心、sso联合登陆,还有发消息的,分布式的文件存储,用户上传的一些图片等等,除此之外还有应用监控的整个体系、自动发布的框架,支持到AB...消息队列的应用 消息队列的应用,是做服务解耦的好方法。也要考虑消息失败和重试的场景,需要来做一些额外补偿来防止数据丢失。还有一个机制是数据的校验和补偿。...很多的场景能做到的是最终一致性,大型的电商系统和金融系统场景非常不一样,在设计分布式系统时,这是常用的方式。在电商中大多数情况只要实现最终一致性就可以了。

1.1K20

当我们谈论秒杀时我们要做什么?

秒杀业务业务特点 服务承载的访问压力大 瞬时流量突增:业务促销活动在特定时间开启,大量用户请求等待活动开启后瞬间涌入 抢购脚本带来压力:灰产通过抢购脚本薅羊毛,一方面带来额外的系统压力,另一方面影响抢购活动公平性...缓存层:数据读取加速 在抢购业务中,对商品库存数量的更改主要通过数据库进行,但是由于读取流量过大,一般需要通过两缓存的机制进行优化,即:Java服务进程内本地缓存-->分布式缓存服务-->数据库服务。...技术保障 业务全链路压测 全链路压测是阿里2013年在11压力之下被逼出来的技能,由于线上线下环境多少都会有些不同,很多问题只有在实际生产环境才能暴露,对于秒杀类业务,线上压测也能够实际评估出系统的真实承载力...比如阿里张瑞说的: “在零点前有一个倒计时环节,连线杭州光明顶作战指挥室,逍遥子会为大家揭幕201511启动,然后直接切换到我们的媒体大屏,所以对GMV数字的要求基本上是零延迟,这个挑战有多大不言而喻...我们可以做些什么 阿里11的目的在于:去库存、提升影响力和拉新,而对研发和基础架构来说则是保持技术领先的年度演习。

6.7K30

蚂蚁金服11.11:支付宝和蚂蚁花呗的技术架构及实践

每年“11”都是一场电商盛会,消费者狂欢日。今年11的意义尤为重大,它已经发展成为全世界电商和消费者都参与进来的盛宴。...分布式数据架构 支付宝在2015年十一当天的高峰期间处理支付峰值8.59万笔/秒,已经是国际第一大系统支付。...以下是分布式事务框架的流程图: ? 实现: 一个完整的业务活动由一个主业务服务与若干从业务服务组成。 主业务服务负责发起并完成整个业务活动。 从业务服务提供TCC型业务操作。...在之前的架构中,系统的秒处理能力无法有效衡量,通过简单的引流压测无法得到更加准确、可信的数据。立足于金融云,系统很快通过全链路压测得到了每秒处理4w笔支付的稳定能力。...为了保证蚂蚁花呗11期间的授信资金充足,在金融云体系下搭建了机构资产中心,对接支付清算平台,将表内的信贷资产打包形成一个一定期限的资产池,并以这个资产池为基础,发行可交易证券进行融资,即通过资产转让的方式获得充足资金

4.2K60

余额宝技术架构及演进

中间层就是采用小型机,其中 KCXP 和 KCBP 是金证公司的消息中间件和业务中间件。往上前端是前置解析是用的 WebLogic,负载均衡用的硬件负载均衡。 ?...另外当年要参加支付宝这边的 11 活动,以当时的系统处理能力来讲,肯定是做不到的。 二期云端架构 基于这些原因,需要对一期的系统做优化,怎么优化?...目前来讲应对春节、11、国庆长假等场景,系统都能稳定应对这些。 ?...比如对于在线交易,可以采用经过阿里支付宝验证过的 OB,专门用于解决金融分布式关系数据库的解决方案; 对于批量结算,可以继续沿用多年来在余额宝已经用的很娴熟的 RDS 集群。...异步调用 异步调用主要靠消息中间件金融系统对消息中间件的可靠性要求非常高,这块我们还是沿用传统思路,并不想采用开源解决方案去填那些坑,更多考虑采用成熟金融消息中间件来做这件事情。 ?

1.2K50

数据泄露、平台“崩瘫”……2022企业如何安全布局私域电商?

像前段时间,某小程序推出“爆品抢购”活动活动一开始其小程序商城就立马出现“白屏现象”,导致商家整个线上业务直接中断4个小时,客户体验遭遇滑铁卢。...01 腾讯企业防护能力 稳若磐石,守护私域业务安全 腾讯「云Mall」基于腾讯云部署,拥有海量的服务架构,通过CDN负载均衡、容器云平台、金融中间件、微服务架构和金融分布式数据库等技术,能够全方位保障流量层的安全...确保品牌商家在开展抢购、秒杀、裂变等日常活动时,以及在11大促期间都能安全无忧,生意稳定经营。 ?...防止系统崩溃 在大规模促销前,为了避免可能存在的黑客发动DDOS&CC攻击和中台存在的性能瓶颈问题,腾讯「云Mall」为企业私域运营提供基础及深度安全诊断,及时发现系统漏洞;通过对代码进行加密加固、提供...DDOS高防包和高防IP,有效拦截黑客攻击;通过设备安全检测,实时异常监控等及时发现系统安全问题,并高效修复和优化业务系统;能够提高企业优化小程序系统性能的效率,避免活动页面白屏、下单失败等情况影响活动进行

2.6K40

揭秘:2018阿里11秒杀背后的技术

二、阿里11背后的技术 ? 1. 云计算 利用云计算弹性能力,支撑交易峰值每秒32.5万笔、支付峰值每秒25.6万笔的混合云弹性架构。 2. 分布消息引擎 在11当天实现万亿消息流转。 3....物流技术 菜鸟通过包裹预测、供应链入库、订单下沉、订单路由调度、电子面单及智能分单,以及末端小件员,涉及十亿包裹的11之战。...总之,11将涉及:基础设施、存储、中间件、云计算、业务架构、大数据、认知计算与人工智能、交互技术等技术领域。...充分利用消息中间件削峰 这里有相关的阿里消息中间件(Notify和MetaQ),以及开源的(ActiveMQ、Kafka等)。...现在对数据库的拆分,都是利用数据库层中间件(淘宝 tddl),来进行无缝对数据库的侵入设计。 除此以外还会涉及到分布式小文件存储以及搜索引擎,以及服务器集群监控等技术。

4.6K30

无例可循,双十一倒逼出中国互联网「三高架构」

随着「双十一」进入第 14 个年头,这一现象的标志性活动在很大程度上已经融入国人的日常生活,因而显得不再那么特殊——打折促销天天有,满减秒杀是基操,消费者已经习惯了随时随地都能下单,同城快递隔天就到。...但随着直播秒杀成为一种常规化的营销手段,为了满足众多商家在较长的促销周期内随机性发起的千千万万的秒峰值,需要有大量的机器成本的投入。...高可用架构演进 这些年来,随着业务特点和规模的发展变化,尤其在历届双十一的极端需求倒逼之下,例如从应对 0 点的单一流量洪峰到满足多平台支付需求和效率,支付宝完成了数次大的架构演进,逐渐形成了一套包括金融分布式交易...第三阶段:异地多活架构,流量弹性伸缩 金融产品对稳定性有极高的要求,需要加速实现金融异地多活的高可用架构。...正是因为一次次双十一的倒逼创新,支付宝的实践证明在金融中间件、数据库和云计算平台的支持下,分布式架构完全能够胜任复杂、高要求的金融交易。

3.1K20

千万调用量微服务架构实践

电商是促销拉动式的场景,也是价格战驱动的场景。618和11都是典型的促销活动。其实都是在抢用户、扩市场占有率。在这样的场景之下,对秒杀、抢购是很热衷的玩法。 ? 促销式的拉动对系统的挑战是什么呢?...基础架构层 这层实际上是中间件和服务,包括MQ的消息、job的调试中心、sso联合登陆,还有发消息的,分布式的文件存储,用户上传的一些图片等等,除此之外还有应用监控的整个体系、自动发布的框架,支持到AB...消息队列的应用 消息队列的应用,是做服务解耦的好方法。也要考虑消息失败和重试的场景,需要来做一些额外补偿来防止数据丢失。还有一个机制是数据的校验和补偿。...很多的场景能做到的是最终一致性,大型的电商系统和金融系统场景非常不一样,在设计分布式系统时,这是常用的方式。在电商中大多数情况只要实现最终一致性就可以了。...从app里用户的每一个操作,这个操作经过网络、服务层、中间件,整个链路要可以监控。对于快速的定位问题是非常有帮助的,尤其是移动电商性能的优化,第一步就是埋点。 在网络这一层,还有网关的接入。

1.6K50

【金猿信创展】恒生电子——全栈式信创解决方案,助力金融信创行稳致远

核心技术及产品突破 1、分布式微服务中间件Light-JRES Light-JRES是面向金融领域的企业应用快速开发平台和多系统融合平台,既减轻对基础设施的依赖,又从业务上具备可复用、可扩展、高安全的特性...JRES中间件是实现对通用技术组件的服务化,譬如:分布式缓存、消息队列、分布式事务等等,通过应用共享以及多租户隔离实现技术组件最大程度复用,降低系统的资源消耗让技术组件和业务公共模块下沉,从而做到支持业务的快速创新和迭代...2、分布式低延时中间件Light-LDP Light-LDP是具有集低延时、分布式解耦、灵活开放等特点的开发平台,支持金融机构微秒业务应用,主要面向券商自营、券商资管以及券商机构业务的策略交易、算法交易...3、金融分布式数据库LightDB LightDB是一款支持在线事务处理与在线分析处理的融合型分布式数据库,具备SQL兼容性高、容量弹性伸缩、金融高可用、现代硬件融合、纯内存计算等核心特性,适用于对可用性...LightDB具有“更快、更稳、更懂金融”的企业特性:采用单机分布式一体化架构,同时支持集中式和分布式部署,在长时间高负载压测下抖动很低;性能方面,在同机房高可用信创软硬件下、单节点进行证券典型订单TPS

91830

通过双十一等项目实践看架构技术

每年“ 11”都是一场电商盛会,消费者狂欢日。今年 11 的意义尤为重大,它已经发展成为全世界电商和消费者都参与进来的盛宴。...而对技术人员来说,双十一无疑已经成为一场大考,考量的角度是整体架构、基础中间件、运维工具、人员等。...以下是分布式事务框架的流程图: ? 实现: 一个完整的业务活动由一个主业务服务与若干从业务服务组成。 主业务服务负责发起并完成整个业务活动。 从业务服务提供 TCC 型业务操作。...在之前的架构中,系统的秒处理能力无法有效衡量,通过简单的引流压测无法得到更加准确、可信的数据。立足于金融云,系统很快通过全链路压测得到了每秒处理 4w 笔支付的稳定能力。...为了保证蚂蚁花呗 11 期间的授信资金充足,在金融云体系下搭建了机构资产中心,对接支付清算平台,将表内的信贷资产打包形成一个一定期限的资产池,并以这个资产池为基础,发行可交易证券进行融资,即通过资产转让的方式获得充足资金

2K30

盘点电商大战背后的技术力量支撑

『目标』保证促销规则支持分时段设置,多活动可叠加,促销系统中数据量超过商品信息系统的前提下,促销内容会根据执行效果快速调整,以强大的促销系统,保证有序的促销活动,使促销系统承担营销功能。...[未来关注于业务层面的梳理与整合,逐步回收适用于活动模型的其他“类促销”业务。] step 4 : 完善促销系统查询服务,使其具备更强大的数据处理能力和更好的性能表现。...Session共享、分布式调用链、Redis分片存储、数据库的分库分表中间件、统一配置管理和流控; 平台方面:运维监控平台,持续集成平台,大数据分析平台;以及针对安全的风控系统等。...方向四——关于系统保障 『准备一:提高系统负载能力』 step 1 : 根据历史数据对11的流量进行预估,细化到每个系统的PV、UV、峰值TPS,要求每个系统要努力达到这些指标; step 2 :对目前系统压力...分布式异步消息队列服务器可在宕机后确保消息不丢失,异步系统有重试机制,从而提高系统可用性、健壮性和扩展性。

13.4K30

CKafka系列学习文章 - 对比RabbitMQ、RocketMQ、TDMQ-CMQ、kafka和Ckafka(二)

万QPS 读写12万QPS 同步算法 ISR(Replica) ISR(Replica) GM 同步写 Raft 可用性 可用性很高,主从自动切换,腾讯云消息服务承诺可用性99.95% 可用性高,主从自动切换...,故障情况极少发生 可靠性低;Broker 只有异步刷盘机制并主备只有异步复制,可能会导致丢失部分消息 可靠性高;发送消息时,指定消息为持久化就会写入到磁盘 可靠性高;Broker 同步写,主备都写成功才返回成功...Ckafka和CMQ都作为消息中间件都支持集群部署、高吞吐量、强一致等特性,那这两款产品最主要的区别是什么,分别更适合哪些场景使用?...在这些地方,Ckafka非常好用 实时处理网站活动(PV,搜索,用户其他活动等) 完美的“日志收集中心” 大数据入口和连接器 image.png 2、TDMQ-CMQ 消息队列 CMQ 版(TDMQ...for CMQ,简称 TDMQ CMQ 版)是一种分布消息队列服务,它具有可靠的、基于消息的异步通信机制,能够将分布式部署的不同应用(或同一应用的不同组件)中的信息传递,存储在可靠有效的消息队列中,防止消息丢失

4.3K74

vivo商城促销系统架构设计与实践-概览篇

促销模型不够抽象,维护混乱,没有独立的活动库存; 2. 混乱的活动共融互斥关系管理,缺乏统一的促销计价能力。...面对新品发布、11大为客户等大流量场景,如何满足高并发场景下的高性能要求。 面对来自上游业务方的不可信调用,以及下游依赖方的不可靠服务等复杂系统环境,如何提升系统整体的稳定性,保障系统的高可用。...如活动编辑后的缓存处理、资源预占后的消息同步、拼团状态流转的消息通知等等。...监控和告警 通过配置日志平台的错误日志报警、调用链的服务分析告警,再加上公司各中间件和基础组件的监控告警功能,让我们能够第一时间发现系统异常 四、踩过的坑 4.1 Redis SCAN命令使用 在Redis...参照优秀的开源热点缓存框架,定制化扩展出一整套热点解决方案,支持热点探测 、本地缓存 、集群广播以及热点预热功能,做到准实时热点探测并将热点Key通知实例集群进行本地缓存,极大限度避免大量重复调用冲击分布式缓存

10.4K11

余军:分布式数据库在金融行业的创新实践

Google Spanner F1 - 第一个真正意义上 NewSQL 数据库 全球分布式关系型数据库,数十万机器组成一个超大的数据库集群。...基于 2014 年 Stanford 工业分布式一致性协议实现 Raft 博士论文,已成为事实工业标准。...OLTP - 直销金融:营销活动平台 TiDB 的解决之道: 面向业务应用侧,完全采用了兼容 MySQL 的协议,应用迁移低成本,低风险,且迁移周期极短,满足 了用户的周活动间隔的变更窗口要求。...OLAP - 交易监控:实时交易监察与监控平台 TiDB 的解决之道: 利用消息中间件,将交易系统的交易记录和撮合日志,流式写入 TiDB,利用 TiDB 的分布式存储,高性能 数据写入和弹性存储。...OLAP - 风控:实时风控 TiDB 的解决之道: 风控数据通过信息中间件写Hive/Hadoop(历史库/历史分析) TiDB的分布式存储引擎架构,非常轻松地应对海量风控数据的导入,存储和查询处理

1.8K102

EdgeOne 在多领域的创新应用与实践

例如电商平台在举行大型促销活动时,往往面临着刷单和网站性能瓶颈的双重挑战,针对这个艰巨的任务,EdgeOne的引用能否成功支撑得起来么?...优势汇总如下: 防刷单:EdgeOne的智能分析系统能够识别并阻止异常流量,保护促销活动的公平性。...电商行业的促销挑战   针对这个挑战,如果能够完美应付,那它就是最契合的服务。因为电商零售行业会经常举办各种促销活动,如11、黑五等各种高并发活动。...同时,EdgeOne 的反欺诈技术可以有效防止刷单等恶意行为,保护促销活动的公平性,想想具有这方面极致的性能跟服务,这不是妥妥的电商领域的左膀右臂,不二之选么。...同时,EdgeOne 的反欺诈技术帮助该平台识别并阻止了大量刷单行为,确保了促销活动的公平进行,相比这点,很多平台没有使用该服务或者集成其他应用服务的就没这么顺畅了。

10421
领券