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

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

二、阿里11背后的技术 ? 1. 云计算 利用云计算弹性能力,支撑交易峰值每秒32.5万笔、支付峰值每秒25.6万笔的混合云弹性架构。 2. 分布式消息引擎 在11当天实现万亿级消息流转。 3....总之,11将涉及:基础设施、存储、中间件、云计算、业务架构、大数据、认知计算与人工智能、交互技术等技术领域。...三、11秒杀架构设计思路 秒杀系统特点是并发量极大,但实际秒杀成功的请求数量却很少,所以如果不在前端拦截很可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时。...前端设计优化 页面静态化:将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素,通过CDN来抗峰值。 禁止重复提交:用户提交之后按钮置灰,禁止重复提交,防止一秒钟内多次写入数据库。...利用缓存应对读请求:比如11秒杀抢购,是典型的读多写少业务,大部分请求是查询请求,所以可以利用缓存分担数据库压力。

4.6K30

11最惊险一幕刚刚曝光

这次11前的突袭攻击,就出现在范禹闲庭信步走出“光明顶”时——11核心作战室内没人察觉异常。 内部工程师把这种偷袭演练与马斯克SpaceX那次知名的“事故逃逸”演习类比。...你听过混沌工程? Chaos Engineering,混沌工程。...随后的几年里,Netflix还将混沌猴子在GitHub上开源分享,并指出这种随机故障测试,对测试分布式系统的稳定性传统方式难以超越的优势。...阿里集团CTO程立就回忆说,2009年第一次11,因为是淘宝商城临时决定搞的活动,技术侧还不太有感觉。...内容涵盖在 11 背景下阿里技术架构多年来的演进,如何确保稳定性这条 11 生命线的安全和可靠,技术和商业交织发展的历程,无线和互动的持续创新与突破,以及对商家的赋能和生态的促进与繁荣。

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

架构师眼中的高并发架构

服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。...大致需要用到的服务器架构如下: 服务器 均衡负载(如:nginx,阿里云SLB) 资源监控 分布式 数据库 主从分离,集群 DBA 表优化,索引优化,等 分布式 nosql 主从分离,集群 主从分离,集群...服务器架构图: 说明: 场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618,11,等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中...,分布式数据库,nosql主从集群,如:用户服务、订单服务; 消息队列 秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求 场景:定时领取红包,等 ?...如: 自动弹窗签到,11跨0点的时候并发请求签到接口 11抢红包活动 11订单入库 等 设计考虑: 逆向思维,压力在数据库,那业务接口就不进行数据库操作不就没压力了 数据持久化是否允许延迟?

1.4K50

Github霸榜多时,原来是阿里技术官的千亿级并发系统设计手册上线了

前言:自2009年第一个“11”诞生,1111年的嬗变,见证中国迈向消费大国的坚定步伐。随后伴随着中国互联网的爆发式增长,国内社会不断变革着的消费与沟通方式,成熟的消费互联网生态体系已经成型。...那么如此大批的促销活动涌现,对于「秒杀」这个词也越来越频繁地出现在我们的生活里。...在如此的大环境下,不仅是头部电商公司,××多、×东,乃至于各种街、×会、×品等,以及一些老牌的传统企业,比如×宁、×美等,也紧跟着安排了各类秒杀活动。...购票软件也是一样的逻辑,1趟火车只有2000张票,同时有成千上万人同时在网站上抢票,看到这里,你是否对于这类业务的难做了一些了解。...一位在编程界摸打滚爬10余年的程序员,希望能给你带来帮助由于文章篇幅的限制小编就用截图的方式给大家总览目录基础篇高并发系统架构分层数据库篇池化技术数据库优化方案缓存篇缓存:消息队列篇消息队列消息队列分布式服务篇系统架构微服务架构维护篇服务端监控要怎么做

7.6K50

架构师眼中的高并发架构

