目前公司项目并发量小，架构简单，但出于一些原因不想离开，而且公司项目水平短期内不会有提高如何在公司现有情况下，接触实际的高并发大数据项目，就是想实操一下高并发的架构设计，或者，参与互联网级别项目的开发，但又不想舍弃现在的工作

如果你是一个工作刚不久的巨婴，那么首先，不要急于学习大型网站的架构设计，此时此刻做任何项目都可以学到很多东西，并发量不高的项目你可以多学习学习代码设计，要是工作不那么忙你还可以在公司学习。任何产品不可能一开始的时候就是高并发架构。但是我们要时刻准备好迎接大流量。如果你确实希望能够直接接触高并发项目，那也不是不可以。我给你一个实际操作的思路。首先你需要了解jmeter工具，高并发的项目通常会用它来进行并发测试。并发我们通常会分为两种，一种是读并发，一种是写并发。

模拟读并发

• 第一阶段：正常情况下，我们编写一个接口都是直接访问数据库获取数据，那这样肯定是占用数据库连接的，所以并发数不会很高。
• 第二阶段：我们为数据添加缓存，访问时我们先访问缓存，比如redis，如果缓存中没有数据我们再从数据库中读取，这里就会涉及到缓存雪崩和穿透的问题。这些问题咱们可以忽略不计，因为解决办法很简单，而且有很多种。添加缓存就减少了数据库压力，更重要的是我们增加了请求的IOPS（吞吐量），也就意味着我们的服务器一秒钟可以处理更多的请求，也就提高了并发量。
• 第三阶段：当我们的缓存处理的IOPS比我们的服务器最高支持的并发数还高，比如Tomcat优化的好的话可以有1.5k左右（有人说可以达到6k），不过我觉得这个跟你机器的内存和tomcat的配置有关，咱们暂且假定是1.5k。如果你要超过1.5k的并发，那么此时你就需要增加服务器或者换一种并发量更高的服务器。我们以增加服务器为例，你可以添加1台服务器来支持更高的并发，然后通过nginx进行负载均衡，将流量分配到两台tomcat中。我们知道nginx的最高并发可以达到3W，也就是意味着你可以添加20台tomcat。
• 第四阶段：当nginx成为了我们的并发瓶颈，我们就要做nginx集群了。这也意味着我们需要将一个地区划分成多个小地区，每个地区配置一个公网nginx。而这种做法有两种，一种是通过网络路由层增加控制来实现分发，一种是通过硬件来实现，硬件的我没操作过，自己实践也不实际，因为很贵！

当然，我们并不能直接通过增加最高并发量就能处理并发，比如数据库层面中途我们就需要改成主从机制，采用分库分表或者使用mongodb这种高吞吐量的数据库来做。比如我们的机器配置也需要增加等。

模拟写并发

写并发跟读并发的区别主要在于写的时间往往比较长，读的时间我们通过缓存来提高，但写库这个动作我们并不能通过缓存来处理，此时就需要我们增加消息队列MQ，最终走向MQ的集群。增加MQ以后我们的请求只是把写库这项任务添加到队列中，然后一条一条地执行，但是用户发起的请求我们立即返回成功标志。这样可以不占用服务线程。也就提高了并发量，同时也需要修改我们的业务，比如正常下单是订单入库后返回成功，并发量上来后我们就需要调整为订单加入队列后成功，并没有入库，那么此时不能告诉用户下单成功，而是提醒用户正在下单，然后前端每1秒钟去查询订单看是否存在，如果存在再提示下单成功。

最后

总的来说，我们知道了一套高并发的常见处理方式和原理，我们就可以自己去模拟一下。讲真的在公司基本学不到啥东西，一般都是靠自己做项目来完成一些自己想要的效果或者自己想实践的技术和经验。我自己就开发了一个代码开发平台，你也可以了解一下，叫懒猴子CG。前端用的nuxt，后端用的springboot，基本都不怎么架构，但是从前端到后端基本都是我一个人开发的，所以还是会学到很多东西。即使流量大了，我也有办法撑起来，这就是自己做项目去实践的一个好处，可以经历一下从无到有的整个过程。

