㈠ 用thinkphp 开发万人在线的聊天室性能跟得上么
当你打算做聊天室的时候你可以自己看看如何解决以下问题：
数据的传输（如何及时把收到的数据传输给别人）
数据库的处理（对于数据的操作，万人在线的聊天室数据量产生肯定很大，那么怎么保证数据库能扛得下去）
web服务器是否有能力对抗那么大的并发数量
服务器的带宽是否能支撑下去
以上四点是基于B/S架构必有的问题，如果并非B/S架构那么后端也没必要使用PHP吧？
第一点、可以使用websocket进行解决，但缺点是不能支持旧版本的浏览器
（如果需要支持可以使用AJAX轮询进行处理，但会加大服务器压力）
第二点、可以增加缓存层，所有数据先进缓存，然后一定时间把缓存写入数据库。前提是需要内存足够大
（或者可以使用数据库中间件进行读写分离，或者直接分表处理）
第三点、再对WEB服务器优化后你能做的只有创建集群，用几台机去缓解压力
第四点、买带宽
说白了，没有一定的金钱做为支持的背景下thinkphp和c做出来的性能相差不大，因为瓶颈并不在它那
㈡ 缓存策略的选择
适合缓存的内容
1. 不变的图像袭启，如logo，图标等
2. js、css静态文件
3. 可下载的内容，媒体文件
适合协商缓存
1. HTML文件
2. 经常替换的图片
3. 经常修改的js、css文件，js、css文件的加载可以加入文件的签名来拒绝缓存，如‘index.css?签名’，‘index.签名.js’
不建议缓存的内容
1. 用户隐私等敏感数据
2. 经常改变的API数据接口
NGINX配置缓存策略
本地缓存配置
1. add_header指令：添加状态码为2XX和3XX的响应头信息，设置代码add_header name value [always];，可以设置Pragma、Expires、Cache-Control，可以继承
2. expires指令：通知浏览器过期时长，设置代码expires time;
3. Etag指令：指定签名，设置代码etag on|off，默认on
前端代码和资源压缩
优势
1. 让资源文件更小，加快文件在网络中的传输，让网页更快的展现，降低带宽和流量的开销
压缩方式
1. js、css、图片、html代码的压缩
2. gzip压缩
gzip配置
gzip on|off; #是否开启gzipgzip_buffers 32 4K|16 8K; #缓冲（在内存中缓存几块？每块多大）gzip_comp_level [1-9] #推荐6，压缩级别（级别越高，压得越小，越浪费CPU计算资源）
gzip_disable #正则匹配UA，什么样的Uri不进行gzip
gzip_min_length 200 #开始压缩的最小长度
gzip_http_version 1.0|1.1 #开始压缩的http协议版本
gzip_proxied #设置请求者代理服务器，该如何缓存内容
gzip_types text/plain application/xml image/png #对哪些类型的文件压缩，如txt、xml、css
gzip_vary on|off #是否传输gzip压缩标志
CDN加速
定义
1. CDN的全称content delivery network，内容分发网络
2. 尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定
3. 在网络各处放置节点服务器所构成的有的互联网基础之上的一层智能虚拟网络
4. CDN系统能够实现地根据网络流量和各节点的连接、负载状况以及到用户距离和响应时间等综合信息将用户的请求重新告禅洞导向离用户最近的服务节点上
优势
1. 本地cache加速，提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度
2. 跨运营商的网络加速，保证不同网络的用户都能得到良好的访问质量
3. 远程访问用户根据DNS负载均衡技术只能选择cache服务器
4. 自动生成服务器袜枯的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点web服务器负载等功能
5. 广泛分布的cdn节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵
工作原理
1. 用户发起请求
2. 智能DNS的解析（根据IP判断地理位置、接入网类型、选择路由最短和负载最轻的服务器）
3. 取得缓存服务器ip
4. 把内容返回给用户（如果缓存中有，没有就执行5、6、7）
5. 向源站发起请求
6. 将结果返回给用户
7. 将结果存入缓存服务器
适用场景
1. 站点或者应用中大量静态资源的加速分发，例如css、js、图片和HTML
2. 大文件下载
3. 直播网站
独立图片服务器
必要性
1. 分担web服务器的I/O负载，将耗费资源的图片服务器分离出来，提高服务器的性能和稳定性
2. 能够专门对图片服务器进行优化，为图片服务器设置针对性的缓存方案，减少带宽成本，提高访问速度
3. 提高网站的可扩展性，通过增加图片服务器，提高图片吞吐能力
采用独立域名
原因：
1. 同一域名下浏览器的并发连接数有限制，突破浏览器连接数的限制
2. 由于cookie的原因，对缓存不利，大部分web cache都只缓存不带cookie的请求，导致每次的图片请求都不能命中cache
如何图片上传和同步
1. NFS共享方式
2. 利用FTP同步
动态语言静态化
将现有的PHP等动态语言的逻辑代码生成为静态的HTML文件，用户访问动态脚本重定向到静态HTML文件的过程。对实时性要求不高
原因：
1. 动态脚本通过会做逻辑计算和数据查询，访问量越大，服务器压力越大
2. 访问量大时可能会造成CPU负载过高，数据库服务器压力过大
3. 静态化可以减低逻辑处理压力，降低数据库服务器查询压力
实现方法
1. 使用模板引擎
2. 利用ob系列函数
需要获取swoole、workerman、TP、laravel、vue、Linux、redis以及性能优化，并发项目实战，微服务 架构方面的资料，可以私信我哦
㈢ 京东活动系统--亿级流量架构应对之术
京东活动系统 是一个可在线编辑、实时编辑更新和发布新活动，并对外提供页面访问服务的系统。其高时效性、灵活性等特征，极受青睐，已发展成京东几个重要流量入口之一。近几次大促，系统所承载的pv已经达到数亿级。随着京东业务的高速发展，京东活动系统的压力会越来越大。急需要一个更高效，稳定的系统架构，来支持业务的高速发展。本文主要对活动页面浏览方面的性能，进行探讨。
活动页面浏览性能提升的难点：
1. 活动与活动之间差异很大，不像商品页有固定的模式。每个页面能抽取的公共部分有限，可复用性差。
2. 活动页面内容多样，业务繁多。依赖大量外部业务接口，数据很难做到闭环。外部接口的性能，以及稳定性，严重制约了活动页的渲染速度、稳定性。
经过多年在该系统下的开发实践，提出“页面渲染、浏览异步化”的思想，并以此为指导，对该系统进行架构升级改造。通过近几个月的运行，各方面性能都有显着提升。在分享"新架构"之前，先看看我们现有web系统的架构现状。
以京东活动系统架构的演变为例，这里没有画出具体的业务逻辑，只是简单的描述下架构：
2.第二步，一般是在消耗性能的地方加缓存，这里对部分查库操作加redis缓存
3.对页面进行整页redis缓存：由于活动页面内容繁多，渲染一次页面的成本是很高。这里可以考虑把渲染好的活动内容整页缓存起来，下次请求到来时，如果缓存中有值，直接获取缓存返回。
以上是系统应用服务层面架构演进的，简单示意。为了减少应用服务器的压力，可以在应用服务器前面，加cdn和nginx的proxy_caxhe，降低回源率。
4.整体架构（老）
除了前3步讲的“浏览服务”，老架构还做了其他两个大的优化：“接口服务”、静态服务
1.访问请求，首先到达浏览服务，把整个页面框架返回给浏览器（有cdn、nginx、redis等各级缓存）。
2.对于实时数据（如秒杀）、个性化数据（如登陆、个人坐标），采用前端实时接口调用，前端接口服务。
3.静态服务：静态资源分离，所有静态js、css访问静态服务。
要点：浏览服务、接口服务分离。页面固定不变部分走浏览服务，实时变化、个性化采用前端接口服务实现。
接口服务：分两类，直接读redis缓存、调用外部接口。这里可以对直接读redis的接口采用nginx+lua进行优化（ openresty ），不做详细讲解。 本次分享主要对“浏览服务”架构
在讲新架构之前先看看新老架构下的新能对比
击穿cdn缓存、nginx缓存，回源到应用服务器的流量大约为20%-40%之间，这里的性能对比，只针对回源到应用服务器的部分。
2015双十一， 浏览方法tp99如下：（物理机）
Tp99 1000ms左右，且抖动幅度很大，内存使用近70%，cpu 45%左右。
1000ms内没有缓存，有阻塞甚至挂掉的风险。
2.新架构浏览服务新能
本次2016 618采用新架构支持，浏览tp99如下（分app端活动和pc端活动）：
移动活动浏览tp99稳定在8ms, pc活动浏览tp99 稳定在15ms左右。全天几乎一条直线，没有性能抖动。
新架构支持，服务器（docker）cpu性能如下
cpu消耗一直平稳在1%，几乎没有抖动。
对比结果：新架构tp99从1000ms降低到 15ms，cpu消耗从45%降低到1%，新架构性能得到质的提升。
why!!!
下面我们就来揭开新架构的面纱。
1. 页面浏览，页面渲染 异步化
再来看之前的浏览服务架构，20%-40%的页面请求会重新渲染页面，渲染需要重新计算、查询、创建对象等导致 cpu、内存消耗增加，tp99性能下降。
如果能保证每次请求都能获取到redis整页缓存，这些性能问题就都不存在了。
即：页面浏览，与页面渲染 异步。
理想情况下，如果页面数据变动可以通过 手动触发渲染（页面发布新内容）、外部数据变化通过监听mq 自动触发渲染。
但是有些外部接口不支持mq、或者无法使用mq，比如活动页面置入的某个商品，这个商品名称变化。
为了解决这个问题，view工程每隔指定时间，向engine发起重新渲染请求-最新内容放入redis。下一次请求到来时即可获取到新内容。由于活动很多，也不能确定哪些活动在被访问，所以不建议使用timer。通过加一个缓存key来实现，处理逻辑如下：
好处就是，只对有访问的活动定时重新发起渲染。
整理架构（不包含业务）：
view工程职责 ：
a.直接从缓存或者硬盘中获取静态html返回，如果没有返回错误页面。（文件系统的存取性能比较低，超过 100ms级别，这里没有使用）
b.根据缓存key2是否过期，判断是否向engine重新发起渲染。（如果，你的项目外面接口都支持mq，这个 功能就不需要了）
engine工程职责 ：渲染活动页面，把结果放到 硬盘、redis。
publish工程、mq 职责 ：页面发生变化，向engine重新发起渲染。 具体的页面逻辑，这里不做讲解
Engine工程的工作 就是当页面内容发生变化时，重新渲染页面，并将整页内容放到redis，或者推送到硬盘。
View工程的工作，就是根据链接从redis中获取页面内容返回。
3.view 工程架构 ( 硬盘 版)
两个版本对比
a.Redis版
优点：接入简单、 性能好，尤其是在大量页面情况下，没有性能抖动 。单个docker tps达到 700。
缺点：严重依赖京东redis服务，如果redis服务出现问题，所有页面都无法访问。
b.硬盘版
优点：不依赖任何其他外部服务，只要应用服务不挂、网络正常 就可以对外稳定服务。
在页面数量不大的情况下，性能优越。单个docker tps达到 2000。
缺点：在页面数据量大的情况下（系统的所有活动页有xx个G左右），磁盘io消耗增加（这里采用的java io，如果采用nginx+lua，io消耗应该会控制在10%以内）。
解决方案：
a. 对所有页面访问和存储 采用url hash方式，所有页面均匀分配到各个应用服务器上。
b. 采用nginx+lua 利用nginx的异步io，代替java io。
现在通过nginx+lua做应用服务，所具有的高并发处理能力、高性能、高稳定性已经越来越受青睐。通过上述讲解，view工程没有任何业务逻辑。可以很轻易的就可以用lua实现，从redis或者硬盘获取页面，实现更高效的web服务。如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java进阶qun：694549689，里面有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
1.具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加。
2.在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。
3.如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的可以加。
通过测试对比，view工程读本地硬盘的速度，比读redis还要快（同一个页面，读redis是15ms，硬盘是8ms）。所以终极版架构我选择用硬盘，redis做备份，硬盘读不到时在读redis。
这里前置机的url hash是自己实现的逻辑，engine工程采用同样的规则推送到view服务器硬盘即可，具体逻辑这里不细讲。后面有时间再单独做一次分享。
优点：具备硬盘版的全部优点，同时去掉tomcat，直接利用nginx高并发能力，以及io处理能力。各项性能、以及稳定性达到最优。
缺点：1、硬盘坏掉，影响访问。2.方法监控，以及日志打印，需使用lua脚本重写。
无论是redis版、硬盘版、openresty+硬盘版，基础都是页面浏览与页面渲染异步化。
优势：
1、所有业务逻辑都剥离到engine工程，新view工程理论上永远无需上线。
2、灾备多样化（redis、硬盘、文件系统），且更加简单，外部接口或者服务出现问题后，切断engine工程渲染，不再更新redis和硬盘即可。
3、新view工程，与业务逻辑完全隔离，不依赖外部接口和服务，大促期间，即便外部接口出现新能问题，或者有外部服务挂掉，丝毫不影响view工程正常访问。
4、性能提升上百倍，从1000ms提升到10ms左右。详见前面的性能截图。
5、稳定性：只要view服务器的网络还正常，可以做到理论上用不挂机。
6、大幅度节省服务器资源，按此架构，4+20+30=54个docker足以支持10亿级pv。（4个nginx proxy_cache、20个view，30个engine）
从事开发已有近10载，一直就像寄生虫一样吸取着网络上的资源。前段时间受“张开涛”大神所托，对活动系统新架构做了一次简单整理分享给大家，希望能给大家带来一丝帮助。第一次在网上做分享，难免有些没有考虑周全的地方，以后会慢慢的多分享一些自己的心得，大家一起成长。最后再来点心灵鸡汤。。。
㈣ 如何搭建亿级并发的系统架构
想设计亿万级高并发架构，你要先知道高并发是什么？
面对流量高峰，不同的企业是如何通过技术手段解决高并发难题的呢?
0、引言
软件系统有三个追求：高性能、高并发、高可用，俗称三高。三者既有区别也有联系，门门道道很多，全面讨论需要三天三夜，本篇讨论高并发。
高并发（High Concurrency）。并发是操作系统领域的一个概念，指的是一段时间内多任务流交替执行的现象，后来这个概念被泛化，高并发用来指大流量、高请求的业务情景，比如春运抢票，电商双十一，秒杀大促等场景。
很多程序员每天忙着搬砖，平时接触不到高并发，哪天受不了跑去面试，还常常会被面试官犀利的高并发问题直接KO，其实吧，高并发系统也不高深，我保证任何一个智商在线的看过这篇文章后，都能战胜恐惧，重拾生活的信心。
本文先介绍高并发系统的度量指标，然后讲述高并发系统的设计思路，再梳理高并发的关键技术，最后结合作者的经验做一些延伸探讨。
1、高并发的度量指标
既然是高并发系统，那并发一定要高，不然就名不副实。并发的指标一般有QPS、TPS、IOPS，这几个指标都是可归为系统吞吐率，QPS越高系统能hold住的请求数越多，但光关注这几个指标不够，我们还需要关注RT，即响应时间，也就是从发出request到收到response的时延，这个指标跟吞吐往往是此消彼长的，我们追求的是一定时延下的高吞吐。
比如有100万次请求，99万次请求都在10毫秒内响应，其他次数10秒才响应，平均时延不高，但时延高的用户受不了，所以，就有了TP90/TP99指标，这个指标不是求平均，而是把时延从小到大排序，取排名90%/99%的时延，这个指标越大，对慢请求越敏感。
除此之外，有时候，我们也会关注可用性指标，这可归到稳定性。
一般而言，用户感知友好的高并发系统，时延应该控制在250毫秒以内。
什么样的系统才能称为高并发？这个不好回答，因为它取决于系统或者业务的类型。不过我可以告诉你一些众所周知的指标，这样能帮助你下次在跟人扯淡的时候稍微靠点儿谱，不至于贻笑大方。
通常，数据库单机每秒也就能抗住几千这个量级，而做逻辑处理的服务单台每秒抗几万、甚至几十万都有可能，而消息队列等中间件单机每秒处理个几万没问题，所以我们经常听到每秒处理数百万、数千万的消息中间件集群，而像阿某的API网关，每日百亿请求也有可能。
2、高并发的设计思路
高并发的设计思路有两个方向：
垂直方向扩展，也叫竖向扩展
水平方向扩展，也叫横向扩展
垂直方向：提升单机能力
提升单机处理能力又可分为硬件和软件两个方面：
硬件方向，很好理解，花钱升级机器，更多核更高主频更大存储空间更多带宽
软件方向，包括用各快的数据结构，改进架构，应用多线程、协程，以及上性能优化各种手段，但这玩意儿天花板低，就像提升个人产出一样，996、007、最多24 X 7。
水平方向：分布式集群
为了解决分布式系统的复杂性问题，一般会用到架构分层和服务拆分，通过分层做隔离，通过微服务解耦。
这个理论上没有上限，只要做好层次和服务划分，加机器扩容就能满足需求，但实际上并非如此，一方面分布式会增加系统复杂性，另一方面集群规模上去之后，也会引入一堆AIOps、服务发现、服务治理的新问题。
因为垂直向的限制，所以，我们通常更关注水平扩展，高并发系统的实施也主要围绕水平方向展开。
3、高并发的关键技术
玩具式的网络服务程序，用户可以直连服务器，甚至不需要数据库，直接写磁盘文件。但春运购票系统显然不能这么做，它肯定扛不住这个压力，那一般的高并发系统是怎么做呢？比如某宝这样的正经系统是怎么处理高并发的呢？
其实大的思路都差不多，层次划分 + 功能划分。可以把层次划分理解为水平方向的划分，而功能划分理解为垂直方向的划分。
首先，用户不能直连服务器，要做分布式就要解决“分”的问题，有多个服务实例就需要做负载均衡，有不同服务类型就需要服务发现。
集群化：负载均衡
负载均衡就是把负载（request）均衡分配到不同的服务实例，利用集群的能力去对抗高并发，负载均衡是服务集群化的实施要素，它分3种：
DNS负载均衡，客户端通过URL发起网络服务请求的时候，会去DNS服务器做域名解释，DNS会按一定的策略（比如就近策略）把URL转换成IP地址，同一个URL会被解释成不同的IP地址，这便是DNS负载均衡，它是一种粗粒度的负载均衡，它只用URL前半部分，因为DNS负载均衡一般采用就近原则，所以通常能降低时延，但DNS有cache，所以也会更新不及时的问题。
硬件负载均衡，通过布置特殊的负载均衡设备到机房做负载均衡，比如F5，这种设备贵，性能高，可以支撑每秒百万并发，还能做一些安全防护，比如防火墙。
软件负载均衡，根据工作在ISO 7层网络模型的层次，可分为四层负载均衡（比如章文嵩博士的LVS）和七层负载均衡（NGINX），软件负载均衡配置灵活，扩展性强，阿某云的SLB作为服务对外售卖，Nginx可以对URL的后半部做解释承担API网关的职责。
所以，完整的负载均衡链路是 client <-> DNS负载均衡 -> F5 -> LVS/SLB -> NGINX
不管选择哪种LB策略，或者组合LB策略，逻辑上，我们都可以视为负载均衡层，通过添加负载均衡层，我们将负载均匀分散到了后面的服务集群，具备基础的高并发能力，但这只是万里长征第一步。
数据库层面：分库分表+读写分离
前面通过负载均衡解决了无状态服务的水平扩展问题，但我们的系统不全是无状态的，后面通常还有有状态的数据库，所以解决了前面的问题，存储有可能成为系统的瓶颈，我们需要对有状态存储做分片路由。
数据库的单机QPS一般不高，也就几千，显然满足不了高并发的要求。
所以，我们需要做分库分表 + 读写分离。
就是把一个库分成多个库，部署在多个数据库服务上，主库承载写请求，从库承载读请求。从库可以挂载多个，因为很多场景写的请求远少于读的请求，这样就把对单个库的压力降下来了。
如果写的请求上升就继续分库分表，如果读的请求上升就挂更多的从库，但数据库天生不是很适合高并发，而且数据库对机器配置的要求一般很高，导致单位服务成本高，所以，这样加机器抗压力成本太高，还得另外想招。
读多写少：缓存
缓存的理论依据是局部性原理。
一般系统的写入请求远少于读请求，针对写少读多的场景，很适合引入缓存集群。
在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求，因为缓存集群很容易做到高性能，所以，这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
缓存的命中率一般能做到很高，而且速度很快，处理能力也强（单机很容易做到几万并发），是理想的解决方案。
CDN本质上就是缓存，被用户大量访问的静态资源缓存在CDN中是目前的通用做法。
缓存也有很多需要谨慎处理的问题：
一致性问题：(a)更新db成功+更新cache失败 -> 不一致 (b)更新db失败+更新cache成功 -> 不一致 ©更新db成功+淘汰缓存失败 -> 不一致
缓存穿透：查询一定不存在的数据，会穿透缓存直接压到数据库，从而导致缓存失去作用，如果有人利用这个漏洞，大量查询一定不存在的数据，会对数据库造成压力，甚至打挂数据库。解决方案：布隆过滤器 或者 简单的方案，查询不存在的key，也把空结果写入缓存（设置较短的过期淘汰时间），从而降低命失
缓存雪崩：如果大量缓存在一个时刻同时失效，则请求会转到DB，则对DB形成压迫，导致雪崩。简单的解决方案是为缓存失效时间添加随机值，降低同一时间点失效淘汰缓存数，避免集体失效事件发生
但缓存是针对读，如果写的压力很大，怎么办？
高写入：消息中间件
同理，通过跟主库加机器，耗费的机器资源是很大的，这个就是数据库系统的特点所决定的。
相同的资源下，数据库系统太重太复杂，所以并发承载能力就在几千/s的量级，所以此时你需要引入别的一些技术。
比如说消息中间件技术，也就是MQ集群，它是非常好的做写请求异步化处理，实现削峰填谷的效果。
消息队列能做解耦，在只需要最终一致性的场景下，很适合用来配合做流控。
假如说，每秒是1万次写请求，其中比如5千次请求是必须请求过来立马写入数据库中的，但是另外5千次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。
那么此时完全可以引入消息中间件集群，把允许异步化的每秒5千次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的1000/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。
业界有很多着名的消息中间件，比如ZeroMQ，rabbitMQ，kafka等。
消息队列本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用它来支撑部分允许异步化的高并发写入是很合适的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。
避免挤兑：流控
再强大的系统，也怕流量短事件内集中爆发，就像银行怕挤兑一样，所以，高并发另一个必不可少的模块就是流控。
流控的关键是流控算法，有4种常见的流控算法。
计数器算法（固定窗口）：计数器算法是使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略，下一个周期开始时，进行清零，重新计数，实现简单。计数器算法方式限流对于周期比较长的限流，存在很大的弊端，有严重的临界问题。
滑动窗口算法：将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。此算法可以很好的解决固定窗口算法的临界问题。
漏桶算法：访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。分布式环境下实施难度高。
令牌桶算法：程序以r（r=时间周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略。分布式环境下实施难度高。
4、高并发的实践经验
接入-逻辑-存储是经典的互联网后端分层，但随着业务规模的提高，逻辑层的复杂度也上升了，所以，针对逻辑层的架构设计也出现很多新的技术和思路，常见的做法包括系统拆分，微服务。
除此之外，也有很多业界的优秀实践，包括某信服务器通过协程（无侵入，已开源libco）改造，极大的提高了系统的并发度和稳定性，另外，缓存预热，预计算，批量读写（减少IO），池技术等也广泛应用在实践中，有效的提升了系统并发能力。
为了提升并发能力，逻辑后端对请求的处理，一般会用到生产者-消费者多线程模型，即I/O线程负责网络IO，协议编解码，网络字节流被解码后产生的协议对象，会被包装成task投入到task queue，然后worker线程会从该队列取出task执行，有些系统会用多进程而非多线程，通过共享存储，维护2个方向的shm queue，一个input q，一个output q，为了提高并发度，有时候会引入协程，协程是用户线程态的多执行流，它的切换成本更低，通常有更好的调度效率。
另外，构建漏斗型业务或者系统，从客户端请求到接入层，到逻辑层，到DB层，层层递减，过滤掉请求，Fail Fast（尽早发现尽早过滤），嘴大屁眼小，哈哈。
漏斗型系统不仅仅是一个技术模型，它也可以是一个产品思维，配合产品的用户分流，逻辑分离，可以构建全方位的立体模型。
5、小结
莫让浮云遮望眼，除去繁华识真颜。我们不能掌握了大方案，吹完了牛皮，而忽视了编程最本质的东西，掌握最基本最核心的编程能力，比如数据架构和算法，设计，惯用法，培养技术的审美，也是很重要的，既要致高远，又要尽精微。