大规模web服务开发技术 读书笔记之一 - viewcode的专栏 - 博客频道 - CSDN.NET



大规模web服务开发技术 读书笔记之一 - viewcode的专栏 - 博客频道 - CSDN.NET

1. 本书讲解的内容

一开始本书就给出了讲述的内容
1. 什么是大规模web服务开发?
2. 面对大规模数据问题时,处理的基本思路和重点在那里?
例如cache缓存机制,大规模数据情况下数据库的运用方法。
3. 算法与数据结构的选择
4. 规模超出RDBMS处理能力时,如何处理?

上面的内容贯穿整本书,怎么强调都不为过。

2. web 服务的规模

多大才算大规模?
1. 百万级用户注册,millions, 独立用户(unique user)访问数达千万级别
2. 数十亿级请求/月,billions
3. 繁忙时流量,百兆级bps
4. 百台硬件服务器 (这个参数随着硬件的进化,指标会不同)

规模的级别分类
Google, Facebook, Yahoo, Youtube等都是超大规模,服务器达上百万台

小规模服务与大规模服务的区别,规模增大后,可能会发生哪些问题?
1. 保证可扩展性、负载均衡的必要性
横向扩展:低成本
纵向扩展

横向扩展会产生的问题?

a. 低成本下,用户请求如何分配?
负载均衡器 -------  应用服务器(用户请求处理)

b. 数据库如何同步?
数据同步  -------- 数据库服务器

c. 网络延迟如何处理?

2. 保证冗余性
3. 低成本运维
4. 标准化开发

web服务的数据在计算机中的流有哪些? 哪些是瓶颈?
磁盘 -->  内存  -->  缓存   -->  CPU

各层的速度差异有多少?

3. web服务的困难在哪里?

1. 数据量增加 (检索、存储费时)
2. 写入、读出的次数增加

用户增加,当一台服务器无法满足用户处理请求时,解决的思路有哪些?
开源的负载均衡器,
现在基础的web http服务器已经有了良好的负载均衡能力, 如nginx

http://zyan.cc/post/306/
http://blog.csdn.net/zmj_88888888/article/details/8823474

集群服务器利用zookeeper来实现路由与负载均衡。
各种集群监视软件等

如何设计web服务?
最小化开端,但也考虑预见性设计和管理。(本书的内容)

4. 面对大规模数据,初次的问题有哪些?

1. 数据库中表的大小急剧增加,如达到数十、百GB,记录条数有数十亿条billion
2. 查询所有数据时,内存容量不够
3. 线性遍历查询,时间太长

5. 内存与磁盘的硬件特性,造成处理数据时,哪些因素需要重点考虑?

数据量很大,当内存无法容纳时,会有严重的瓶颈,这是因为:
磁盘的读取速度太慢了,内存与磁盘的速度差异达10^6倍,million级别。 磁盘IO成为数据处理的瓶颈。
磁盘慢的原因是:
机械的方式扫描数据。

总线的传输速度差异:
内存 -- > CPU: 7.5GB/s,  现在不止了:频率 * 通道数 * 字节宽度数
磁盘 -- > 内存 : 58 MB/s

也是需要考虑的因素。


即使采用固态硬盘,总线的速度差异也是存在的。


如何查看、测量服务器的平均负载?
top、uptime命令

如何查找cpu、io的瓶颈?
sar  :  cpu使用率



vmstat: io等待率

程序访问I/O请求过多,或页面交互太频繁 导致频繁访问磁盘。

解决思路:
1. 能否增加内存以保证缓存区域的方法继续有效
2. 数据量是否本书就过多
3. 有无必要修改程序的I/O算法

6. 可扩展性与哪些因素有关?与哪些因素无关?

1. 考虑到成本与灵活性,横向扩展更有性价比。
2. 如何保证CPU负载的可扩展行?
    增加web程序服务器。这是因为web程序服务器的工作都在于接受http请求,查询数据库,数据加工成HTML或json返回给客户端,基本只消耗CPU.
    而数据库服务器,基本需要较多的IO资源。

CPU负载扩展:
增加相同结构的应用服务器,负载均衡来分散请求。
3.  三层结构:
代理服务器   ---   应用服务器   ---   数据库服务器
负载均衡,可以由代理服务器来完成。"反向代理负载均衡"。

运算类,逻辑处理,由应用服务器来完成。CPU消耗大。