祝你顺利！

如何做一个和滴滴打车一样的高并发互联网架构？

其实互联网的高并发架构解决方案很多，而且大多都存在很多共同的地方，我们常常用秒杀来作为高并发设计的案例，因为秒杀的单点时间内的请求量是非常高的。如果我们把场景换成滴滴打车的话，其实也有很多共通的部分。

现在我们就来简单的分析一下滴滴打车的架构可能是怎么设计的吧

我们先看看一个打车的场景，都会经过多少流程吧。

当我们需要打车的时候，我们打开APP，选择自己想要的车辆类型，然后发起请求。这时我们的请求进入到应用服务器，应用服务器进行处理以后，按照一定的算法，找到最近的空闲的车辆，然后指派车辆，如果没有找到合适的车辆，就会进入等待状态。当找到合适的车辆时，将我们的所在地推送给司机，然后把司机的相关数据返回给我们的APP。

我经历的几家公司里，或多或少用到了高并发技术，下面结合自己的经验，姑且说下。。。

首先，需要不得不提下并发的概念！

并发(量):指定时间段内，系统同时处理的请求数！所以高并发是指指定时间内，系统同时处理大量的连接(请求)！

衡量并发量通常有一些特定的指标:

①，TPS(QPS):每秒的处理事务数量或者请求数量。

②，响应时间:完成一个请求需要的平均时间！

从这两个指标可以看到，提高并发能力落在了下面几个问题上:

1，如何提高并发连接数？你业务写的再好，如果服务器只允许几千的最大连接数（比如tomcat），那么你的并发能力就只能被限制在几千，为什么最大连接数被限制呢？早期的网络连接模型使用的是一个连接对应一个线程，这样内存开销很大，支撑不了大量的连接！

我们先来说高并发吧。

什么是高并发？

高并发是互联网分布式系统架构设计中必须考虑的因素之一，它通常指：通过设计保证系统能够同时并行处理很多的请求。

高并发有哪些指标？

响应时间：系统对请求做出 响应的时间。例如：处理一个HTTP请求需要200ms，那200ms就是响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每条响应的请求数量。其实这个指标和吞吐量区分不明显。

并发数量：同时承载正常使用系统功能的用户数量。例如：QQ同时在线的用户数量其实也就是并发数量了。

如何提高并发能力？

提高系统的能发能力，主要有两种方式：垂直扩展和水平扩展

垂直扩展

其实就是提升单机的处理能力，一般又有两种方法：

1）增强单机硬件性能

这个方法简单暴力，升级CPU，升级硬盘，升级内存，升级网卡。

2）提升单机架构性能

这个方式就是委婉一点了，我们通过缓存，尽量的减少IO的次数，使用异步的线程处理，增加服务的吞吐量，使用无锁的数据结构，减少响应时间等等。

在互联网飞速发展的时期，提升单机硬件性能往往是最快的方法，因为这个阶段，时间是最包括的，升级硬件是最能够有效解决问题的方式，而且时间成本几乎可以不考虑。

但是这个方法有一个致命的缺点，就是，单机的性能是有极限的，但是用户的增长理论上可以是无限的，所以，解决问题的根源，这个方式并不适用，我们更多的还是选择水平扩展的方式

水平扩展

水平扩展，其实就是增加服务器的数量，从而线性扩充系统的性能，但是，这个就对系统的架构设计有要求了，如何让架构各层能够进行水平扩展的设计，就是系统设计的重点了。

常见的分层架构

常见的分布式架构如上图：

1. 客户端层：浏览器或者手机APP

2. 反向代理层：系统入口、反向代理

3. 站点应用层：实现核心的逻辑，返回html或者json