服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。...大致需要用到的服务器架构如下: 服务器 均衡负载(如:nginx,阿里云SLB) 资源监控 分布式 数据库 主从分离、集群 DBA表优化、索引优化等 分布式 NoSQL 主从分离、集群 主从分离、集群...服务架构图 说明: 场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618、11等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中...以上例子是一个相对简单的高并发架构,并发量不是很高的情况可以很好的支撑,但是随着业务的壮大,用户并发量增加,我们的架构也会进行不断的优化和演变,比如对业务进行服务化,每个服务自己的并发架构,自己的均衡服务器...如: 自动弹窗签到,11跨0点的时候并发请求签到接口 11抢红包活动 11订单入库等 设计考虑: 逆向思维,压力在数据库,那业务接口就不进行数据库操作不就没压力了 数据持久化是否允许延迟?

1.3K60

大型网站架构系列:电商网站架构案例

大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。...也可以货到付款; 用户购买时可以在线与客服沟通; 用户收到商品后,可以给商品打分,评价; 目前有成熟的进销存系统;需要与网站对接; 希望能够支持3~5年,业务的发展; 预计3~5年用户数达到1000万; 定期举办11...,12,三八男人节等活动; 其他的功能参考京东或国美在线等网站。...商品打分评价 商品评论 目前有成熟的进销存系统 对接进销存 属于约束条件对接时要考虑数据一致性,鲁棒性 支持3~5年,业务的发展 属于约束条件伸缩性,可扩展性 3~5年用户数达到1000万 约束条件 举办11...,12,三八男人节等活动 活动管理,秒杀 突增访问流量(可伸缩)实时性要求(高性能) 参考京东或国美在线 参考条件 以上是对电商网站需求的简单举例,目的是说明(1)需求分析的时候,要全面,大型分布式系统重点考虑非功能需求

5.2K70

架构师眼中的高并发架构

服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。...大致需要用到的服务器架构如下: 服务器 均衡负载(如:nginx,阿里云SLB) 资源监控 分布式 数据库 主从分离,集群 DBA 表优化,索引优化,等 分布式 nosql 主从分离,集群 主从分离,集群...说明: 场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618,11,等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中...,分布式数据库,nosql主从集群,如:用户服务、订单服务; 消息队列 秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求 场景:定时领取红包,等 服务器架构图: ?...如: 自动弹窗签到,11跨0点的时候并发请求签到接口 11抢红包活动 11订单入库 等 设计考虑: 逆向思维,压力在数据库,那业务接口就不进行数据库操作不就没压力了 数据持久化是否允许延迟?

1.6K20

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

每年“11”都是一场电商盛会,消费者狂欢日。今年11的意义尤为重大,它已经发展成为全世界电商和消费者都参与进来的盛宴。...系统的复杂度越来越高,以前按照点的伸缩性架构无法满足要求,需要我们一套整体性的可伸缩方案,可以按照一个单元的维度进行扩展。...分布式数据架构 支付宝在2015年十一当天的高峰期间处理支付峰值8.59万笔/秒,已经是国际第一大系统支付。...以下是分布式事务框架的流程图: ? 实现: 一个完整的业务活动由一个主业务服务与若干从业务服务组成。 主业务服务负责发起并完成整个业务活动。 从业务服务提供TCC型业务操作。...为了保证蚂蚁花呗11期间的授信资金充足,在金融云体系下搭建了机构资产中心,对接支付清算平台,将表内的信贷资产打包形成一个一定期限的资产池,并以这个资产池为基础,发行可交易证券进行融资,即通过资产转让的方式获得充足资金

4.2K60

支付宝架构师眼中的高并发架构

服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。...大致需要用到的服务器架构如下: 服务器 均衡负载(如:nginx,阿里云SLB) 资源监控 分布式 数据库 主从分离,集群 DBA 表优化,索引优化,等 分布式 nosql 主从分离,集群 主从分离,集群...说明: 场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618,11,等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中...,分布式数据库,nosql主从集群,如:用户服务、订单服务; 消息队列 秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求 场景:定时领取红包,等 服务器架构图: ?...如: 自动弹窗签到,11跨0点的时候并发请求签到接口 11抢红包活动 11订单入库 等 设计考虑: 逆向思维,压力在数据库,那业务接口就不进行数据库操作不就没压力了 数据持久化是否允许延迟?