数据读写类,由数据库服务器来完成。IO消耗大。
IO类扩展:
借助数据库的扩展和大规模数据处理方式。具体方式:
优化数据库的写法。
优化数据处理算法。


7. 处理大规模数据的重点有哪些?

1. 能在内存完成多少数据的处理?
尽量减少磁盘数据读写次数,尽量在内存中完成数据处理。
将磁盘寻道次数降到最低。

分布式处理(分块处理)。

2. 算法的优化,降低时间或空间复杂度


3. 数据压缩与搜索技术的帮助

================缓存的背景知识============
处理大规模数据的基础知识有哪些?
1. 操作系统缓存
2. 以分布式为前提的RDBMS应用
3. 算法和数据结构

8. 操作系统的缓存机制(为什么缓存是一种高效的数据处理方式?)

目标与资源
1. 数据存放在磁盘上,如何实现数据的高速访问?
内存是磁盘访问速度的10^5到10^6倍。   
2. 解决方案: 尽量使用内存。

内存的工作原理: 缓存机制。

虚拟内存  -->  地址变换  -->  实际内存

缓存基本单位: 页面,4KB数据

虚拟文件系统 --> (页面缓存机制)  -->  虚拟内存

如何快速确定文件是否已经在内存中?
文件在虚拟内存中的地址: 文件inode和偏移量 作为散列键值。

内存的使用方式:
linux会把全部空闲内存用于缓存。
sar -r可以查看内存状态

数据是如何由磁盘读入内存的?
页面缓存机制:其优点,面对的问题

9. 由缓存到IO负载,缓存与IO负载有哪些关系

降低IO负载的策略:
在缓存基础上降低IO负载。

是否增加内存,需要考虑的因素:
1. 如果物理内存比数据还大,那就考虑全部缓存。
2. 内存大小与成本的平衡。

当内存无法全部缓存时,该如何处理?
可以考虑增加数据库服务器,对数据库而言,更重要的是IO负载,增加缓存容量,提高效率。
(CPU负载分担,只需要简单增加服务器即可)

对于IO负载,增加服务器需要考虑本地局部性

单纯的增加缓存,一般还是不能应对快速增长的数据量。缓存仍然会成为瓶颈。

当数据库服务器重启后,缓存会被清空,这时有大量请求,会发生哪些现象?
对IO密集型服务器,无缓存,会有严重IO瓶颈,系统频繁访问磁盘。
解决方法:将数据库缓存读取完成后,再放回生产环境。

10. 基于本地局部性Locality的分布式

这个概念是什么意思?
对于一个固定的访问,可以使用一个固定的服务器来处理,而将多个固定的访问分割,放在不同的服务器上处理。
通过增加数据库服务器的方式,来增加缓存,并采用一些策略,来提高缓存的利用效率。

分割的方式:
1. 按表访问分割
2. 按数据id分割,即按索引分割
这种方式缺点:当分割粒度发生变化时,可能需要数据合并。

3. 按访问模式分割,如根据http请求的useragent和url等进行分割
这样很容易区分"热门"和"冷门"请求。
如爬虫访问和用户访问之间的区别,可以降低爬虫的请求处理的体验,提高用户请求的体验。
用户请求可以单独处理,其缓存可以在一个服务器上,可以提高服务器效率。


=============数据库相关的背景知识===========

11. 索引在数据库中有哪些作用?在分布式数据库中又有哪些作用?

MySQLl是一种RDBMS, 增加索引后,数据库查询能迅速返回数据。这是数据库自身数据结构和算法的能力。

而分布式MySQL的应用的要点:
1. 缓存的灵活运用:是否增加内存,是否增加服务器来增加和分类缓存
2. 正确设置索引
3. 若横向扩展,该如何设计?

与缓存相关的因素:
1. 是否增加内存,是否增加服务器来增加和分类缓存

2. 大规模数据下,表结构的设计对内存的使用有哪些影响?
     3亿条记录,若增加一个8字节的列,数据量就会增加 3亿 * 8B = 3GB。
若表的深度特别深,就需要考虑改变表的结构。


3. 数据规范化,将一个表拆成多个表,优缺点有哪些?
优点:规范化后能降低数据占据内存的大小。
缺点:联合查询时,会降低查询速度。

在二者之间,寻找一个平衡点。将必要字段和非必要字段分离。
******************
索引的原理:B+树
B+树是一个多叉平衡树。  其效果包括两方面:
多叉: 利于将某一个节点的数据控制在4KB左右,利于磁盘读取和存储。 将寻道次数降到最低。
平衡树:利于快速查询。搜索复杂度为 O(Log(N))

