大规模web服务开发技能

第5课 大规模数据处理的难点 -- 内存和磁盘 node

单台Linux服务器瓶颈分析 linux

一、查看平均负载 web

用top、uptime命令查看平均负载; 算法

一、平均负载很低,系统吞吐量没法提高 --------->检查软件设置是否异常,网络、主机是否存在故障 sql

二、平均负载很高,用sar或vmstat命令查看cpu使用率和I/O等待率 shell

二、确认CPU、I/O是否存在瓶颈; 数据库

>若是是CPU负载太高缓存

一、使用sar或top命令确认是用户程序的瓶颈仍是系统程序的问题; 服务器

二、用ps命令查看可见进程的状态和CPU使用时间,进一步确认问题进程; 网络

三、肯定进程后,使用strace进行跟踪或用oprofile进行剖测;

若是是排除程序失控、磁盘、内存处于理想状态,则须要增长服务器、改善程序逻辑和算法;

>若是是I/O负载太高

多半是程序发出的I/O请求过多致使负载太高或者是发生页面交换致使频繁访问磁盘,使用sar或vmstat确认交换区状态;

若是是发生页面交换引发

1. 用ps确认是否有进程消耗了大量内存

2. 若是是程序问题消耗大量内存的,须要改进程序;

3. 若是是由于内存安装不足,则增长内存,没法增长内存的状况,须要考虑分布式

若是不是发生页面交换引发(多是用于缓存的内存不足):

1.若是增长内存能够扩大缓存,则增长内存;

2.若是增长内存仍是没法解决问题,则考虑分布式或增长缓存服务器;


第6课:可扩展的要点

CPU负载的扩展(较简单)

    一、增长相同结构的服务器,经过负载均衡器来分散;

    二、如:web应用服务器、网络爬虫等;

I/O负载的扩展(较复杂) 

一、借助数据库

二、大规模数据


第7课:处理大规模数据的基础知识

处理大规模数据的三个重点: 
     写程序的技巧:

    *  尽可能在内存中完成,:将磁盘寻道次数降到最低;能够实现分布式,有效利用局部性;

    * 使用能应对数据量增长的算法,例如:线性搜索 -->二叉树搜索,O(n) -->O(logn)

    * 有时能够利用数据压缩和搜索的技术

处理大规模数据以前的三大前提知识:

    * 操做系统的缓存 
    * 以分布式为前提应用RDBMS时必需要作的事情 
    * 大规模环境中的算法和数据结构


第9课:下降I/O负载的策略

以缓存为前提,下降I/O负载的策略:

    * 若是数据规模小于物理内存,则所有缓存; 
    * 若是数据规模大于物理内存,能够考虑数据压缩(使用数据压缩,在从缓存中读取时是否要进行解压,这是否会增长计算负载呢?); 
    * 若是数据规模大于物理内存 ,能够就是扩展到多台服务器。为分散CPU负载,只须要简单增长服务器,为分散I/O负载,须要考虑局部性; 
    * 考虑经济成本的平衡性

linux页面缓存策略:(只要可能linux就会把空闲的内存用做页面缓存使用)

    1. 从磁盘读取数据 
    2. 若是数据在缓存中不存在且有空闲的内存 
    3. 创建新的缓存 
    4. 若是没有空闲内存供缓存使用,则替换旧的缓存 
    5. 进程要求分配内存时,其优先级高于页面缓存;

52design.com_3d_07服务器刚启动时,不要投入生产环境,由于创建缓存须要时间,若是在没有缓存的状况下,大规模的访问形成频繁的读写磁盘,可能会引发宕机;启动后要将常用的数据库文件cat一遍,使其放入缓存中;

png-0023如何cat?


第10课:利用局部性的分布式 
所谓局部性就是Locality,根据访问模式实施分布式;

image 
我理解是按必定的业务规则将访问进行分流,这样单台服务器只要保存对应规则部分的缓存数据便可,png-0023那么应用请求分配由谁来完成呢?是LVS?

经常使用的局部性分布式技术是:Partitioning(分区) 
简单的说就是将一个数据库分割到不一样的机器上,

    * 最简单的分割方法:以表为单位分割,好比表A、B在机器1上,表C、D在机器2上;分割原则是看表的容量和机器缓存容量的匹配上;png-0023这样的分割是否意味着不一样机器的表之间必须是弱关系的,不能有关联的需求?

    * 有一种分割方法是从数据中间进行分割,即对一个表,好比根据ID的起始字母:a-c在机器1,d-f在机器2等;

    * 还有一种特别的分割方法是根据业务用途,将数据分割成“数据岛”;例如Hatena BookMark是根据HTTP请求的User-Agent和URL进行分离的,例如:通常用户分配到岛1,部分API请求分配到岛2,Google bot、Yahoo!等爬虫分配到岛3;

image

    * 使用局部性的分布式,要求应用程序作相应的修改,同时存在的问题是:若是须要改变分割粒度,须要将数据合并一次后再进行分割,比较麻烦;

 


