高并发系统如何实现高可用原理减而治之：CDN；nginx限流、异步队列（高并发流量变成均分流量）分而治之：lvs+nginx负载均衡特性写强一致性（不超卖）读弱一致性（读可能有库存，但不能下单）核心实现读服务，实现写服务，实现排队进度查询，实现链路流量优化。Howtodo(lvslayer,serverlayer,reducetrafficinflux)在流量漏斗请求环节，各层服务调峰，限流，自动降级，熔断秒杀系统的实现【以滴滴为例lecturer]Ab压测接口能承受的最大qps值-n访问1000次，-cConcurrent100Requestspersecond是吞吐量，以秒为单位，所以这个值就可以了；结束qps。限流Tengine版本使用http_limit_req_module来限制具体的连接，请参考http://tengine.taobao.org/doc...类似于官方的nginx，但是支持多变量，支持多个limit_req_zone设置。例如：limit_req_zone$binary_remote_addrzone=one:3mrate=1r/s；limit_req_zone$binary_remote_addr$urizone=two:3mrate=1r/s;#$uri:没有客户端请求参数limit_req_zone$binary_remote_addr$request_urizone=thre:3mrate=1r/s;#$request_uri:withclientrequestparameters上面第二个命令表示当同一个ip地址访问同一个uri时，会导致限制req(每秒1个请求)。Nginx正式版有两个模块来限制IP的连接数和并发数：limit_req_zone用于限制单位时间内的请求数，即速率限制，漏桶算法“leakybucket”limit_req_conn用于限制同时连接数，即并发数limit_req_conn模块可以根据源IP限制单个用户的并发访问连接数或者服务的并发连接总数。两种算法最大的区别：令牌桶算法可以处理突发流量，而铜泄漏算法不能。可以参考学习：https://www.cnblogs.com/bigli...漏桶算法我们假设系统是一个漏桶。当一个请求到来时，就是给漏水的桶“加水”。处理请求时，是漏水桶底漏水。水流出的速度是固定的。当“加水”速度过快时，水桶会溢出，即“拒绝请求”。从而使桶中的水量不可能超过桶的容量。主要目的是控制数据注入网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过该机制可以调整突发流量以为网络提供稳定的流量。示例如下：http{limit_conn_log_levelerror;limit_conn_status503;limit_conn_zone**$binary_remote_addr**zone=one:10m;limit_conn_zone**$server_name**zone=perserver:10m;limit_req_zone**$binary_remote_addr**zone=allips：100m速率=10r/s；//其中$binary_remote_addr有时需要根据其现有的**log\_format变量**配置server{……………….limit_conn一个100；allipsburst=5节点布局；……………………。}}参数说明：zone=one或allips表示设置一个名为“one”或“allips”的存储区域，大小为10兆rate=10r/s表示1秒内最多允许10次请求。burst=5表示最大延迟请求数不大于5，如果限制延迟请求过多，需要使用nodelay参数，服务器会立即返回503状态码。limit_connone100表示限制每个客户端IP最大并发连接数100limit_connperserver1000表示服务提供的连接总数不得超过1000，超过请求的将被拒绝。示例如下：http{limit_req_zone$binary_remote_addrzone=one:100mrate=10r/m;服务器{limit_reqzone=oneburst=1nodelay;}}配置说明rate=10r/m允许每秒不超过1个请求，最大延迟请求数不大于5。如果请求不需要延迟，加上nodelay参数，服务器会立即返回503状态代码。如果没有这个字段，会导致大量的tcp连接请求等待。http{limit_zoneone$binary_remote_addr10m;server{......limit_conn1;......}}这里一个是声明一个limit_zone名称，$binary_remote_addr是一个变量，用来代替$remore_addr，10m是一个session空间，用于状态存储。limit_connone1将并发客户端连接数限制为1，一次（每次）每个IP地址只允许一个连接。limit_req_zone的作用是通过漏桶原理来限制用户的连接频率，（该模块允许你限制单个地址指定一个会话或特殊需要的请求次数）。limit_zone功能是限制一个客户端的并发连接数。（该模块可以限制单个地址或特殊情况下特定会话的并发连接数）。一是限制并发连接数，二是限制连接频率。表面上看好像没什么区别，来看看实际效果吧~~~在我的测试机上加上这两个参数，下面是我配置文件的一部分http{limit_zoneone$binary_remote_addr10m;#limit_req_zone$binary_remote_addrzone=req_one:10mrate=1r/s;server{......limit_conn1;#limit_reqzone=req_oneburst=120;……}}配置说明limit_zoneone$binary_remote_addr10m;这里one是声明一个limit_zone名称，$binary_remote_addr是一个变量来代替$remore_addr，10m是存储会话状态的空间limit_connone1限制客户端并发连接数为1limit_zone工作条件limit_reqzone=oneburst=10;默认是这样配置的，这样每次请求都会有一个延迟时间，limit_req_zone$binary_remote_addrzone=one:100mrate=10r/m；即每分钟有10个token供用户使用，根据a的配置，会有延迟，每次请求时间为60/10，则每次请求时间为6s。limit_reqzone=oneburst=10nodelay;添加nodelay配置，这样就可以根据自己的网络情况访问，一分钟访问10次后，服务器直接返回503。limit_req_zone$binary_remote_addrzone=one:100mrate=10r/m;即每分钟有10个代币供用户使用。根据b的配置，会根据网络情况访问url。如果每分钟超过10个令牌，则服务器返回503并等待下一分钟来领取访问令牌。rate=10r/m每个地址每分钟只能请求10次，也就是说根据漏桶原理burst=1总共有1个token，每分钟只添加10个token，发送1个tokenout那些多余的请求会返回503，加上nodelay后，超过burstsize的请求会直接返回503，如果没有这个字段，会导致大量的tcp连接请求等待。http{...#定义一个名为allips的limit_req_zone用来存放session，大小为10M内存，#以$binary_remote_addr为key，限制每秒平均请求为20个，#1M可以存放16000个状态，rete的值必须是一个整数，#如果限制一个请求两秒，可以设置为30r/mlimit_req_zone$binary_remote_addrzone=allips:10mrate=20r/s;...server{...location{...#限制每个IP每秒不超过20个请求，漏桶突发数为5#brust表示如果1、2、3有19个请求，第4秒，第5秒允许#25个请求。#但是如果第一秒请求25个，第二秒请求超过20个返回503错误。#nodelay，如果不设置该选项，则严格使用平均速率限制请求数，#当第一秒有25个请求时，第二秒会执行5个请求，#设置nodelay，25个请求将在第一秒执行。limit_reqzone=allipsburst=5节点布局；...}...}...}一个cdn负载均衡iphash的问题，如果把某个学校的总ip分配给某台机器，那么这台机器的流量就会很大。在高并发环境下，消息队列经常会因为来不及同步处理而阻塞。比如insert、update等大量请求同时到达DB，直接导致无数的行锁和表锁，甚至请求到最后会堆积起来。太多，从而触发太多连接错误。通过使用消息队列，我们??可以异步处理请求，从而减轻系统的压力。流量预估秒杀系统的特点和难点秒杀系统的策略是与其他服务隔离部署的，所以也是一个单独的服务，即秒杀服务。实现需求秒杀系统的实现-库存扣减方案库存扣减的几种方式●库存订单扣减买家下订单时，从商品总库存中减去买家的采购数量。下单减库存是最简单的减库存方式，也是最精准的控制方式。下单时，通过数据库的交易机制直接控制商品的库存，不会出现超卖的情况。但是你要知道，有的人可能下单后不付款。●付款后扣库存是指买家下单后，库存不会立即减少，而是在用户付款后实际减少库存，否则库存会一直留给其他买家。但是因为只有付款的时候才减少库存，如果并发比较高，可能会出现买家下单后无法付款的情况，因为商品可能已经被别人买了。●预提存货的方法相对复杂。买家下单后，库存会保留一定时间（如10分钟）。过了这个时间，库存会自动释放。发布后，其他买家可以继续购买。买家付款前，系统会检查订单库存是否有预留：如果没有预留，则再次尝试预留；存货不足（即扣缴不合格）的，不得补缴；如果预扣成功，则进行付款并实际减去库存。上述减少库存的方法存在的问题由于购物过程中有两个或多个步骤，因此在不同的操作步骤中，如恶意下载等，在减少库存时会存在一些漏洞，可能被恶意买家利用。单例。如果我们采用“订单减库存”的方式，即用户下单后减去库存。一般情况下，买家下单后付款的概率会很高，所以不会出现大的问题。不过这个场景有一个例外，就是当卖家参加某项活动时，此时该活动的有效时间就是该商品的黄金销售时间。如果竞争对手恶意下单所有卖家的产品，这个产品的库存就会降为零，那么这个产品就不能正常销售了。要知道恶意下单的人是不会真正付款的，这就是“订单减库存”方式的弊端。付款减库存既然“下单减库存”可能会导致恶意下单，影响卖家的产品销售，请问有什么办法可以解决？你可能会疑惑，用“付款减库存”的方式行吗？确实可以。但是，“货款减去库存”会导致另一个问题：库存超卖。既然“订单减库存”和“付款减库存”都有缺点，那我们可不可以把两者结合起来，把前后两个操作联系起来，下单时先扣留，规定时间内不付款放库存，也就是“扣库存”的方法？该方案确实可以在一定程度上缓解上述问题。但是否彻底解决了？事实上，不！对于恶意下单的情况，虽然有效支付时间设置为10分钟，但恶意买家可以在10分钟后再次下单，或者一次下很多单。库存按件减少。针对这种情况，解决的办法是结合安全和反作弊措施来阻止。下单后扣库存问题怎么解决？识别并标记经常下单不付款的买家（被标记的买家下单后不能减少库存），并对某些类目设置最大购买数量（例如参与1人最多只能购买3个）活动物品），重复下单不付款有次数限制。服务器性能优化（极限挤压cpu）的重点是避免不必要的上下文切换。进程和线程的切换、系统调用、cpu都需要耗费资源的调度，这些都是无效的动作。程序的实际执行才是有效的动作。使用线程和协程可以避免两者。所以由此可见，Php并不是一种更好更适合扣库存的语言。为了达到极致的性能，php可以做的就是减少阻塞时的IO（磁盘文件读写，远程调用）。Redis，单机单服务可以做到10wqps。库存扣款实现Go是单进程，PHP是多进程。代码实现：redis+lua脚本防止超卖。商品信息和抢购进度的实现商品标题图片详情，这种不经常变化的，相对静态的信息，可以是静态+cdn价格，促销活动，库存，这些相对动态的信息，可以缓存为热点。数组和哈希表数据结构的区别，最大的区别：方法不同，数组通过key查找value，hash通过函数查找。https://www.cnblogs.com/chenj...减库存成功的用户存入数组A，依次存入。数组是索引数组，key是索引值，value是uid。哈希表，key为uid，value为数组A的索引值。每次消费数据，从头消费到尾，记录最近一次消费的索引值，即X，得到队列进度。数组和哈希存储在内存中，数组和哈希表的查询复杂度为O1，非常快。预留库存，放出少量流量，到统一扣库存的地方进行操作。写顺序，异步消费。请求链接实现漏斗流量示例：验证码12306是为了削峰填谷，增加用户操作难度，减少请求次数。它还可以防止机器人破解和验证。访问库存，注意这里的限流，但不要太久，注意时间间隔。允许用户低频读取数据，读写分离，一主多从，有效大幅提升读取的访问能力。海量并发处理的本质：分而治之；有效压榨CPU。单个服务的性能提升主要集中在压榨CPU性能上。减少IO（网络访问，磁盘读写），减少cpu上下文切换，cpu上下文切换是无效操作。单进程单线程，保证不切换上下文，但遇到IO可能会阻塞，异步多核cpu，单机部署多实例（多个单进程单线程），有效利用多核cpu.