88420

支付宝架构师眼中的高并发架构

服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。 ...大致需要用到的服务器架构如下: 服务器 均衡负载(如:nginx,阿里云SLB) 资源监控 分布式 数据库 主从分离,集群 DBA 表优化,索引优化,等 分布式 nosql 主从分离,集群 主从分离,集群...: 说明: 场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618,11,等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中...,分布式数据库,nosql主从集群,如:用户服务、订单服务; 消息队列 秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求 场景:定时领取红包,等 服务器架构图: 说明: 场景中的定时领取是一个高并发的业务...如: 自动弹窗签到,11跨0点的时候并发请求签到接口 11抢红包活动 11订单入库 等 设计考虑: 逆向思维,压力在数据库,那业务接口就不进行数据库操作不就没压力了 数据持久化是否允许延迟?

1.1K20

看完这个“秒杀”设计方案!我有点慌了

方案二 利用我们分布式中限流、网关等知识,将请求层层筛选,降低最后连接到数据库的请求。...如果到这一步还是很多请求压到数据库势必撑不住,那么可以采取服务限流、服务降级等措施,进行削峰处理。...一方面关注数据库与缓存的一致性,另一方面关闭超时未支付的订单,当订单提交之后交给任务队列,生成订单、修改数据库、做好持久化工作。 架构图如下(可点击查看大图): ?...也可以像方案二那样逐层过滤请求,这种业务场景和双十一相同?如果像 11 那样,想尽可能多地卖出商品,那么就不像秒杀了。...为了保证一致性,还要能够扛得住像 11 这样的大规模并发访问,那么,应该怎么做呢? 使用秒杀这样的解决方案基本上不太科学了。这个时候就需要认认真真地做高并发的架构和测试了。

1.4K20

架构师眼中的高并发架构

01 服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务。...大致需要用到的服务器架构如下: 服务器 均衡负载(如:nginx,阿里云SLB) 资源监控 分布式 数据库 主从分离,集群 DBA 表优化,索引优化,等 分布式 nosql 主从分离,集群 主从分离,集群...说明: 场景中的这些业务基本是用户进入APP后会操作到的,除了活动日(618,11,等),这些业务的用户量都不会高聚集,同时这些业务相关的表都是大数据表,业务多是查询操作,所以我们需要减少用户直接命中...,分布式数据库,nosql主从集群,如:用户服务、订单服务; 消息队列 秒杀、秒抢等活动业务,用户在瞬间涌入产生高并发请求 场景:定时领取红包,等 服务器架构图: ?...如: 自动弹窗签到,11跨0点的时候并发请求签到接口 11抢红包活动 11订单入库 等 设计考虑: 逆向思维,压力在数据库,那业务接口就不进行数据库操作不就没压力了 数据持久化是否允许延迟?

93110

亿级流量电商详情页系统的大型高并发与高可用缓存架构实战

虽然了解redis/memcached,ActiveMQ,nginx负载均衡等技术,但是了解这些技术就能让你技术竞争力?掌握这些技术就足够你解决各种复杂系统中的高并发与高可用挑战?...掌握这些技术在Java高阶职位的面试中,就能让你拥有属于自己的技术亮点?答案似乎都是否定的。...解决方案:nginx抗热点数据+redis抗大规模离线请求+ehcache抗redis崩溃的三级缓存架构 4、数据库+缓存写一致性解决方案 面临难题:高并发场景下,如何解决数据库与缓存写的时候数据不一致的情况...解决方案:异步队列串行化的数据库+缓存写一致性解决方案 5、缓存维度化拆分解决方案 面临难题:如何解决大value缓存的全量更新效率低下问题?...解决方案:基于hystrix的高可用缓存服务,资源隔离+限流+降级+熔断+超时控制 11、复杂的高可用分布式系统架构设计 面临难题:如何针对复杂的分布式系统将其中的服务设计为高可用架构

