如何处理高并发

处理高并发的六种方法

1：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。

2：缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考的虑考虑你的项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。

3：MQ(消息队列)，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。

4：分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

5：读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6：solrCloud:

SolrCloud(solr 云)是Solr提供的分布式搜索方案，可以解决海量数据的 分布式全文检索，因为搭建了集群，因此具备高可用的特性，同时对数据进行主从备份，避免了单点故障问题。可以做到数据的快速恢复。并且可以动态的添加新的节点，再对数据进行平衡,可以做到负载均衡：

首先，我们需要了解epoll编程的概念。epoll是一项对Linux内核进行的轮询，以处理大量的文件描述符和一个增强版的Linux下多路复用IO接口选择/投票。

一个成熟的高性能服务器，epoll相关代码，不到1万分之一。在今天的posix和Unix /BSD/ systemv设计的回顾中，epoll补丁不应该被实现。异步反应器框架应该只有一个简单的、统一的选择器。

但通常门户服务器，所有无辜的人:高性能服务器开发= = EPOLL，可以出现EPOLL这是自吹自擂的垃圾，姚明是posix，或者是Unix /BSD/ systemv的早期版本，这是不完美的设计考虑因素。Epoll编程，具有以下高并发服务器开发:

1、大部分业务是更多的客户端接入，如果接入基本超过8小时的连接，但登陆客户端基本不怎么活动，因此只有客户端触发设置相关事件会产生主动沟通。

2、在大量查阅资料后我们发现，单单多进程是不现实的。

3、QQ等的多客户端登陆软件，服务器要怎么设计开发。

4、客户端接入时间随机，系统运行初期不会存在同一时间有非常非常多用户登陆的情况，但是用户一旦接入服务器就会长时间不可能断开。

5、是不是可以使用epoll技术跟多线程技术配合开发？如何？

6、系统应该怎样开发使用TCP协议。

限流算法目前程序开发过程常用的限流算法有两个：漏桶算法和令牌桶算法。

漏桶算法

漏桶算法的原理比较简单，请求进入到漏桶中，漏桶以一定的速率漏水。当请求过多时，水直接溢出。可以看出，漏桶算法可以强制限制数据的传输速度。如图所示，把请求比作是水滴，水先滴到桶里，通过漏洞并以限定的速度出水，当水来得过猛而出水不够快时就会导致水直接溢出，即拒绝服务。

来自网络

漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。

令牌桶算法

令牌桶算法的原理是系统以一定速率向桶中放入令牌，如果有请求时，请求会从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。这种算法可以应对突发程度的请求，因此比漏桶算法好。

来自网络

漏桶算法和令牌桶算法的选择

两者的主要区别漏桶算法能够强行限制处理数据的速率，不论系统是否空闲。而令牌桶算法能够在限制数据的平均处理速率的同时还允许某种程度的突发流量。如何理解上面的含义呢？漏桶算法，比如系统吞吐量是 120/s，业务请求 130/s，使用漏斗限流 100/s，起到限流的作用，多余的请求将产生等待或者丢弃。对于令牌桶算法，每秒产生 100 个令牌，系统容量 200 个令牌。正常情况下，业务请求 100/s 时，请求能被正常被处理。当有突发流量过来比如 200 个请求时，因为系统容量有 200 个令牌可以同一时刻处理掉这 200 个请求。如果是漏桶算法，则只能处理 100 个请求，其他的请求等待或者被丢弃。

php 高并发解决思路解决方案，如何应对网站大流量高并发情况。本文为大家总结了常用的处理方式，但不是细节，后续一系列细节教程给出。希望大家喜欢。

一 高并发的概念

在互联网时代，并发，高并发通常是指并发访问。也就是在某个时间点，有多少个访问同时到来。

二 高并发架构相关概念

1、QPS (每秒查询率) : 每秒钟请求或者查询的数量，在互联网领域，指每秒响应请求数(指 HTTP 请求)

