《高性能网站构建实战》笔记
Linux集群简介：
1、高可用集群：Turbolinux,TurboHA
2、负载均衡集群：Linux Virtual Server,TurboLinux Cluster Server。
3、超级计算机集群：任务片式，并行计算方式
硬件负载
作为启动器，设备形式多样。
将负载均衡功能置于交换设备中，置于服务器与internet间，如Alteon,ArrowPoint
运用两块网络适配器将这一功能集成到计算机中，其中一块连接到前端止于web服务器的交换机上，另一块通过路由器或其它设备连接到internet上。如Coyote Point,F5 Networks以及HydraWeb。
软件负载均衡
DNS轮询：最早的负载均衡是通过DNS轮询实现的,在DNS配置多个A记录。
代理服务器
LVS+Keepalive环境
前端负载均衡机：direct server(DR)、后端实际服务器:real server(RS)、IP虚拟服务软件IPVS（IP Virtual Server）
IPVS软件实现了3种IP负载均衡技术，大致原理：
NAT(VS/NAT) 网络地址转换（network address translation）
通过网络地址转换，调度器重写请求报文的目标地址，根据预设调度算法，将请求分发到后端真实服务器
IP Tunneling(VS/TUN)
调度器把请求报文通过IP隧道发送给真实服务器，而真实服务器将响应直接返回给客户
Direct Routing(VS/DR)
通过改写用户请求报文中的MAC地址，将请求发给真实服务器，再由真实服务器将响应直接返回给客户
LVS几种常用算法：
轮询、加权轮询、最少连接、加权最少连接、基于局部性的最少连接、带复制的基于局部性的最少连接、目标地址散列等
Keepalive是我们平时说的第三层、四层、五层交换。检测服务器故障，如果有死机或工作故障，keepalive会检测到并将其从系统中剔除。当服务器正常后，keepalive再将服务器加入到服务器群中。主要用于real server健康检测以及loadbalance主机和Backup主机之间的failover实现。
LVS/DR模式网络拓补
VRRP块
实例状态state
Lvs Cluter多台LVS服务器安装方案
http://my.oschina.net/lxcong/blog/143904
服务器架构：
负载均衡服务器：2台（LVS+Keepalive）
WEB服务器（Nginx+PHP）：4台
数据库服务器（MySql一主两从）：3台
HAProxy高性能负载均衡器
Nginx服务器作负载均衡
页面缓存：内存缓存、文件缓存
Squid：普通代理、透明代理（使用iptables实现）、反向代理
Sarg日志分析工具
Varnish:目前还不能加速https。基于内存的缓存，比基于文件（硬盘）的效率高
Nginx:轻量级。需要加载第三方模块（nginx_cache_purge用于清除指定缓存）
WEB服务器
Apache，最新稳定版2.4.17
--enable-so指明编译动态加载模块（DSO）；
--enable-mods-shared=<MODULE-LIST>指定DSO编译的模块，all指有，more大多数，也可罗列模块名以空格分开。
--with-mpm=<MPM>。MPM有：worker,prefork,mpm_os2,beos,event。
Prefork是unix机上默认。没有线程，只有主线程根据需要开辟子线程。系统稳定性高。
Worker是支持多线程多进程混合模型的MPM，可以处理海量请求，但系统开销小于prefork，因此建议使用worker。
1、 日志切割apache自带的rotatelogs小工具。
2、 GZIP模块。Apache两种算法mod_gzip（压缩比高）和mod_deflate（压缩速度快）。Mime类型根据实际情况添加，至于PDF,JPEG本身就是高压缩的，重复压缩意义不大，还会造成服务器负担。
3、 简单防DDOS攻击：Mod_dosevasive。
4、 多线程下载抵御：Mod_limitipconn模块。设置客户端IP最大连接数。
Nginx:关闭空主机头
NOSQL
NoSQL特点：
1、 数据高并发读写。传统关系型支撑10000并发读还行，如果是写，磁盘I/O无法承受。普通的BBS站都面临着高并发写请求。
2、 海量数据的存储。如一个SNS站一个月用户动态信息达到2.5亿条。大型WEB网站的登陆系统，例如腾讯、盛大数以亿计的账号，关系数据库难以应付。
3、 高可扩展和高可用。
Memcached
复制功能：repcached用以实现一主一从,且主从都可复制。
监控工具：自身的stats命令查看。也可用memcache-top小工具和Memcache.php
Redis
4种数据类型：string字符串、list双向链表（push,pop）,set(多集合求交并差),zset。
监控工具：自身的stats命令查看。也可用memcache-top小工具和Memcache.php
分布式文件存储数据库
MongoDB适用场景
主从配置：master,slave
MongoDB管理工具:Mongostat,profile(类似于mysql的showlog)，自带的web控制台
分布式文件系统
如果是创业公司, 建议使用云服务, 阿里云OSS 或者 七牛 比较不错, 尽量把时间和精力花在业务上。但如果觉得一定要花些时间去做自己的分布式文件系统, 而且是偏向于存储小型文件的话, 下面是我了解到的:
Swift openstack 子产品. 此产品以 amazon s3 为假想竞争对手做的
GridFS mongo 社区的
Gluster 背后是 redhat 公司
TFS 淘宝自己开源的
Mogilefs memcached 那公司弄的(?)
HDFS:Hadoop简化的GFS
GFS：GOOGLE弄的
单处理器单用户的本地文件系统（如DOS文件系统）；
多处理器单用户的本地文件系统（如OS/2文件系统）；
多处理器多用户的本地文件系统，如UNIX本地文件系统；
多处理器多用户的分布式文件系统，如Lustre文件系统
本地文件系统，处理器通过系统总线直接访问物理存储资源。
分布式文件系统，文件管理系统管理的物理资源不一定在本地节点，而是通过网络连接。
采用哪种方案，需要运维人员进行选型。备选方案如下：
1、GOOGLE文件系统GFS:
GFSClient： 应用程序的访问接口
Master（主控服务器）：管理节点，在逻辑上只有一个（还有一台“影子服务器“，在主控服务器失效时提供元数据，但并不是完整的热备服务器），保存系统的元数据，负责整个文件系统的管理。
Chunk Server（数据库服务器）：负责具体的存储工作，数据以文件的形式存储在Chunk Server上；相应GFS客户端的读写请求。
好处：管理相对简单
坏处：很多服务请求都经过主控服务器，容易成为整个系统的瓶颈；可能存在单点失效问题。
2、HDFS
是Hadoop中的大规模分布式文件系统，在整个架构上与GFS大致相同，更简化，比如同一时刻只允许一个客户端对文件进行追加写操作。
它具有以下几个特点：
1）适合存储非常大的文件
2）适合流式数据读取，即适合“只写一次，读多次”的数据处理模式
3）适合部署在廉价的机器上
但HDFS不适合以下场景（任何东西都要分两面看，只有适合自己业务的技术才是真正的好技术）：
1）不适合存储大量的小文件，因为受Namenode内存大小限制
2）不适合实时数据读取，高吞吐量和实时性是相悖的，HDFS选择前者
3）不适合需要经常修改数据的场景
整体架构
由NameNode，DataNode，Secondary NameNode以及客户端组成。
监控系统
Cacti概述
Cacti是一套基于PHP,MySQL,SNMP及RRDTool开发的网络流量监测图形分析工具。
Cacti和Nagios的监控体系可以说是使用广泛而且支持丰富的国内外的运维人员都需要掌握的一套监控体系，这套体系的好处在于使用Cacti的强大画图和自定义画图能力，以及Nagios的可控报警
Zabbix企业级分布式监控系统
zabbix（音同 zæbix）是一个基于WEB界面（和Cacti一样也是用PHP）的提供分布式系统监视以及网络监视功能的企业级的开源解决方案
iftop流量监控工具
Nmon性能监视和分析工具
