- 负载均衡
当用户请求到达时-----httpd服务请求-----动态的通过fastcgi转发到后端指定主机
存储可以通过文件或者数据库系统，基于mysql送达给后端的服务器
10000（C10K问题）个请求中只有20%是动态的请求，其中又有20%需要连接数据库的，所以更多的负载发生在httpd
对于httpd一方面要响应请求，另一方面要承载反向代理，容易成为性能瓶颈，2000个请求需要application server负载，而application server承载能力1000个左右
数据请求----在执行复杂查询的时候能100个并发就不错了
所以解决途径-----向上扩展scale up：狂买机器 然而性价比不高，钱花的翻倍，性能提升有限
向外扩展---加更多的主机，把请求分散到更多主机（问题：调度操作谁来实现，比如httpd的调度模块把需求分散到后端，http是stateless协议，势必要跟踪用户访问的足迹，胖cookie导致诸多用户敏感信息在浏览器上，例如购物车等数据会放在服务器的内存空间中----session，浏览器二次访问中会把cookie发送给session，从而唤醒历史访问信息，那么问题来了，购物车信息可能第一次分发到机器1，第二次分发到机器2，卧槽~悲剧了）
上述问题mysql也会遇到
所以有了主从复制，数据存储都找到一台主机，其他数据库服务器作为从服务器存在，复制一份，那么负责分发任务的服务器不仅要负责任务分发还要顾及负载均衡
而且解耦也变得困难
这就是中间件的价值所在！！解析请求并决定分发给哪个数据库服务器：是主写，还是负载均衡的选择一台数据库进行读操作
NFS（Network File System）即网络文件系统，是FreeBSD支持的文件系统中的一种，它允许网络中的计算机之间通过TCP/IP网络共享资源。在NFS的应用中，本地NFS的客户端应用可以透明地读写位于远端NFS服务器上的文件，就像访问本地文件一样。
- httpd向外扩展
问题：静态文件无疑要复制一份到n份，更新站点时，后端内容会经常改，新程序会有bug；
不同用户调到不同服务器上，session的复制无疑是个大问题----这tm内存数据怎么迁移啊（用redis呗，用memocache的就该哭了）
如何做httpd的负载均衡？一个域名下有两个 做轮询，带来的问题是，两个不同的dns服务商A，B如果A宕机了，那么A的用户通过域名B访问，会丢失之前的访问记录（诸如session），从而带来糟糕的使用体验
所以加一个负载均衡器，作为一个调度器，监听80端口，转发给httpd 修改目标地址dnet
web请求中get请求报文很小或者没有，所以容易调度，那就不让响应报文通过调度器！！！实现更高负载均衡效果，以nginx为例，响应3-5万属于很高级别的并发量----nginx反向代理
由此看来负载均衡器成了唯一入口，一旦发生问题就麻烦了，这就需要提供备份负载均衡服务器（冗余备份），把此前主机的服务和调度转到冗余机器上，如何获得运行主机的状态？并能成功通知冗余备份？
首先实现ip抢夺，但带来的问题是，反复抢夺会造成
所以考虑集群的扩展方案：同类功能绑定在一起的谓之集群
所谓可用性availability=无故障时间/(无故障时间+修复所用时间)，看来所谓高可用就是设法添加并优化冗余----高可用集群
并行处理集群-----通过日志分析客户的访问行为（可能达数十G），如何分析？总结 -----分布式！例如淘宝的日志存储分散到1000台服务器（分布式存储，不光要负载均衡还要存储），搞一个存储集群，在一个框架下以便于收集和整理，有一个负载均衡机制
可能光读数据，几天就过去了，所以处理依然要搞分布式，分散切割处理并合并处理结果的解决机制谓之MapReduce机制-----大规模并行处理平台，例如Hadoop
上述机制属于batch处理，还是属于延时的范畴，但对于要求针对请求做实时处理 例如 storm流式处理平台，做现时分析
在大规模处理平台出现前，使用高性能集群（集中式的功能模式）与分布式相对
- LB
httpserver：不产生写操作
mysqlserver：产生写操作
不读写分离就加中间件；如果采用分布式读，那么假如结果超过10万行，并做排序，就坏事了；如此一来，就需要专门的团队要研发架构解决面临的问题；
实际上各互联网大佬，为了顾及面子和解决自己面临的独到问题，都会选择开发属于自己的架构
- 评价性能的指标
可扩展性
可用性
容量
性能
添加主机在早期是线性扩展的可以提升负载均衡和并发性能，然而到达一定程度就出现拐点，这时各主机之间的内耗就会出现等待解决。
稳定性 标准化（版本，配置，路径标准）自动化是前提
高性能集群计算是军备级别的技术，可以用来破解密码，民用方面可以用来做天气预报
- 高扩展性能集群构建原则
系统内尽量避免串行和交互；
有观点认为：用两台dns服务器（一台生产机（两条AG路lb性能不太好），一台灾备）既做高可用又做负载均衡，不过这也是权宜之计；流行的做法是，做两套，也有可能多套架构。亦或是划片响应。一旦其中一套遇到问题，就做切换。在前端做(全局负载均衡调度器)GSLB,SLB(service load balancing)
如果缓存服务器未被命中，有两套解决方案：
到其他缓存服务器上找（cdp内容分发协议cache delivery protocol缓存之间共享协议）
剩下的10%-20%逃逸到本地服务器，才来到负载均衡器，web页面中也是动静分离的，分发到相应的动、静服务器，通过反向代理实现。
动态内容，其实一小部分也是可以静态缓存的，取决于缓存策略（例如新闻站点）
对于mysql服务器索引，查数据，取数据.....也可以缓存数据
为什静态内容需要缓存?
涉及到缓存的存储机制，网站页面一般存在文件系统上
解析路径，把文件（数据）从磁盘取到内存，因为缓存是k-v存储，同样，在10万条键值对找一个文件比在10万个文件系统中找一个文件速度不是快一星半点！！！
当然缓存这种k-v类型数据，也有可能从磁盘取出来，key可能是url映射的结果k-v的查找速度是O(1)的，根本不care是从几万还是几十万的结果集中去找.
所以粗暴的做法就是------缓存为王，加内存。但是遇到后台数据改变，缓存反而会降低性能
结构化（数据库数据） 非结构化数据 （网站图片，三台主机要不要看到同样的图片，专门的上传程序）半结构化数据
聚合门户，同一网页上的两个不同链接可能来自两个不同的主机！！！
性能
等待3秒才能打开可能流失20%用户，10秒可能流失100%，优化程序和逻辑也是提升性能的关键！！！
总结：
构建高性能集群
分层：静态层 动态层 数据存储层（结构，非结构化）负载均衡层
分割：不同应用分发到不同服务器组
分布：分不了层的做分布式应用，分布式静态资源，分布式数据和存储，负载均衡机制，如果有数据集，要对数据集进行分片（sharing）
分布式计算：如果资源有变化做分布式计算！！！
性能是响应时间
容量：一段时间内完成的工作量；性能保证的前提下，系统单位时间内的吞吐量