2、PV（Page View）：综合浏览量，即页面浏览量或者点击量，一个访客在 24 小时内访问的页面数量

--注：同一个人浏览你的网站的同一页面，只记做一次 pv

3、吞吐量（fetches/sec） ：单位时间内处理的请求数量 （通常由 QPS 和并发数决定）

4、响应时间：从请求发出到收到响应花费的时间

5、独立访客（UV）：一定时间范围内，相同访客多次访问网站，只计算为 1 个独立访客

6、带宽：计算带宽需关注两个指标，峰值流量和页面的平均大小

7、日网站带宽： PV/统计时间（换算到秒） 平均页面大小（kb） 8

三 需要注意点：

1、QPS 不等于并发连接数（QPS 是每秒 HTTP 请求数量，并发连接数是系统同时处理的请求数量）

2、峰值每秒请求数（QPS）= （总 PV 数80%）/ （六小时秒数20%）代表 80%的访问量都集中在 20%的时间内

3、压力测试： 测试能承受的最大并发数 以及测试最大承受的 QPS 值

4、常用的性能测试工具ab，wrk，httpload，Web Bench，Siege，Apache JMeter

四 优化

1、当 QPS 小于 50 时

优化方案:为一般小型网站,不用考虑优化

2、当 QPS 达到 100 时,遇到数据查询瓶颈

优化方案: 数据库缓存层,数据库的负载均衡

3、当 QPS 达到 800 时, 遇到带宽瓶颈

优化方案:CDN 加速,负载均衡

4、当 QPS 达到 1000 时

优化方案: 做 html 静态缓存

5、当 QPS 达到 2000 时

优化方案: 做业务分离,分布式存储

五、高并发解决方案案例:

1、流量优化

防盗链处理(去除恶意请求)

2、前端优化

(1) 减少 HTTP 请求[将 css,js 等合并]

(2) 添加异步请求(先不将所有数据都展示给用户,用户触发某个事件,才会异步请求数据)

(3) 启用浏览器缓存和文件压缩

(4) CDN 加速

(5) 建立独立的服务器(减少 I/O)

3、服务端优化

(1) 页面静态化

(2) 并发处理

(3) 队列处理

4、数据库优化

(1) 数据库缓存

(2) 分库分表,分区

(3) 读写分离

(4) 负载均衡

5、web 服务器优化

(1) nginx 反向代理实现负载均衡

(2) lvs 实现负载均衡

Nginx 采用的是多进程（单线程） & 多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的服务器。

异步非阻塞

1、Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。

2、接收来自外界的信号，向各worker进程发送信号，每个进程都有可能来处理这个连接。

3、 master 进程能监控 worker 进程的运行状态，当 worker 进程退出后(异常情况下)，会自动启动新的 worker 进程。

worker 进程数，一般会设置成机器 cpu 核数。因为更多的worker 数，只会导致进程相互竞争 cpu，从而带来不必要的上下文切换

惊群现象

主进程（master 进程）首先通过 socket() 来创建一个 sock 文件描述符用来监听，然后fork生成子进程（workers 进程），子进程将继承父进程的 sockfd（socket 文件描述符），之后子进程 accept() 后将创建已连接描述符（connected descriptor）），然后通过已连接描述符来与客户端通信。

那么，由于所有子进程都继承了父进程的 sockfd，那么当连接进来时，所有子进程都将收到通知并“争着”与它建立连接，这就叫“惊群现象”。大量的进程被激活又挂起，只有一个进程可以accept() 到这个连接，这当然会消耗系统资源。

Nginx对惊群现象的处理

Nginx 提供了一个 accept_mutex 这个东西，这是一个加在accept上的一把共享锁。即每个 worker 进程在执行 accept 之前都需要先获取锁，获取不到就放弃执行 accept()。有了这把锁之后，同一时刻，就只会有一个进程去 accpet()，这样就不会有惊群问题了。accept_mutex 是一个可控选项，我们可以显示地关掉，默认是打开的。

