文档章节

《大规模WEB服务开发技术》读书笔记(I)

ayesd
 ayesd
发布于 2014/04/28 20:36
字数 4612
阅读 45
收藏 0

1、认识服务的规模

注册用户,独立用户

请求数

繁忙时流量

服务器台数

貌似应该有很多其他的指标,以前都听说过,但是从来没有认真分析过,已经上线的系统也没有对此进行过统计和分析!

2、大规模服务中的问题有以下几点:

可扩展性、负载均衡的必要性

一般来说,当一台服务器无法承担负载时,都会采用横向扩展(scale out)或者纵向扩展(scale up)。横向扩展就是通过服务器的数量来分担负载,纵向扩展是通过提高硬件的性能来处理负载。而我们知道,硬件的性能和价格不是成比例的,所以通常采用横向扩展技术!采用横向扩展也会带来问题,如请求如何分配——负载均衡,数据如何同步,网络通信延迟等。

保证冗余性

服务器多了后,故障率也会上升。要么构建稳定的系统,要么构建发生故障时能自动切换以继续运行的系统!

低成本运维的重要性

采用自动化工具。

开发人数和开发方法的变化

如何标准化开发?

考虑下应用程序实现方案?

统一编程语言?

统一库函数和框架?

统一代码规范?

使用版本管理工具管理源代码?

需要有人负责全局的推行。

团队如何管理

应对大规模数据量

数据的流向:磁盘->内存->缓存->CPU。各层的速度差异巨大。

减小数据大小?

分散到多台服务器上?

把数据读取次数降到最低?

3、系统增长战略——最小化开端、预见变化的管理和设计

服务规模小的时候,使用简单的方法效果会更好。应该考虑某种程度上的容量规划,以及在设计服务时尽量减少不必要的数据等。

4、技术团队体制

服务开发部:负责开发各种服务的团队,负责日常的应用程序改进。内部按照服务分成团队,每队3~4人。服务开发部也会跟踪自己开发的服务的性能,将主要页面的大致响应时间定量化,然后每天改进。

基础设施部:负责运维服务器和基础设施的团队,负责准备服务器、运维数据中心和负载均衡等。

5、沟通方式

工作指示基本通过口头传达

如果口头效率低下或者希望留下记录,则通过工具的组合来进行交流

博客+wiki(工作内、实施维护操作方法)

IRC

服务器管理工具

6、改变系统的流程

各团队用10分钟开个短会:共享前一天进度和当天计划。

会议中决定任务负责人,会议结束,立即开始任务。

实现过程尽量书写测试用例。

测试之后开始实现,实现完成提交版本管理。

实现完成后,请求团队内其他开发工程师进行代码审查。

审查通过后,合并到产品代码。

7、数据规模

表的大小以GB为单位,执行select col from table,如果不加索引,因为数据量差不多有千万级别,因此,该SQL会卡死!所以哪怕是调试,也需要避免这种sql语句,可能会引起过高的负载。

8、处理难点

无法在内存中处理!需要读磁盘!内存要比磁盘的I/O快10W~100W倍。

磁盘的搜索和物理结构有关,搜索时有机械物理操作,需要数毫秒,但是内存搜索与物理结构无关,只需要数微秒。

因为磁盘搜索的慢,所以操作系统做了一些加速处理:

将连续的数据放在同一处,然后读取的时候并不是逐个字节读取,而是一次读取4KB左右。(可以参考着看Linux相关基础,鸟哥私房菜里面也提到过。)这样就可以将旋转次数降到最低。

传输速度和总线速度的差异(上面说的是搜索!)。内存的传输速度大概比磁盘的快100倍。。。。。(可以使用hdparm工具查看传输速度【Timing cached reads=内存传输速度】【Timing buffered disk reads=磁盘传输速度】)。

9、 可扩展性的要点——CPU负载和I/O负载

在web应用中,接受HTTP请求、查询数据库,再把数据库返回的数据加工变成HTML后发送给客户端,基本上只消耗CPU。相反,数据库服务器需要较多I/O资源。

由此,对于web应用程序服务器来说,负载均衡非常简单,只需要相同的主机做相同的工作就可以实现了,因为不需要分散数据。但是I/O负载的负载均衡就没有那么简单了,因为数据分散之后就会有数据一致性的问题。

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

能在内存中完成多少

在最大限度减少磁盘寻道次数的基础上灵活运用内存

充分利用局部性的分布式

使用能应对数据量增加的算法

例如线性搜索->二叉树搜索

O(n)->O(log n)

