在口试中，口试官提出这样的问题，该当从哪些角度剖析。在事情中，大概没有这么弘大繁芜的运用处景，但是，针对网站的优化思路是同等的。本文从技能度度，剖析下应如何设计优化系统，才能保障如此大规模的并发访问。
秒杀系统紧张办理三大问题：
一、瞬时的高并发访问。抢购和普通的电商发卖有所不同，普通的电商发卖，流量是比较均匀的，虽然有波峰波谷，但不会特殊突出。而抢购是在特定时间点进行的推销活动，抢购开始前，用户不断刷新页面，以得到购买按钮；抢购开始的一瞬间，集中并发购买。
二、数据精确性。抢购毕竟是一种购买行为，须要购买、扣减库存、支付等繁芜的流程，在此过程中，要担保数据的精确性，防止超卖（卖出量超过库存）的发生。
三、防作弊。无论是火车票的购买，还是低价商品的匆匆销，肯定不肯望某些客户买到所有的商品，应只管即便担保公正性。通过购票插件购买火车票，阿里巴巴抢月饼事宜等，须要限定技能性用户绕过网站的限定，通过技能手段得到不良收益。
办理上述问题，紧张有如下的三个思路：访问拦截，分流，限流。
主流的Web站点采取分层的架构设计，如果你的运用还没有采取分层的架构，那么先做分层设计吧。一样平常来说，浏览器采取了html/js/css技能，卖力数据的展示；反向代理一样平常采取nginx，卖力负载均衡；Web层是指Php，Tomcat等运用做事器，卖力用户状态的掩护，http协议处理等；service层一样平常是rpc调用，当然也有用http的，例如spring cloud；数据库存储一样平常是mongodb，mysql等持久化数据方案。用户的一次数据访问，例如查询商品库存，数据是从上层依次调用到DB，逐层返回数据。
所谓访问拦截，是指只管即便把访问拦截在上层，减轻下一层的压力，即离用户访问更近的那一层。下面将从每一层讲解如何做访问拦截。
浏览器访问拦截：产品层面，当用户点击查询或购买按钮后，按钮置灰，防止用户重复提交数据。js层面，限定用户在限定韶光内的接口调用次数，或者返回相同的值。例如，用户重复刷新，每秒访问10次接口，变成5秒钟访问一次，并发量将会降落50倍。此种方法，可以拦截90%的小白用户的访问，但是技能型的用户可以绕过js，通过脚本或其他自动化办法调用接口，当年涌现的刷票神器，就属于这类范畴。用户量虽小，但是访问量很大。关于防作弊的问题，后续谈论。
CDN加速：CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速率和稳定性的瓶颈和环节，使内容传输的更快、更稳定。大略的来说，便是把原做事器上数据复制到其他做事器上，用户访问时，那台做事器近访问到的便是那台做事器上的数据。CDN的劣势是内容的变更生效慢，以是仅适用于“险些不变”的资源，例如引用的js包，图片等。
动静分离与反向代理层访问拦截：动态页面是指根据实时数据渲染的，须要组织数据、渲染页面；静态页面是存储在文件系统的文件，不会根据数据变革而变革，读取速率很快。为了提升效率，应尽可能的静态化，用静态页面，更换动态页面。例如，商品信息页，商品信息在发布后，是不会变革的，如果采取动态的办法，访问数据库读取数据，service组装数据，web渲染数据；如果发布商品信息时，就保存下商品信息的静态页面，访问时只须要读取一个文件就够了。
做了动静分离，静态文件的访问应在哪一层返回？无论是tomcat，还是apache，都支持静态文件的访问，很多时候我们也是这么做的，把静态文件作为web项目的一部分进行发布。Nginx也支持静态文件的访问，更高效的做法是，把静态文件交由nginx管理，访问nginx直接返回静态数据，减轻Web做事的压力。
Web层和Service层访问拦截：通过上述的访问拦截，进入到web层的，都是动态数据访问。这部分的访问拦截，紧张采取缓存的策略，减少对下一层的数据访问。缓存又可分为本地缓存和redis、memcache等缓存中间件。关于缓存，重点关注缓存的淘汰策略。一样平常有三种办法：超时更新，定时更新，关照更新。
访问拦截，除了减少向下一层的访问，还大幅提高系统的支持用户数。访问拦截，大大减少了每次要求的处理韶光，假设：每个要求原来须要200ms韶光，10W的并发量，每秒钟可处理50W的要求；通过访问拦截，每个要求的处理韶光低落到100ms，同样的并发量，每秒钟可处理100W的要求。
通过上述的剖析，各层通过访问拦截，系统架构演化成如下的构造。
在并发量巨大的场景下，通过上述的优化远远不足的，由于单台做事器的处理能力是有限的，即便在当前硬件设备越来越便宜，也不可能无限扩容。分流便是指通过多台做事器，并发的处理要求，减轻单台做事的负载。
DNS轮询：Nginx的处理能力是有限的，单台做事器支持10W旁边的并发访问，没有问题。如果更大的负载怎么办？Nginx是运用做事的入口，不能再运用做事这个层次增加做事器，提高并发处理能力。
通过浏览器输入域名访问某个做事，其过程如图所示。DNS轮询是ISP供应的一个做事，不同的用户访问同一个域名，获取到不同的IP地址。例如：给www.example.com配置4个IP地址，如果有40W的并发访问，每个IP将会得到10W的并发访问。当然，域名的IP地址配置，可以支持不同的策略，例如按照电信运营商分配，按照地域分配等。
Nginx负载均衡：Nginx可以支持10W的并发访问，而运用做事器却达不到这个水准，tomcat一样平常支持1W的并发访问就很好了。Nginx支持配置要求的代理策略，把要求路由到多个Web做事器处理。Nginx支持的负载均衡策略包括：轮询，权重，ip_hash，fair，url_hash等。
分布式架构的负载策略：Web层调用service，以及service之间的调用，每个service都须要支配多份。目前最常用的两个框架技能，spring cloud和dubbo，都采取客户端负载均衡策略，路由到service的不同实例。
Redis负载：redis是内存的缓存构造，非常高效，瓶颈在于网络IO，支持几十万的QPS。redis分流，可考虑分片的设计，把数据分配到多台做事器上，减轻每台机器的负载。一样平常情形下，分片策略多用户redis数据扩容方案。
Mysql读写分离：对写要求，不适宜做分流，由于分流后的数据同步是大问题，导致数据不一致。对付写要求，一样平常采取读写分离的策略，并且可以多台读库。读库运用MyIsam引擎，单独设置得当的索引，提高读性能。从库并不是越多越好，由于从库越多，数据延迟越严重，要保持好平衡。
通过上述的剖析，各层通过分流策略，系统架构演化成如下的构造。
访问拦截和分流的策略，紧张浸染还是办理并发读的问题。购买、支付等这类“写要求”，不能像读缓存一样，写缓存提高效率，数据持久化成功，才算交易成功。尤其抢购这种模式下，商品数量少，如果多台做事同事写数据，将造成mysql严重的行锁冲突，实行效率远远不如顺序实行。并且大量的所等待，延长单个操作的时长，占用事情线程，产生做事雪崩征象，短韶光内不能对外供应做事。办理此问题的思路是限流，限定写操作的流量，使其正常运行，不影响业务。
计数器：假设统共100个商品库存，供大家抢货，并发访问极大。可以在Web层做一个计数器，抢单一次计数器加1，计数器到达100后，直接返回抢购失落败。同样的道理，计数器亦可在service层实现。这种情形下，假设有10台web做事器，也只会放行100 10 = 1000次抢购。
按商品路由：在Web层，把对同一品类商品的抢购路由到一台service处理。在service内，自定义mysql连接池，使对同一个商品的操作，利用同一个连接。这样就实现了对同一商品的顺序处理，避免了锁竞争。
异步化：是指把购买要求的接管和处理异步化。购买要求先放到行列步队中，这个过程非常高效，返回客户信息。抢购做事订阅行列步队，异步处理购买要求，处理成功给用户发。异步化紧张办理成产和消费的速率不匹配问题，由此类场景都可以采取。
对付防作弊问题，是比较随意马虎处理的。由于所有的购买，都是上岸用户的行为，可以很方便的根据用户ID进行过滤，只许可一个客户购买一次。在分布式环境下，要办理如何记录用户ID的问题，由于同一个用户可能被不同的web，不同的service处理。
全局Cache：在redis中开辟一个空间，记录所有用户的商品购买，处理用户购买要求是，校验缓存中是否已记录此商品的购买，如果已经购买，则不许可。要办理重复提交的问题，可考虑分布式锁。
用户ID路由：参考上一节的按商品路由，我们同样可以把对一个用户的处理，路由到同一个Service处理，只须要做本地缓存就够了。此种方案最大的问题是，如果做事挂了，数据就错乱了。