第11课:正确应用索引 ----分布式MySQL应用的大前提

    * 在设计大数据量的表时,尽可能紧凑一些,让记录尽量的小,由于表结构稍微有错误,数据量就会以GB的单位递增;

    * 要注意表设计过程当中对冗余列的处理,若是一个表包含冗余列,会浪费存储空间,若是将冗余列分割到另外一个表,也许会节省空间(不必定,须要评估),但同时也增长了查询的复杂度,所以在时间和空间的取舍上要进行衡量;

    * MySQL中创建索引的数据结构就是B树的变种B+树,B树能够经过调整节点数参数M,使得每一个节点的大小在4KB,从而使得磁盘寻道次数和节点访问次数相同;而二叉树是固定为2个节点,所以不具有这样的调节能力;

    * 从理论上,B(+)树的复杂度为Olog(n),而线性搜索的复杂度为O(n)

 

Mysql索引的规则:

    * where、order by、group by中指定的列会使用索引

    * 什么时候索引有效?明确添加的索引、主键,UNIQUE约束;

    * 想同时应用多个列上的索引,就必须使用复合索引;

    * 确认索引是否有效的命令:explain

 


第12课:MySQL的分布式 -- 以扩展为前提的系统设计

MySQL的Replication:

    * master/slave的架构; 
    * 查询发给slave,更新发给master;经过ORM来控制; 
    * slave前面放负载均衡器,如:LVS 、MySQL Proxy,从而将查询分散到多台服务器上;

image

Master/Slave的特征:

查询能够扩展,只需增长Slave服务器便可,但在增长前添加适当的内存;

Master没法扩展,虽然web应用90%以上是读操做,但若是须要扩展,则须要经过对表进行分割或更换实现方法;

  • 进行表分割:分散写入操做,将数据文件分散到同一机器的不一样磁盘上或不一样的机器上
  • 不使用RDBMS,采用key-value存储结构,如:Tokyo Tyrant、Redis

第13课:MySQL的横向扩展和Partitioning

 以Partitioning为前提的设计

例如表entry和表tag是一对多的关系,若是要取出包含标签“perl”的书签,须要使用JOIN查询,将两个表关联。可是若是entry和tag表放在不一样的机器上,MYSQL就没法实现JOIN(MySQL的FEDERATED表能够实现),只有经过先查找包含“perl”标签的记录,再到entry表中根据eid找对应的entry记录。所以,JOIN查询只能在保证表之后不会被分割到不一样机器上的前提下才能使用。

利用where…in…来避免JOIN

select  url from entry INNER JOIN bookmark on entry.eid = bookmark.eid where bookmark.uid = 169848 limit 5;

=>

select eid from bookmark where uid = 169848 limit 5;

select url from entry where eid in (0,4,5,6,7);


第14课:特殊用途索引----处理大规模数据

问题:当数据规模超过RDBMS的处理能力时怎么办?

方法:利用批处理操做从RDBMS中提取出数据,创建索引服务器之类的,再让WEB应用程序经过RPC等访问索引服务器。

image      image


第30课:云 vs 自行构建基础设施

Amazon EC2 (Amazon Elastic Compute Cloud),是不负责储存的,储存由S3 (Amazon Simple Storage Service)服务负责,因此得有脚本每次重启时从S3恢复数据库

Amazon S3 (Amazon Simple Storage Service)

Google App Engine

Microsoft Windows Azure

 

image


第31课:层和可扩展性

一台服务器的处理能力大概为100万~200万PV(page views)/月左右  4核CPU,8G内存

各层可扩展性:

        应用程序服务器,配置相同,不持有状态,容易扩展

       数据源(数据库服务器、文件服务器):read的分布式容易,write 的分布式难


第33课:保证冗余性

应用程序服务器:

    增长服务器数量

    用负载均衡器实现失败转移和失败恢复

image

数据库服务器:

Multi-master:是今年Mysql服务器构建的主要方法。该架构中,服务一般是两台,组成Active/Standby结构。其中,一台是Active,另外一台是Standby,一般只向Active写数据。一旦Active停机,Standby经过VRRP协议监视到这一状况,即把本身提高为Active,变成新的master。而停机的那台通过人工修复后变成Standby,或恢复为原来的结构。为了从外部判断哪台是Active,须要用到虚拟IP(VIP),即Active服务器除了原有的IP地址,还会被分配一个服务用的虚拟IP地址。应用程序服务器始终访问这个虚拟IP。切断时将这个虚拟IP分配给新的Active。从而实现master的透明切换。

image


第38课:网络的分界点

PC路由器的极限:超过1Gbps(30pps,即每秒30万包数据,按每包300字节算,为1Gbps)

一个子网的极限:500台主机

一个数据中心没法实现全球化

CDS:(Content Delivery Network),基本原理就是在世界各地放置服务器,将媒体文件缓存后,用户就能够从最近的服务器下载了。

如:Amazon CloudFront

相关文章
相关标签/搜索