主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。

worker进程工作流程

当一个 worker 进程在 accept() 这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，一个完整的请求

什么是IO多路复用呢？

对于操作系统而言，IO多路复用就是要完成操作系统IO的请求。对于IO文件的请求，当一个IO流要进行文件处理的时候，要获取一组文件的描述符，当文件描述符还没有就绪时，那么它就在等待，直到描述符一旦就绪，马上上报系统通知的机制，告诉应用程序我准备就绪，你可以来操作了。这就是IO多路复用的方式。

这种机制处理起来就很高效，多路复用就是在一个线程里，交替并发的完成。复用的就是一个线程。

　　服务程序最为关键的设计是并发服务模型，当前有以下几种典型的模型：

　　- 单进程服务，使用非阻塞IO

　　使用一个进程服务多个客户，通常与客户通信的套接字设置为非阻塞的，阻塞只发生在select()、poll()、epoll_wait()等系统调用上面。这是一种行之有效的单进程状态机式服务方式，已被广泛采用。

　　缺点是它无法利用SMP(对称多处理器)的优势，除非启动多个进程。此外，它尝试就绪的IO文件描述符后，立即从系统调用返回，这会导致大量的系统调用发生，尤其是在较慢的字节传输时。

　　select()本身的实现也是有局限的：能打开的文件描述符最多不能超过FD_SETSIZE，很容易耗尽；每次从select()返回的描述符组中扫描就绪的描述符需要时间，如果就绪的描述符在末尾时更是如此（epoll特别彻底修复了这个问题）。

　　- 多进程服务，使用阻塞IO

　　也称作 accept/fork 模型，每当有客户连线时产生一个新的进程为之服务。这种方式有时是必要的，比如可以通过操作系统获得良好的内存保护，可以以不同的用户身份运行程序，可以让服务运行在不同的目录下面。但是它的缺点也很明显：进程比较占资源，进程切换开销太大，共享某些信息比较麻烦。Apache 13就使用了这种模型，MaxClients数很容易就可以达到。

　　- 多线程服务，使用阻塞IO

　　也称之 accept/pthread_create模型，有新客户来时创建一个服务线程而不是服务进程。这解决了多进程服务的一些问题，比如它占用资源少，信息共享方便。但是麻烦在于线程仍有可能消耗光，线程切换也需要开销。

　　- 混合服务方式

　　所谓的混合服务方式，以打破服务方和客户方之间严格的1:1关系。基本做法是：

　　新客户到来时创建新的工作线程，当该工作线程检测到网络IO会有延迟时停止处理过程，返回给Server一个延迟处理状态，同时告诉 Server被延迟的文件描述符，延迟超时时间。Server会在合适的时候返回工作线程继续处理。注意这里的工作线程不是通过 pthread_create()创建的，而是被包装在专门用于处理延迟工作的函数里。

　　这里还有一个问题，工作线程如何检测网络IO会有延迟？方法有很多，比如设置较短的超时时间调用poll()，或者甚至使用非阻塞IO。如果是套接字，可以设置SO_RCVTIMEO和SO_SNDTIMEO选项，这样更有效率。

　　除了延迟线程，Server还应提供了未完成线程的支持。

　　如有有特别耗费时间的操作，你可以在完成部分工作后停止处理，返回给Server一个未完成状态。这样Server会检查工作队列是否有别的线程，如果有则让它们运行，否则让该工作线程继续处理，这可以防止某些线程挨饿。

　　典型的一个混合服务模型开源实现ServerKit

　　Serverkit的这些线程支持功能可简化我们的服务程序设计，效率上应该也是有保证的。

　　2 队列(queue)

　　ServerKit提供的队列是一个单向链表，队列的存取是原子操作，如果只有一个执行单元建议不要用，因为原子操作的开销较大。

　　3 堆(heap)