哪些列适合建立索引?
WHERE, ORDER BY, GROUP BY 条件中指定的列。

MYSQL中,哪些索引有效?
1. 明确指定的索引
2. 主键,UNIQUE约束

以前mysql 查询每次只能使用一个索引,不知道现在是否有改善。

在查询语句前加上 explain命令就能 确定 sql的索引 是否有效。



12. 当使用分布式mysql时,如何设计系统?

如何现实mysql分布式系统?
mysql有一个replication复制特性,这是实现其分布式的基础。
1. 准备多台服务器
2. 其中一台作为master,其他作为slave
3. 以轮询的方式,从master服务器向slave服务器同步数据(更新数据)
4. 通过slave服务器进行查询(通过负载均衡可以方便的将查询分配到不同的slave服务器中去) select
5. 通过master服务器进行数据提交、更新
6. 回到3, 循环处理

一般数据操作select与insert的比例为10:1. 所以,以上系统结构,slave服务器可以轻易的扩张,而master服务器却不能。

如何实现写入频繁的、可扩展的数据库服务器?
1. 表分割,减小单个表的大小
2. key-value存储方式,nosql数据库,来替换RDBMS,这种数据库擅长写入与读出操作,不需要复杂的关系操作和统计排序等处理。所以,开销少、速度快。

13. mysql 如何进行横向扩展?

总结:
1. 放进内存
2. 增加内存
3. partitioning

partitioning策略的限制:
当两个表,如entry与tag表,放在不同的服务器上,就无法对这两个表执行join操作。mysql不支持跨服务器join操作。

如何实现跨服务器、多表联合查询?
解决方法:
1. 若实时性要求不高,根据业务需求,建立中间表,定期向中间表更新数据。查询更新表,这样速度会很快。
2. 若实时性要求较高,待调研。

还可以不使用JOIN操作,而是开发专用算法,进行数据查询。
或者使用专用的sql语句,如where... in ... 替代 join。

partitioning也是有代价的:
运维变复杂、故障率上升
partitioning是最后的处理手段。

对于横向扩展的系统,实现冗余备份,至少需要几台服务器?
4台。 1台master + 2台正常工作的slave + 1台备份

Read full article from 大规模web服务开发技术 读书笔记之一 - viewcode的专栏 - 博客频道 - CSDN.NET


No comments:

Post a Comment

Labels

Algorithm (219) Lucene (130) LeetCode (97) Database (36) Data Structure (33) text mining (28) Solr (27) java (27) Mathematical Algorithm (26) Difficult Algorithm (25) Logic Thinking (23) Puzzles (23) Bit Algorithms (22) Math (21) List (20) Dynamic Programming (19) Linux (19) Tree (18) Machine Learning (15) EPI (11) Queue (11) Smart Algorithm (11) Operating System (9) Java Basic (8) Recursive Algorithm (8) Stack (8) Eclipse (7) Scala (7) Tika (7) J2EE (6) Monitoring (6) Trie (6) Concurrency (5) Geometry Algorithm (5) Greedy Algorithm (5) Mahout (5) MySQL (5) xpost (5) C (4) Interview (4) Vi (4) regular expression (4) to-do (4) C++ (3) Chrome (3) Divide and Conquer (3) Graph Algorithm (3) Permutation (3) Powershell (3) Random (3) Segment Tree (3) UIMA (3) Union-Find (3) Video (3) Virtualization (3) Windows (3) XML (3) Advanced Data Structure (2) Android (2) Bash (2) Classic Algorithm (2) Debugging (2) Design Pattern (2) Google (2) Hadoop (2) Java Collections (2) Markov Chains (2) Probabilities (2) Shell (2) Site (2) Web Development (2) Workplace (2) angularjs (2) .Net (1) Amazon Interview (1) Android Studio (1) Array (1) Boilerpipe (1) Book Notes (1) ChromeOS (1) Chromebook (1) Codility (1) Desgin (1) Design (1) Divide and Conqure (1) GAE (1) Google Interview (1) Great Stuff (1) Hash (1) High Tech Companies (1) Improving (1) LifeTips (1) Maven (1) Network (1) Performance (1) Programming (1) Resources (1) Sampling (1) Sed (1) Smart Thinking (1) Sort (1) Spark (1) Stanford NLP (1) System Design (1) Trove (1) VIP (1) tools (1)

Popular Posts