2.5K20

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

缓存层:数据读取加速 在抢购业务中,对商品库存数量的更改主要通过数据库进行,但是由于读取流量过大,一般需要通过两级缓存的机制进行优化,即:Java服务进程内本地缓存-->分布式缓存服务-->数据库服务。...技术保障 业务全链路压测 全链路压测是阿里2013年在11压力之下被逼出来的技能,由于线上线下环境多少都会有些不同,很多问题只有在实际生产环境才能暴露,对于秒杀类业务,线上压测也能够实际评估出系统的真实承载力...比如阿里张瑞说的: “在零点前有一个倒计时环节,连线杭州光明顶作战指挥室,逍遥子会为大家揭幕201511启动,然后直接切换到我们的媒体大屏,所以对GMV数字的要求基本上是零延迟,这个挑战多大不言而喻...我们可以做些什么 阿里11的目的在于:去库存、提升影响力和拉新,而对研发和基础架构来说则是保持技术领先的年度演习。...因此需要在一下基础技术上进行积累: MySQL数据库内核优化,适配秒杀业务 构建公司系统化的全链路压测解决方案 与秒杀类需求的业务共建,从中间件、缓存、数据库、业务逻辑等方面构建全套解决方案 提升容器弹性伸缩效率

6.7K30

书单 | 11月新书速递!Apache Pulsar首著来啦

(扫码了解本书详情)  03 ▊《SequoiaDB分布式数据库权威指南》 许建辉 等 著 巨杉数据库首著,代表国人原创技术之大成 湖仓一体架构,跨引擎数据一致性,跨业务实时数据应用 本书从分布式数据库的背景与发展情况出发...,详细、系统地介绍了国产分布式数据库SequoiaDB(巨杉数据库)的基础知识、数据库实例、架构原理、运维管理等核心技术内容,提供了性能调优和问题诊断的基本思路。...本书旨在帮助读者更好地理解SequoiaDB的运行机制和原理,掌握运维管理的思路和实践方法,适用于普通读者入门SequoiaDB,也适用于对分布式数据库一定认识,且具备一定运维和开发能力的读者深入了解...(扫码了解本书详情)  11 ▊《趣玩Python:自动化办公真简单(色+视频版)》 关东升 著 Python办公自动化轻松玩转!...活动方式:关注下方“博文视点Broadview”公众号,在后台回复“书单抽奖”参与活动,届时会在参与的小伙伴中抽取3名幸运鹅! 活动时间:截至11月29日开奖。

52920

金融级IT架构:网商银行是如何进行数字化落地的

2016年,“同城活”架构落地。11月,首次成功参加“11”大促。...2017年,全面应用国产分布式数据库OceanBase,在银行业界率先实现了100%去IOE和自主可控;同年,全面建成数据库“三地五中心”架构,城市级别灾难RPO为0。...这些小微经营者包括网店店主、路边店店主、经营性农户,这些经营者80%此前从未获得银行经营性贷款。...▼ 网商银行依托于阿里巴巴集团和蚂蚁集团多年来沉淀的云计算和分布式底层平台技术,从筹建之初就将所有核心业务系统以分布式架构创建于云平台之上,是中国第一家将核心系统架构在云计算和分布式数据库上的银行。...活动方式:关注下方“博文视点Broadview”公众号,在后台回复“金融架构抽奖”参与活动,届时会在参与的小伙伴中抽取1名幸运鹅! 活动时间:截至8月12日(周四)开奖。

1.2K10

Java进阶架构师必看:15次架构演进详解