　　malloc()分配内存有一定的局限，比如在多线程的环境里，需要序列化内存分配操作。ServerKit提供的堆管理函数，可快速分配内存，可有效减少分配内存的序列化操作，堆的大小可动态增长，堆有引用计数，这些特征比较适合多线程环境。目前ServerKit堆的最大局限是分配单元必须是固定大小。

　　4 日志记录

　　日志被保存在队列，有一个专门的线程处理队列中的日志记录：它或者调用syslog()写进系统日志，或者通过UDP直接写到远程机器。后者更有效。

　　5 读写锁

　　GNU libc也在pthreads库里实现了读写锁，如果定义了__USE_UNIX98就可以使用。不过ServerKit还提供了读写锁互相转换的函数，这使得锁的应用更为弹性。比如拥有读锁的若干个线程对同一个hash表进行检索，其中一个线程检索到了数据，此时需要修改它，一种办法是获取写锁，但这会导致释放读锁和获取写锁之间存在时间窗，另一种办法是使用ServerKit提供的函数把读锁转换成写锁，无疑这种方式更有效率。

　　除了以上这些功能，ServerKit还提供了数据库连接池的管理（当前只支持MySQL）和序列化（Sequences），如感兴趣可参见相关的API文档。

　　二、ServerKit服务模块编写

　　ServerKit由3部分组成：server程序，负责加载服务模块、解析配置文件、建立数据库连接池；libserver，动态链接库，提供所有功能的库支持，包括server本身也是调用这个库写的；API，编程接口，你编写的服务模块和ServerKit框架进行对话的接口。

　　ServerKit需要libConfuse解析配置文件，所以出了安装ServerKit，还需要安装libConfuse。关于libConfuse可参考 http://wwwnongnuorg/confuse/ 。

　　下面我们看一个简单的服务模块FOO：

　　#include <confuseh>

　　#include <serverh>

　　static long int sleep_duration;

　　static int FOO_construct()

　　{

　　fprintf(stderr, "FOO_construct\n");

　　return 1;

　　}

　　static int FOO_prestart(cfg_t configuration)

　　{

　　fprintf(stderr, "FOO_prestart\n");

　　return 1;

　　}

　　static void FOO_operator(void foobar)

　　{

　　fprintf(stderr, "FOO_operator\n");

　　for(;;) sleep(sleep_duration);

　　return NULL;

　　}

　　static void FOO_report(void)

　　{

　　fprintf(stderr, "FOO_report\n");

　　}

　　

　　static cfg_opt_t FOO_config[] = {

　　CFG_SIMPLE_INT("sleep_duration", &sleep_duration),

　　CFG_END()

　　};

　　static char FOO_authors[] = {"Vito Caputo <vcaputo@pengarucom>", NULL};

　　

　　SERVER_MODULE(FOO,0,0,1,"Example module that does nothing but sleep")

　　

　　按以下方法编译：

　　$ gcc -c -fPIC -pthread -D_REENTRANT -g FOOc

　　$ gcc -shared -lserver -lconfuse -lpthread -g -e __server_module_main -o FOOso FOOo

　　-e选项指定程序运行入口，这使得你可以直接在命令行敲 /FOOso 运行模块。

　　server程序根据环境变量SERVER_PERSONALITY_PATH定位主目录，并查找主目录下的c11n作为配置文件，动态加载的模块需放在主目录下的modules目录。

　　$ export SERVER_PERSONALITY_PATH=`pwd`

　　$ mkdir modules

　　$ cp FOOso modules

　　$ vi c11n

　　c11n的内容：

　　identity = "any_id"

　　FOO {

　　sleep_duration = 1;

　　}

　　identity标识server实例，用ps可看到程序名称形如serveridentity，本例为serverany_id。

　　执行server启动服务程序。

　　三、ServerKit其他功能缺陷

　　缺乏daemon模式；

　　只能运行在Linux box；

　　DB pool只支持MySQL；

　　Heap管理内存的功力有限

实现高并发

一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。