求教给位，如何做基于 lamp 的分布式服务器架构？

[Jacklee]

RT，目前web项目都是单点服务，由于访问量和数据量逐渐增大，服务器挂掉的概率也上升，影响也很大，考虑到减少对线上项目的影响，想做成多点服务，咨询了下前辈，说可以做分布式架构。服务器和数据库都备两台，一台出问题，可切换到服务正常的服务器。
我是这方面的小白，所以发个帖求问大牛们，提供一些细节或者一些相关资料，多谢！

[mhycy]

第一层:
单点/多点出口,利用DNS负载均衡,使用nginx反向代理.
(此法入口单点失效不会全挂)

第二层:
Apache/PHP服务器
Session使用网络方式单点储存/实现一个同步分发机制
静态文件需要依据业务实现一个同步分发机制.
最优做法是静态文件独立储存与访问, 需要同步的仅仅是网站源码

第三层
MySQL实现一主多从结构,主写从读.

[9hills]

VIP + LVS（两台）+ NGINX（N台）+ 应用服务器（N台）+ 数据库服务器（一主多从1备）

其中NGINX可和应用放到同一台机器上。

[Jacklee]

@mhycy 感谢，这个方向从成本和性能上都很不错，目前我们静态文件已经是独立服务器，所以要做的工作集中于你所提的第一层、第二层中的“session使用网络方式单点储存/实现一个同步分发机制 (这一点能否cookie存在客户端代替？)”以及第三层，这个我需要研究研究，目前还在收集一些资料

[Jacklee]

@9hills 好高端，这个方案不知道成本方面，以及涉及session方面是如何解决的呢，因为VIP + LVS我都不太了解

[mhycy]

@Jacklee
Cookie就没这方面考虑了.
因为Session的特殊性所以需要同步而已.(因为Session数据存在于服务器端)

关于第三点, 一般而言LAMP站点压力最大的不是静态文件就是数据库, 所以一主多从结构可以优化访问.
主数据库负责写入的原因是为了数据一致性, 因为读取对时效性/一致性要求不高, 所以从库读取减轻压力.
(也没哪些应用是写入压力高于读取压力的)

[hcymk2]

@mhycy
第三层 MySQL实现一主多从结构,主写从读

如何在原有项目代码改动最小的情况下实现？

[mhycy]

@hcymk2 MySQL-Proxy

[Jacklee]

@mhycy 恩恩，很有道理，除了某些用户量很大的应用，基本都是读操作压力最大；我们之前就遇到大量读取导致数据库too many connections崩掉的，所以才考虑做这个事情

[mhycy]

@Jacklee
其实 @9hills 的方案原理是一致的, 只是入口服务器的方案换掉了, 增加可靠性.
具体实现建议使用此方案.方案细节可用 "LVS 高可用" 作为关键字查询得到.
这个方案需要交换机支持, VIP 就是 Virtual IP 的缩写.

[mhycy]

@Jacklee
补充: 实际建议使用 @9hills 的方案
这个方案对于入口服务器的单机故障有更短的恢复时间(秒级)

[Jacklee]

@mhycy 那如果MySQL-Proxy挂掉了呢

[Jacklee]

@mhycy 那感觉@9hills的方案都得到普遍认同啊，我去研究研究，多谢

[mhycy]

@Jacklee
Proxy是分布式部署在应用服务器,真要挂掉这台应用服务器可以下线重启了.
另: 不止mysql-proxy一个选择还有别的工具可用, 具体需要自行分析...

[Jacklee]

@mhycy 原来如此，了解了，多谢

[9hills]

@Jacklee

确定高可用方案，首先要确定可用性等级。非常简单的说一说：

99.99% 架构，最少两个IDC，保证数据一致性，进行流量切换。。。很麻烦
99.9%架构，只需要一个IDC，但需要用VIP+LVS做前端的秒级切换（最少需要2台机器），后端配NGINX再做代理，之后是应用服务器（NGINX和应用可以放到同一台机器，最少两台）和数据库服务器（最少三台，主从备）
99.5% 架构，直接配两台NGINX做proxy，DNS解析到两台机器即可。但是即时你TTL设的很小，因为互联网的特性，实际生效时间根本无法控制。。。

[9hills]

@Jacklee 99.9% = 每年停机8小时，绝大部分业务都是可以接受这个等级的

[hcymk2]

@mhycy
我听说MySQL-Proxy 性能不是很好看。
实际用起来如何呢？

[mhycy]

@hcymk2 具体不太了解...
机房数据我们拿不到, 他们给啥..我们用啥...囧

[popu111]

前面的大神都是大企业级别的解决方案。。。我会说我就搞了个CDN和用CloudXNS设置了备用IP么？