单体架构 3.1.jpg Tomcat + 数据库部署在同一台服务器上的 问题:- 随着用户增长,tomcat和数据库之间相互竞争服务器资源- 单机性能不足以支撑业务- 整个服务器挂掉 2....引入本地缓存和分布式缓存 3.3.jpg 引入本地缓存和分布式缓存 Tomcat服务器上或同JVM中增加本地缓存在外部增加分布式缓存缓存热数据和静态html页面通过缓存把大多数的请求在读写数据库前拦截掉会应用到哪些技术栈呢...全文检索:ElasticSearch 11....引入容器化技术实现环境隔离与动态服务管理 3.14.jpg 引入容器化技术实现环境隔离与动态服务管理 目前最流行的技术是Docker 容器管理:K8S 11来之前: 在现有的机器集群上划分出服务器来启动...Docker镜像,增强服务的性能 11之后: 活动结束后:就可以关闭镜像,对机器上的其他的服务不会造成任何影响 15.

1.5K20

亿级流量架构之秒杀设计

没法扩容, 那么也就意味着要使用其他方法, 如果所有请求访问一台物理机器肯定不行, 一百万的数据访问无论如何分库分表都无济于事, 因为面对的每一条都是热点数据, 所以要用到分布式架构的思路。...4.2 方案二 利用我们分布式中限流、网关等知识, 将请求层层筛选, 降低最后连接到数据库的请求。...也可以像方案二那样逐层过滤请求, 这种业务场景和双十一相同? 如果像 11 那样,想尽可能多地卖出商品, 那么就不像秒杀了。...为了保证一致性,还要能够扛得住像 11 这样的大规模并发访问,那么,应该怎么做呢? 使用秒杀这样的解决方案基本上不太科学了。...这个时候就需要认认真真地做高并发的架构和测试了,需要各个系统把自己的性能调整上去,还要小心地做性能规划,更要把分布式的弹力设计做好,最后是要不停地做性能测试,找到整个架构的系统瓶颈,然后不断地做水平扩展

2.6K52

双十一之秒杀设计

没法扩容, 那么也就意味着要使用其他方法, 如果所有请求访问一台物理机器肯定不行, 一百万的数据访问无论如何分库分表都无济于事, 因为面对的每一条都是热点数据, 所以要用到分布式架构的思路。...- 方案二 - 利用我们分布式中限流、网关等知识, 将请求层层筛选, 降低最后连接到数据库的请求。...也可以像方案二那样逐层过滤请求, 这种业务场景和双十一相同? 如果像 11 那样,想尽可能多地卖出商品,那么就不像秒杀了。...为了保证一致性,还要能够扛得住像 11 这样的大规模并发访问,那么,应该怎么做呢? 使用秒杀这样的解决方案基本上不太科学了。...这个时候就需要认认真真地做高并发的架构和测试了,需要各个系统把自己的性能调整上去,还要小心地做性能规划,更要把分布式的弹力设计做好,最后是要不停地做性能测试,找到整个架构的系统瓶颈,然后不断地做水平扩展

79010

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

每年“ 11”都是一场电商盛会,消费者狂欢日。今年 11 的意义尤为重大,它已经发展成为全世界电商和消费者都参与进来的盛宴。...这比传统的“两地三中心”架构更好的业务连续性保障。...现在支付宝的数据架构已经从集中式的小型机和高端存储升级到了分布式 PC 服务解决方案,整体数据架构的解决方案尽量做到无厂商依赖,并且标准化。 支付宝分布式数据架构可伸缩策略主要分为三个维度: ?...以下是分布式事务框架的流程图: ? 实现: 一个完整的业务活动由一个主业务服务与若干从业务服务组成。 主业务服务负责发起并完成整个业务活动。 从业务服务提供 TCC 型业务操作。...为了保证蚂蚁花呗 11 期间的授信资金充足,在金融云体系下搭建了机构资产中心,对接支付清算平台,将表内的信贷资产打包形成一个一定期限的资产池,并以这个资产池为基础,发行可交易证券进行融资,即通过资产转让的方式获得充足资金

2K30
领券