有时可以利用数据压缩和搜索等技术

11、处理大规模数据之前的三大前提知识——程序开发的底层基础

操作系统的缓存

以分布式为前提应用RDBMS时必须要做的事

大规模环境中算法和数据结构怎样使用

12、在理解操作系统缓存的基础上编写应用程序——页面缓存

linux上有页面缓存(page cache)、文件缓存(file cache)、缓冲区缓存(buffer cache)机制。

虚拟内存机制:将逻辑的线性地址变换成物理的物理地址。这样就可以使进程无需考虑自己使用的内存位于什么地方,可以认为比如从0x000地址开始,这样处理就更方便。在分配内存时,以适当的大小(4KB)分配好,并传递给进程,而不是一个字节一个字节的访问。这样的内存块就称为“页面”。

页面缓存原理:操作系统能够让已分配的页面一直维持在这一状态。

进程不能访问磁盘,只能访问虚拟内存。

操作系统从磁盘中读取4KB的块,并写入到内存中,然后将该地址变换为虚拟地址后再告诉进程,最后进程再访问内存。而进程读完数据后,虽然不再需要这块内存,但是并不会释放,而是保留下来,这样其他进程访问同一块磁盘时,就可以直接使用留下来的页面,无需再访问磁盘。这就是页面缓存。

页面缓存的效果就是,一直运行的操作系统更快些。

VFS

LINUX以页面为单位缓存磁盘

LRU

内存空闲时就缓存——通过sar确认:sar -r 1(每秒输出一次当前的内存状态),kbcached即用于缓存的容量,%memused被使用的内存,包括缓存。

增加内存降低I/O负载

13、降低I/O负载的策略

以缓存为前提的降低I/O负载的策略

如果物理内存比数据规模还大,考虑全部缓存。

与经济成本的平衡性。

扩展到多台服务器——无法全部缓存的情况

CPU负载分散只需要简单的增加

I/O分散要考虑局部性

14、利用局部性的分布式

局部性的分布式就是根据访问模式进行分散。

Partitioning——考虑局部性的分布式

Partitioning就是将一个数据库分割到多台服务器上。分割方法很多:

最简单的就是“以表为单位进行分割”,这种方式需要修改程序。

从数据的中间分割,例如按照ID的起始字母进行Partitioning。问题:当改变分割粒度时,需要将数据合并一次比较麻烦。

根据访问模式分割成“岛”——考虑局部性的分布式

比如一般用户分配到岛1,爬虫等分配到岛2

以页面缓存为基础的运维基本准则

操作系统刚启动时不要将服务器投入生产环境

性能测试要在缓存优化后进行

15、分布式MySQL应用的三大要点

灵活应用操作系统缓存

正确应用索引

以横向扩展为前提设计系统

16、灵活应用操作系统缓存

考虑所有数据的大小,尽量将数据量维持在物理内存量之下。

内存不足时增加内存

考虑表结构设计对数据大小的影响

当记录数上亿之后,即使增加8字节的列,数据量也会增加3GB

规范化虽然可以减少数据量,但是会使查询变得复杂,因此应该在速度和数据量的平衡性前提下,考虑规范化。

17、索引

B树

二叉树和B树:B树可以合理的设置节点大小,比如设置为4KB,则和上面的缓存大小相一致!

B+树

MySQL的索引采用的就是B+树:使得搜索外部设备时能够将寻道次数最小化;搜索复杂度O(n)->O(log n)

MySQL索引的不足

使用所以的有->where、order by、group by条件中指定的列

何时有效->明确的添加的索引;主键、UNIQUE约束。可以通过show index确认

MySQL索引的陷阱->想同时使用多个列上的索引,就必须使用复合索引

确认索引是否有效的方法——explain命令

type和rows:type为ALL,rows很大则索引无效,type为ref,rows比较小则索引有效

Extra列也十分重要,如果出现Using filesort或Using temporary的查询不能说是好查询

18、MySQL的的分布式

MySQL的replication功能,即常见的主从和读写分离

应用程序服务器通过负载均衡去查询slave,这样就可以把查询分散到多台服务器上了。

master/slave的特征——对参照系进行扩展,更新类不扩展

主从的结构确定了master是无法实现分布式的。

通常的应用程序,读占据了90%以上,因此master不会称为瓶颈。

需要对更新/写入类进行扩展——表分割、key-value存储

当master的表负载过高,则需要对表进行分割。通过分割来分散写入操作,如果可以分割表文件,就可以将其分散在同一台机器的多块硬盘或者分散到多台服务器上。

