lamp架构提高服务器并发要注意哪些问题

　对于大流量、大并发量的网站系统架构来说，除了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能的 *** 作系统（OS）、高性能的网页服务器（Web Server）、高性能的数据库（Databse）、高效率的编程语言等。下面我将从这几点对其一一讨论。
*** 作系统
Linux *** 作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprice、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性和性能的考虑， *** 作系统选择CentOS（Community ENTerprise Operating System）是一个理想的方案。
CentOS（Community ENTerprise Operating System）是Linux发行版之一，是RHEL/Red Hat Enterprise Linux的精简免费版，和RHEL为同样的源代码，不过，RHEL和SUSE LE等企业版，提供的升级服务均是收费升级，无法免费在线升级，因此要求免费的高度稳定性的服务器可以用CentOS替代Red Hat Enterprise Linux使用。
LAMP网站架构图
Web服务器、缓存和PHP加速
Apache是LAMP架构最核心的Web Server，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销大，性能上有损耗，不如一些轻量级的Web服务器（例如nginx）高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。
Apache做为Web Server是负载PHP的最佳选择，如果流量很大的话，可以采用nginx来负载非PHP的Web请求。nginx是一个高性能的>现在有一个系统，他有两个接口并发量特别高，或者说比其他接口高出几个档次。
那么如何针对这两个接口进行处理？
目前我有几点疑惑。
1、不少高并发网站在指出将模块服务化，这样可以对各个模块进行负载均衡，按需分配，那么他其实是代码层级上就是分开编写的还是只是部署在不同的机器上用nginx转发实现模块化？
2、如果代码不是分开编写的，像这种个别接口访问量高的应该怎么处理。
3、就算是分开编写，每个服务已经自成一个系统，那么如何处理该系统中极个别接口访问量特别高的情况？
现在想到的方法是：
使用nginx负载均衡，针对这两个接口给予专门的服务器集群做处理（代码还是那一套）。
我不知道这样做是不是正确的？因为我为了这两个接口部署了整个系统，我感觉是有问题的。
请各位大牛指点迷津，或提供一些参考资料。

集群通信系统是一种用于集团调度指挥通信的移动通信系统，主要应用在专业移动通信领域。该系统具有的可用信道可为系统的全体用户共用，具有自动选择信道功能，它是共享资源、分担费用、共用信道设备及服务的多用途、高效能的无线调度通信系统。

本文先提供一个没有采用的方式--采用事务加select for update的形式

这么做呢就有个非常严重的问题,--- 同一时刻只有一个有效服务
如果A系统拿到了数据,开始了事务但是没提交,那么B系统同样的条件也会查到同一批还没处理好提交的数据,此时B系统该查询线程就会阻塞等待A提交事务这么看问题就来了,这里虽然保障了同一时刻只有一个服务可以拿到并处理一批数据,但是也导致了效率特别低,而且后面 无论扩展多少服务应用都没啥用

步骤解释:

我这里只写了大致的方案,一些redis高可用以及数据幂等性自己考虑去

这种方式是 我觉得最好的方案 了,完全保障了每个服务每次 处理 mysql的数据都是 互不相同的数据 ,完全 避免了竞争 问题

但是我们目前没有用这种方案,原因是目前我们redis内存只申请到一个比较小的内存,而 zset采用的跳跃表结构虽然保障了数据查询非常快速,但是也非常占用内存 ,预估了一下按照我们的数据量起码要存储300万数据,用到的内存量是 3~4G 之间,好家伙直接把我们所有内存都用了,其他服务还用个屁而且这玩意为了保障数据安全,不进行数据淘汰起码还要留个1G空闲安全空间那肯定就用不了了

如果你们的服务 数据量够小 或者 内存够大 ,redis又做到了 高可用,高可靠 ,那么我还是 十分推荐 用这种方案,毕竟很多服务都是 性能为王!

消息服务器使用socket，为避免服务器过载，单台只允许500个socket连接，当一台不够的时候，扩充消息服务器是必然，问题来了，如何让链接在不同消息服务器上的用户可以实现消息发送呢？

要实现消息互通就必须要让这些消息服务器本身能互通，想了两个方式，一种是消息服务器之间交叉链接，另一种是增加一个特殊的消息服务器，这个消息服务器不对外开放，只负责消息转发和推送。

下列测试不考虑防火墙等。仅测试可行性和效率。

消息服务器

转发服务器

公共缓存

软件环境

client1 可向 client2 或者其他 client 发送消息，并接收其他 client 发送的消息
Redis 中保存 client 连接的信息，给每个用户分配唯一的 key ,包括链接的哪台服务器,转发服务器定时检测消息服务器，如消息服务器挂掉，由转发服务器清理掉Redis已经挂掉的所有链接。

1 Client1 给 Client2 发送一条消息
2 Socket1 接收到消息，根据 key从Redis 取出 Client2 的连接信息，连接在本机，直接推送给 Client2 ，流程结束。
3如果连接不在本机，把消息推送到转发服务器,由转发服务器把该消息推送给连接所在消息服务器，消息服务器接收消息，推送给 Client2 。

服务器上创建一个serverphp,内容如下：

上只需把ip变更一下即可。1921680201变更为1921680202

在转发服务器上建立脚本proxyphp，内容如下：

注意开启顺序

1开启转发服务器php proxyphp

2分别开启socket服务器php serverphp

可以在转发服务器上看到两个消息服务器已经连接
3开始测试，分别打开两个telnet,连接两个消息服务器，发送消息测试：
登陆

基于强大的 swoole 扩展，让php高效的实现这些成为可能，目前消息服务器到转发服务器是长连接，转发服务器到消息服务器是短连接，存在性能瓶颈，也浪费了连接资源。下一步改造成长连接，消息服务器的client使用异步。

没有准确的答案的。

这款配置还是相对较高的配置，以官网来说，每天大概500ip，PV大概3000左右，同时在线人数最多不会超过50人吧，这种流量相对一个企业站来说还算可以，这个服务器完全可以符合要求，目前运行了相当长时间，服务器没有出现过任何中断，截取Alexa的排名数据仅供参考。

扩展资料：

这款配置的峰值并发用户应该可以到几百个用户，这里有太多因素决定同时并发数了，比如网站视频数量多少，数据库是否和文件服务器分开，每个用户在站点上打开的页面多少等都会影响服务器负载。

另外这些数据其实都只是一个预估的数据，显示情况远比理想状况复杂很多很多，比如要是在这台服务器安装配置一些额外的服务，而当前服务运行的进程可能就会直接对服务器造成负载的提升等等。

因此能支持多少用户这种问题本身就是一个伪命题，要具体情况具体分析，不过可以肯定的是这个配置可以支持绝大部分企业站点的正常运行相当长时间。

参考资料来源：百度百科——服务器

---