如有10亿人同时去一个网站浏览，都按F5不松手会怎样？
网站会崩溃，任何一个网站都不可能承受的住。
电商怎么解决高并发 高并发订单处理
电商怎么解决高并发 高并发订单处理
我们可以粗略地估计一下，普通键盘的刷新速度快可以达到1000次每秒，考虑到有很多软件并不需要这么快的响应速度，这些软件会降低这个频率来节省电脑资源。我自己用谷哥浏览器试了一下，按f12打开控制台选择network选项，按住f5不松手（直接在浏览器界面按住f5只会刷新一次，我想这跟题主的本意可能不符）这时候控制台飞快刷新，目测每秒几十次，按10次算的话十亿人按住f5不松手产生的浏览量可以达到100亿每秒。
我们再看一下可能是世界上短时间内并发的网站——双十一时候的淘宝。具体的数据我们没有不过我们可以根据网上提供的一些数据估算一下。淘宝访问的时候应该就是十一号零点刚过那几分钟，事实上淘宝交易额增速快的也是那几分钟，我猜测每秒峰值订单也是发生在这个时候，这个数据是54.4万笔每秒。设一千个人里边有一个下单的那么当时的浏览量大概5亿每秒。实际上这个时候的淘宝虽然没有崩溃，但是很多页面已经出现了延迟，有很多数据已经刷不出来。而题中的条件远远超过这个数字，淘宝也是完全承受不住这个访问量的（实际上我已经尽量低估了十亿人按住f5造成的访问量，高估了淘宝在双十一承受的访问量）。我觉得没有任何一个网站可以承受这么大的访问量。
实际上十亿人接近世界人口的七分之一，根本不会有一个页面可以吸引这么多人同时访问，网站在设计的时候也完全不会考虑如此高的并发。
现实中的网站访问远比这个复杂，这里只是做一个很粗略估计来讨论一下，欢迎大家提出不同意见。
看到有朋友在评论中提出疑问，我自己测试了一下，然后看了下Apache的日志21次，只代表我自己的测试，不保证准确，给大家一个参考。
传说中的洪水攻击，其效果就是这样，那会瞬间阻塞网络，导致网站访问慢或访问不到，目前来看也只有阿里有可能承受住
10亿人同时浏览一个网站，并且还按F5进行不断刷新，现实当中没有这样的网站，如果有的话一定是会崩溃的！
但是现实中和题主设接近的网站有，谁？那就是经常被全国在春运时喷的12306，我们不妨来看看当前12306的流量数据。
2018年的时候提供过当年春运时12306的页面流量次数，高峰时期单日PV是1500亿次，平均到每小时则是1500/17=88亿次(注：12306晚23点到第二天6天不售票，这里我就去掉了这7小时)。也就是说12306每小时88亿的访问量，每分钟则相当于1.47亿的访问量。
这个数据量已经是相当惊人了，即便是淘宝双11也是比不上12306的。同时，这里还请注意，这里仅仅是说的页面访问量，如果加上数据库的查询、出票等等功能，那么12306所承担的压力会更加大，负荷也更重，因此全球范围内真正的网站，能承受全国亿人同时冲击的就只有它了，剩下才是淘宝双11的高并发流量冲击。
可以说当前的12306系统超越当前任何一个秒杀系统。
目前12306所承受的访问量还在逐步递增，因为春运走的人群也是逐年递增，很多人疑问为何12306开始线上购票后怎么票越来越难买，还不如当年线下排队购票。其实很多人是忽视了春运人数增长这个现象。
从春运开始的1亿人次，逐年增长到现在破4亿人次，票显然是越来越难买。这个数字增长其实已经反映了这些年来的运力增长，但这个运力的增长赶不上越来越多民众的出行需求。
今年12306又出现了崩溃的情况，显然买票的人多了。
Lscssh 科技 官观点：
综合技术难度来说，12306实现的技术远比淘宝电商平台要复杂，如果你真的懂技术就会惊叹12306目前所取得的成绩，否则在你眼里肯定是不如淘宝天猫。
首先祝贺我国都有闲情雅致去同一个网站浏览。
这个问题，放在8年之前，是瘫，你会在网站高峰是很容易看到网站不可访问的提示；放在今天，是要恭喜您，这个级别的网站的架构师们，已经同样怀着一颗闲情雅致的心情，把这个问题解决了；就算是自己没解决，也会找武林高手把这事儿解决。直观的例子就是我国的12306网站。
早些年，当12306在线购票系统刚刚公布不久，春运来了。来自五湖四海的弟兄们怀着回家团圆的热情，一起按F5刷票，把网站搞瘫了。没错瘫了。那个时候，能刷到票的，除了手速，关键的是运气。
所以从那时起，关于12306的各种一股脑地涌现出来。大到系统架构、；小到用户体验。甚至在互联网产品的交流沙龙上，12306的网站改版竟然成了反面教材，被肆意使用。
12306经历了初期的磨难，但依然要面对无法躲避的春运、国庆黄金周等难关。12306召集有大数据并发经验的互联网公司们的大牛、架构师们，为网站献计献策，充分优化系统架构；具体改了多少架构；做了多少重构不得而知。而经过时间的沉淀，大家能够普遍认同的是，12306的数据关系，往往比常见的互联网公司要复杂的多。而经历了大并发的多次洗礼，大家感觉到，系统便稳定了很多。
有一年春运，购票系统和以往相比，简直可以用丝滑来形容。12306甚至没给大家留下什么瘫痪的印象。事后，12306和阿里云宣布战略合作。12306向阿里云提出了严峻的挑战，而阿里云不负众望，为12306保驾护航。
其实，大并发一直是信息时代不得不面对的一个问题。12306只不过是一个例子，时至今日，大并发已经衍生出更多复杂的场景。双11我们在畅快购物的同时，偶尔在一瞬间还是会感到大并发带给网站的压力。只不过，用户已经更加从容；因为他们相信，网站有这个技术马上会将瘫痪的服务恢复。等下下就好~
10亿用户并发访问，此等流量目前也还没有一个大型网站能承载。 日前12306就出现了崩溃的现象，有人猜测疑似因流量过大导致。“12306 服务”承受着这个世界上任何秒杀系统都无法超越的QPS，上百万的并发再正常不过了！不过大型网站的访问量大、并发量高、海量数据等方面如果处理不来，没法解决多用户高并发访问问题还是要崩了。
目前淘宝的高并发流量承载水平。 每年的双十一狂欢节是阶段性高并发访问的典型代表，1分36秒，交易额冲到 100 亿 ！高并发系统架构通常采用分布式集群部署，服务上层有着层层负载均衡。根据不同负载能力和配置策略来均衡分配访问流量，保证系统的高可用性。当然，其中还有容灾系统的辅助作用。
2019双十一来说，天猫淘宝每秒交易创建峰值54.5万笔、实时计算消息处理峰值25.51亿条/秒，而用户在购物支付中未感受到抖动、流畅平稳。支付宝技术自主研发的技术之一、分布式数据库OceanBase再次刷新数据库处理峰值，达6100万次每秒。
性能、程序并发处理能力有限。网站在大并发，高负载时就会有瘫痪，拒绝服务的崩溃现象出现。对于“10亿人同时去一个网站浏览”，十亿级别的并发访问，放现在任意一大型网站都难以承载。
负载均衡、合理的使用并发和异步、发挥多核优势…还仍是当下研究和 探索 的重要课题。因需求而演进，初期的单机架构，到容器化技术实现运行环境隔离与动态，在现在系统还可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题。并发到千万级亿数级别并况也是服务端的架构的不断演进过程。
如果是测试，额，好像这个场景也只会是测试，，看网站类型吧，如果只是浏览网页，做静态缓存，加不算钱的CDN完全没问题
主根，在美国，网络运维预算工程师也有杰出吊炸天的专家，在使用网络到现在，目前没有听到过，主根卡爆，您用的网络，是付了钱的，您出多少钱，别人为你提供多少优质的网络服务，网络工程师这点常识不可能没有，不预留兼容空间，常按键盘F5，持续刷新，取决您的电脑cpu是否足够强大，不会影响到别人使用网络的，过流使用网络，各大网络后台，会给您限速的，不可能给你一根网线，让你去开网吧，您出多少钱，您就享受怎样的有限网络限制服务。一块钱成本，想要博得四两拨千斤，肯定不现实，网络工程师可不是光吃白米饭不需要菜的主，不会给黑客留后门让您无节制的使用有限网络，谁会做亏本买卖，所以您试图卡爆主根想法，不会实现。
很有趣的一个问题，从侧面引申出了用户与之间的访问关系，究竟有哪些因素会影响我们的访问呢？题目中已经预示了这个问题：
那么，就从这两个方面来简单分析一下，是否存在同时支撑10亿用户访问的网站吧！
一、关于网站流量的问题讨论
随着互联网的快速发展，网站内容不再单调，一个页面存在、音频、视频等多种元素，这给传输的带宽带来了一定的压力。
我们不按照视频播放的特殊情况来计算，仅仅按照一般网页打开高峰值的流量来进行估算。鉴于高清，语音，flash等因素，初步估计峰值带宽需要200K每秒。那么，若10亿人同时访问需要多少的带宽呢？大家不要急，容我拿出计算器好好计算一下，为了便于计算，暂不采用1024的进位，使用约为1000的进位（1M=1024K）。瞬时产生的峰值流量为200000G，也就是200T。当前网络传输已经支持100G，但是实际应用场景较少，我们按照理想100G来计算。
那么单台带宽肯定无法满足10亿人的同时使用，需要200000G除以100G台才能完成这一目标，显然2000台的搭建并不现实（不是无法实现，只不过成本过于昂贵）。
二、关于程序、性能能否支持的问题
我们拿12306、淘宝商城这两个高流量的网站举例，您就会知道10亿人同时访问所带来的压力。
一年一度的春节就要来临，也到了12306容易崩溃的时间段。这部，前不久12306疑似又出现了崩溃的问题。我们先来看下2018年时12306高峰期的统计数字：
请记住每秒164.8万次这个数字！
再来说说淘宝，淘宝参考价值的就是双十一时的用户访问量。据相关统计数字显示，淘宝双十一峰值用户访问数据是每秒4200万次。即便如此，淘宝当晚依然如临大敌，全力保障避免网络以及出现问题。
每秒164.8万次、每秒4200万次与每秒10亿次来对比，可想而知这个数据的恐惧。甚至这里令我想到了DoS攻击（拒绝服务，通过频繁占用资源终导致网络或崩溃），10亿人同时访问远比攻击要来得更加可怕！
结论是当前不存在同时支持10亿人访问的网站！
对于10亿用于同时接入某网站的问题，您怎么看？
欢迎大家留言讨论，喜欢的点点关注。
很有想象力的一个问题，十亿人同时刷新一个网站，至少目前为止还没有网站能够架得住，按照现在阿里巴巴云计算的能力讲，的组合能力已经优化到一种非常合理化的境界，单纯的依靠计算能力提升的空间已经非常有限了，如果单单是为了应对这些人的冲击构建大量的，毫无疑问将会产生极大的浪费，任何企业都不会为了应对这一攻击而购置大量的。
早期的云计算产生其实也是一种偶然的因素，亚马逊早期为了应对巨大的冲击，购置了大量的，结果发现储备的太多了，就想着如何处理这些多余或者利用这些的额外用处，于是想着如果把这些构建起来给一些中小企业提供服务，而且这些之间还可以进行资源的共享，这就是早期云计算产生的简单的需求，但随着功能的延申云计算所起到的作用也越来越大，亚马逊在这方面投入的精力也是越来越大，但成效也越来越明显，成为亚马逊市值飙升的重要参照因素，而且云计算的诞生对于甲骨文的数据库有非常大的冲击，亚马逊已经宣传旗下的数据库切换到云计算的模式，相信不久的将来阿里巴巴也会完成这一使命。
同时访问一个网站，考验的就是网站的负载均衡能力，现在网站已经不是单一的构造了，不同地区的访问会汇总到不同的区域里面，后通过数据的交互将数据汇总到总的主控上，然后做出具体的反应从理论上讲，如果想要快速的反应就要求在接受到数据一瞬间就要准确到传递到正确的上，关键是步如果访问量过大，步接收的可能直接崩溃或者数据被排队等待了，可以想象在双11期间阿里巴巴启动的的数量要多于平时，同时阿里巴巴已经把迁移到阿里云上了，对于的管理能力又进一步增强了，同时又增加了很多的备用来支撑，毕竟阿里云的业务能力也在进一步增强，所以增加备用的也是业务上的需要。
增加的负载能力简单直接有效的办法就是增加的数量，但这种方式对于成本的要求还是非常高，每家都不会去做这种事情，毕竟如果只是单纯的使用几次这种成本的代价太高，之前的购票网站12306经常出现宕机的情况，后还是阿里巴巴的阿里云一起协助解决了这类冲击的问题，其实订票冲击相比双11的冲击还是了许多，解决并发问题的能力上在国内范围厉害的企业当属于阿里巴巴，12306把查询的功能部署在阿里云上极大降低12306主要的压力，同时也是对阿里巴巴负载能力一个极大的检验。
即使阿里巴巴已经在解决负载能力上有着非常丰富的经验，但是10亿用户同时刷新网站的做法，即使放在阿里巴巴面前也是一个极大的难题，不仅仅是技术能力的问题关键还是在于是否有必要购置这些，希望能帮到你。
按住F5不算啥，部分已加载的是读取本地缓存，ctrl+F5，shift+Command+R才是毁灭性的吧
深入理解分布式事务，高并发下分布式事务的解决方案
1、什么是分布式事务
分布式事务就是指事务的参与者、支持事务的、资源以及事务管理器分别位于不同的分布式系统的不同之上。以上是百度百科的解释，简单的说，就是一次大的作由不同的小作组成，这些小的作分布在不同的上，且属于不同的应用，分布式事务需要保证这些小作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
2、分布式事务的产生的原因
2.1、数据库分库分表
当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。
2.2、应用SOA化
所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。
以上两种情况表象不同，但是本质相同，都是因为要作的数据库变多了！
3、事务的ACID特性
3.1、原子性（A）
所谓的原子性就是说，在整个事务中的所有作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的作都会被回滚，整个事务就像从没被执行过一样。
3.2、一致性（C）
事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么后A账户一定是450元，B账户一定是350元。
3.3、隔离性（I）
所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。
3.4、持久性（D）
所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。
4、分布式事务的应用场景
4.1、支付
经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的作必然需要引入分布式事务。
4.2、在线下单
买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。
5、常见的分布式事务解决方案
5.1、基于XA协议的两阶段提交
XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：
总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。
5.2、消息事务+终一致性
所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：
1、A系统向消息中间件发送一条预备消息
2、消息中间件保存预备消息并返回成功
3、A执行本地事务
4、A发送提交消息给消息中间件
通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：
步骤一出错，则整个事务失败，不会执行A的本地作步骤二出错，则整个事务失败，不会执行A的本地作步骤三出错，这时候需要回滚预备消息，怎么回滚？是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地作+发消息）+B系统的本地作，其中B系统的作由消息驱动，只要消息事务成功，那么A作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地作，如果本地作失败，消息会重投，直到B作成功，这样就变相地实现了A与B的分布式事务。原理如下：
虽然上面的方案能够完成A和B的作，但是A和B并不是严格一致的，而是终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。
5.3、TCC编程模式
所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。
6、总结
分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力
1. 电商详情页系统架构介绍
电商详情页架构方案大概分为两种，种小型电商，使用页面静态化的方案；第二种大型电商，架构较为复杂，使用异步多级缓存 + nginx 数据本地化动态渲染的方案。
1. 页面静态化架构（全量页面静态化，适合小型电商网站）
电商详情页分为页面数据和页面模板两块，通过页面模板渲染的方式，把页面数据填充到模板中，生成终的静态化 HTML 页面，推送到 nginx 上面，前端商品详情页的请求直接通过 nginx 服务访问静态页面。
对于小型网站，页面很少，这种架构方式很实用，也非常简单。模板引擎可以使用 velocity 或者 freemarker 实现，通过页面数据管理的 cms 系统渲染页面。当页面数据或者页面模板出现变更，重新部分或者全量渲染静态化页面。
整体页面静态化架构如下图所示：
2. 异步多级缓存 + nginx 数据本地化动态渲染的架构 （适合大型电商）
对比页面静态化架构，该架构方案在保证高并发、高可用的前提下，不用提前部分或者全量渲染静态化页面，页面数据和模板可以根据业务需求实时变更，由 nginx 渲染成 HTML 静态页面返回给前端展现。
整体架构思路如下图所示：
电商系统架构以及分布式系统架构优缺点
1.技术新
2.技术范围广
3.分布式
4.高并发、集群、负载均衡、高并发
5.海量数据
6.业务复杂
7.系统安全
根据业务需求进行拆分成N个子系统，多个子系统相互协作才能完成业务流程子系统之间通讯使用RPC远程通讯技术。
同一个工程部署在多个不同的上。
1.把模块拆分，使用接口通信，降低模块之间的耦合度。
2.把项目拆分成若干个子项目，不同的团队负责不同的子项目。
3.增加功能时只需要再增加一个子项目，调用其它系统的接口就可以。
4.可以灵活的进行分布式部署。
有优点就有缺点，缺点如下：
1.系统之间交互需要使用远程通信，接口开发增加工作量。
2.各个模块有一些通用的业务逻辑无法共用。
为了解决上面分布式架构的缺点，我们引入了soa架构，SOA：Serv Oriented Architecture面向服务的架构。也就是把工程拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
为什么“书到用时方恨少”？
"书到用时方恨少"这句话的意思是在面对实际问题时，我们很难凭借快速阅读书本上的知识解决所有问题。这是因为书上讲述的很多理论知识往往是从一个抽象和理论上的角度出发，而实际问题往往比较具体、实际和复杂。因此，在解决实际问题时，我们需要考虑到更多的细节，理论知识往往需要在实际场景中进行验证和调整，我们需要根据实际的需求和限制进行修改和集成，这就需要我们有较强的实践能力，能够将所学知识很好的运用到实际工作中去。
举一个实际的场景来说，我们来看看在软件开发的过程中，为什么"书到用时方恨少"。当我们开始学习编程，编写代码时，我们很难预见到所有的问题和局限性。因此，我们需要不断的去调整和优化代码，以适应实际的需求和限制。比如说，当我们正在开发一个电商应用时，我们需要处理用户、商品、订单等很多不同的数据，我们需要使用数据库来存储这些数据。但是我们学习数据库时并不会遇到所有的实际场景问题，例如：如何在高并发下保证数据的一致性，如何优化查询效率等。只有将学习到的理论知识和实际问题相结合，才能够更好的解决实际问题。
在开发过程中，还需要考虑与其他人员协作。设我们在开发一个大型的软件项目，一个团队需要协作完成各种不同的任务。而在实际的团队协作中，我们会发现书本上没有讲到的一些挑战，例如：如何有效地配置开发环境，如何管理代码的版本控制等。这些都是实际项目中需要面对的问题，书本上的知识难以提供完整的解决方案。
因此，不同于学术研究，实际项目会更复杂，需要考虑到很多因素，例如时间、经费、用户反馈、市场趋势等。只有在实际的场景中不断调整和优化给定的知识和技能才能够更好地解决实际的问题和面对未来的挑战。