或者考虑不使用RDBMS,而使用key-value,如通常的点赞。

19、MySQL的横向扩展策略

数据能放入内存吗?

->yes:放入内存

->no:增加内存,无法增加内存,则用Partitioning

分割之后,将无法使用join

以Partitioning为前提的设计

如若数据库表之前耦合性非常大,则设计时不要将其分割到不同的服务器上。

避免join——利用where in

Partitioning的好处

降低负载

增加局部性

提高缓存的效果

缺点

运维变得复杂

故障率上升

实现冗余需要几台服务器

答:4台。1master+3slave。如果是1+2,假设slave坏掉,则在恢复数据的时候就必须停掉剩下那台slave!

20、特殊用途索引——处理大规模数据

超过RDBMS的处理能力时,利用批处理操作从RDBMS中提取出数据,建立索引服务器之类的东西,再让Web应用程序通过RPC等访问索引服务器。

特殊用途索引——使用调优后的数据结构

关键字链接的处理

使用巨大的正则表达式,虽然比数据库快,但是仍然非常慢

Trie+Common Prefix Search

21、理论联系实践

探寻必须的技术条件

RDBMS中不使用JOIN,这应该是“最差实践”,教科书是绝对不会说不使用JION的,但这是从实践中得来的经验!

相反,使用一些教科书上的理论解决一些相应的问题,却是十分正确的!

从计算机的角度去思考


后续是有关压缩、算法和搜索的话题

22、以紧凑、简洁的方式保存整数数据

压缩大规模数据可以降低磁盘I/O。

23、可变字节码和速度的感觉

可变字节码——整数的编码方式

对例子进行编码实现

24、算法的实用化

算法和算法的评测

数据规模和复杂化的差异

如果数据很小,则算法的复杂度也区分不出来,但随着数据规模变大,算法选择的差异性就越来越大!

算法的评测->复杂度

时间复杂度(执行时间、操作步骤数)、空间复杂度(内存使用量)

复杂度和常数项——评测很重要

常数项:算法实现中不依赖与输入大小,但却不得不执行的一类处理。

就算实现不复杂,CPU缓存是否容易生效、分支预测是否发生等计算机结构特点也会有影响,因此常数项可能会导致差距。

如同样是O(log n)复杂度的排序算法中,快速排序是最快的,因为它使得CPU缓存容易生效。

25、关键字链接

26、文章分类

27、全文搜索技术的应用范围

28、搜索系统的架构

29、搜索引擎的内部结构

30、创建全文搜索

31、企业软件vs.Web服务

应用范围上的差异

流量、增长度、可靠性、事务两者间差异较大。

Web服务的基础设施

低成本、高效率:不应当追求100%的可靠性

重视可扩展性、响应性方面的设计

Web服务的服务规格经常会发生变化

32、云vs.自行构建基础设施

云计算特点就是价格便宜,可扩展性优秀。缺点:内存有上限和低速I/O,模糊不清的负载均衡器,时常停机

自行构建基础设施:硬件配置可以灵活调整;能够灵活应对服务的要求;可以控制瓶颈。

33、层和扩展性

一台服务器能处理的流量极限

各层的可扩展性

web服务器可扩展比较容易,增加服务器即可

数据库服务器和文件服务器的扩展性相比较而言没有那么容易。

read和write相比较,read的分布式也比较容易实现。

最难的要数write的分布式

34、掌握负载进行调优

可视化的管理界面,服务器管理工具。

测量负载的指标——平均负载、内存和CPU相关信息

经验来说,平均负载的值不超过CPU的核数就没有问题。

根据用途进行调优

面向用户

面向爬虫

35、保证冗余性

应用程序服务器一般采用负载均衡实现失败转移和失败恢复,让故障服务器自动下线,故障恢复之后再上线。

数据库服务器可以采用muti-master的方式。

存储服务器采用分布式文件系统。

36、系统稳定化

留出一定余量!

系统的不稳定性

功能增加+内存泄漏:功能达不到理想的性能,导致整体负载上升,服务停止,使用的编程语言,也很难消除内存泄漏。

地雷:比如一篇文章有一万多个评论,如果没有考虑到这种情况,极有可能将评论数全部读取出来进行展示,会导致服务器性能下降甚至停机。

用户的访问模式:如链接被贴到著名网站,被大量用户访问导致系统停机。通常可以采用缓存服务器。

数据量增加

外部关联程序的增加

内存、硬盘故障

网卡故障

37、系统稳定对策

维持适当余量,可以将70%作为分界线