4. 服务层：这一层可以有，也可以没有，如果我们没有实现服务化，也就没有这个了

5. 数据缓存层：缓存部分数据，加速访问速度，减少数据库的IO

6. 数据库层：固化数据的存储

水平扩展架构实践

反向代理层的水平扩展

其实是通过DBS轮询实现的：DNS-SERVER对于一个域名配置了多个解析IP，每次DNS解析请求来访问DNS-SERVER，会轮询返回这些IP。

当Nginx成为瓶颈的时候，只要增加服务器数量，部署Nginx服务，增加IP，就可以扩展反向代理层的性能，理论上是可以实现无限高并发的。

站点层的水平扩展

站点层的水平扩展是通过Nginx实现的，通过修改Nginx配置，设置多个web后端。当web后端成为瓶颈时，增加web服务器，加入Nginx配置中，就可以理论上实现无限高并发了。

服务层水平扩展

服务层的水平扩展，是通过服务连接池实现的。

站点层通过RPC-client调用下游服务层RPC-server时，当服务层成为瓶颈时，增加服务器，部署到RPC-client下游服务连接中，就可扩展性能了。

数据库层的水平扩展

缓存想要扩展是很简单的，只需要细化缓存的颗粒就行了，例如某一个服务器，缓存哪些类型的数据，我们一般缓存的数据并不会很多，通常都是变化频率不高的数据进行缓存，变化频率高的数据，缓存的意义相对较小。

但是，数据库其实是有极限的，随着我们数据量的增加，数据库的压力越来越大。

一般我们的处理就是，分库分表。

将数据层水平拆分，例如服务器A存储用户数据，服务器B存储订单数据。这样，我们就可以实现服务器的水平扩充。

但是有时候，一个表，例如订单表的数据量就会非常的大。

我们又会对这样类型的表进行垂直的拆分。

将表分为order1，order2……

通过orderid的范围来确定应该查询那个数据库。

例如：order1库，存储orderid1—1kw

order2库，存储orderid1kw-2kw

这样，我们就能很好的对数据进行路由，并且数据均衡性较好，也容易扩展。

小结

其实，能够实现高并发的技术很多。

好像我们在做秒杀的时候，其实我们从客服端、站点层，到服务层，每一层都有一个过滤，让无效的访问能够被过滤，减少数据层的IO，其实，数据层是最容易产生瓶颈的一层，所以，我们的所有工作，就是尽可能的少对数据层进行访问，提高吞吐量。

所以，类似队列，缓存，负载均衡都是一些常用的手段。

千万级用户的大型网站，应该如何设计其高并发架构？

这个问题非常有针对性，我从十步攻略来回答你的问题：

第一步：物理分离webserver和数据库

最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。

第二步：增加页面缓存

好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。

第三步：增加页面片段缓存

增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；

第四步：数据缓存

在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系 统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。

第五步： 增加webserver

好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有： 1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案； 2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等； 3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存； 4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等； 在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。

第六步：分库

享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的 资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；

但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。

第七步：分表、DAL和分布式缓存

随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可 能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；

DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等；

第八步：增加更多的webserver

在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势 了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战： 1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购 买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载集群中； 2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等； 在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。

第九步：数据读写分离和廉价存储方案

突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不 容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一些更为廉价的存储方案，例如BigTable这种。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：

数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；

廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。

第十步：进入大型分布式应用时代和廉价服务器群梦想时代

经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量了，对于大型网站而言，人气的重要毋 庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大 了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦， 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将 系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战： 1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式； 2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控制等； 3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。 经过这一步，差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。

看看这一步完成后系统的图示：

这一步涉及到了这些知识体系：

这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。

运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。

说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及，像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易，写这篇文章更多的是希望能够引出更多大型网站架构演变的介绍。

以上介绍完毕，BAT的技术演进之路，请保存，欢迎关注。欢迎吐槽