消灭不稳定因素:降低SQL负载、减少内存泄漏、发生异常时的自律控制等

发生异常时的自律控制如自动DoS判断;自动重启服务器;自动终止耗时查询。

38、提高硬件资源使用率

引入虚拟化技术

通过服务器管理工具在运营上发挥虚拟化的优势

虚拟化的额外开销

CPU大约2%~3%

内存性能10%

网络性能50%

I/O性能降低5%左右

39、网络的分界点

超过1Gbps(从路由来看应该是30万pps)->PC路由器的极限

对策:采用多个PC路由;购买成品路由器

超越500台主机->一个子网的极限

子网、ARP表的极限

网络架构的层次化

1、最小的为访问层

2、上面的是分发层

3、最上方为核心层或OSPF层

全球化->一个数据中心的极限

对策:采用CDN

40、应对大规模服务须知

作业队列系统——TheSchwartz等

存储的选择——RDBMS、key-value等

缓存系统——Squid等

计算集群——Hadoop等



© 著作权归作者所有

ayesd
粉丝 7
博文 19
码字总数 30025
作品 0
深圳
高级程序员
私信 提问
我的 2017 年度盘点

一、Core Topics Learning based on full English. Operating System Kernel & Dynamic tracking & Go Programming Language. Lincoln Foundation & Absolutism Research. 二、年度成果 2.1 ......

RiboseYim
2017/12/30
0
0
《数据之巅》读书笔记

《数据之巅》读书笔记 笑遍世界2017-05-1311 阅读 大数据读书笔记 2016年初读的徐子沛的一本书《数据之巅》,把读书笔记记录一下。 美国国会实行参众两院制,众议院的席位按人口比例在各州之...

笑遍世界
2017/05/13
0
0
读书笔记

《编译的一点体会》和《关于库的深入思考》,《编译优化指南》 Embedded Application Binary Interface(EABI) HTML 5 就是 Web Application 如果说上次的“HTML 5来敲门”技术沙龙被“洗脑”...

长平狐
2013/06/03
59
0
读书笔记| 设计数据密集型应用

date: 2019-02-19 10:02:44 title: 读书笔记| 设计数据密集型应用 想法 好书, 已入手英文版准备开刷 如果你需要一份数据相关内容/技术的 , 这本书绝对可以排在明显靠前的位置, 如果再考虑到时...

daydaygo
02/19
0
0
《Linux内核设计与实现》读书笔记 - 目录 (完结)

《Linux内核设计与实现》读书笔记 - 目录 (完结) 读完这本书回过头才发现, 第一篇笔记居然是 2012年8月发的, 将近一年半的时间才看完这本书(汗!!!). 为了方便以后查看, 做个《Linux内核设计...

你的猫大哥
2018/01/14
0
0

没有更多内容

加载失败,请刷新页面

加载更多

TVS瞬态抑制二极管的三大特点

  TVS管瞬态抑制二极管有以下三大特点。   1、将 TVS 瞬态抑制二极管加在信号及电源线上,能防止微处理器或单片机因瞬间的脉冲,如静电放电效应、交流电源之浪涌及开关电源的噪音所导致的...

仙溪
20分钟前
2
0
6 个 K8s 日志系统建设中的典型问题,你遇到过几个?

导读:随着 K8s 不断更新迭代,使用 K8s 日志系统建设的开发者,逐渐遇到了各种复杂的问题和挑战。本篇文章中,作者结合自己多年经验,分析 K8s 日志系统建设难点,期待为读者提供有益参考。...

Mr_zebra
20分钟前
4
0
准则2.1-性能、运行Wi-Fi在iPad上一个或多个错误问题

很多开发者上架遇到这个问题,苹果那边打不开APP,加载不出来内容! 很多人以为是没有兼容ipad,其实是苹果审核都用ipad,跟有没有支持兼容没有关系。 如果自己在国内测试加载正常,要看APP...

qtb999
20分钟前
4
0
华为云学院带你7天入门Redis(2)

华为云学院带你7天入门Redis(2) 1、深度剖析memory Info是Redis提供的一个非常有用的查看状态信息的命令。使用 redis-cli 连上 Redis,输入 info all 命令,redis-server 就 会返回 Redis ...

华为云学院
28分钟前
5
0
Android 自定义View中,四个参数的构造函数的含义

MyView(Context context) Used when instanciating Views programmatically. MyView(Context context, AttributeSet attrs) Used by the LayoutInflater to apply xml attributes. If one of......

SuShine
30分钟前
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部