《大规模web服务开发技术》笔记
2016-02-23 22:08
302 查看
前段时间趁空把《大规模web服务开发技术》这本书看完了,今天用一下午时间重新翻了一遍,把其中的要点记了下来,权当复习和备忘。由于自己对数据压缩、全文检索等还算比较熟,所以笔记内容主要涉及前5章内容,后面的零星记了一些。本文可能对如下人士比较有帮助:1、对这本书有兴趣,但对内容存疑的;2、对大规模Web服务有一定经验的,可对照着查漏补缺。
Hatena的规模(2010年4月)
注册用户150w,UU1900w/月
请求数:几十亿/月
繁忙时流量:850Mbps(不含图像)
硬件(服务器)600台,通过虚拟化技术,主机超过1300台
日志每天几GB级别,数据库GB到TB级别
系统增长的战略
最小化开端、预见变化的管理和设计
平衡效率和质量
开会、规范化、文档、敏捷等
GB级别(千万)的文本数据库,不用索引,一句select查询200s也未能执行完
内存和硬盘的速度差异
寻址:前者是后者的10w到100w倍
传输速度(总线):前者——7.5G/s,后者——58M/s
找寻单机瓶颈(用足单机的性能,不要推测,要测量)
sar或vmstat查看是CPU问题还是IO问题
若是CPU问题
top或sar查看是系统进程还是用户程序
ps查看进程状态和cpu使用情况,确定问题进程
用strace或oprofile找出程序或进程的具体问题所在
若是IO问题
发生频繁页交换--->内存不足
ps查看程序所用内存
能否改善程序,减少内存占用
不行增加硬件或分布式
若无,则可能是缓存的内存不够
增加内存
不行就增加机器,分布式
CPU扩展比较方便,但IO负载的扩展比较困难
查看实际负载:top结果中的load average(1分钟 5分钟 15分钟)
查看是IO负载过高还是CPU负载过高:sar -P(多核)
处理大规模技术的重点
尽量在内存中进行,可实现分布式,利用局部性
算法的复杂度,O(n) --> O(logn)有质的飞跃
数据压缩和检索技术
缓存机制
页面缓存(page cache)
现代操作系统均采用虚拟内存
内核分配过的内存会尽量留下来,下次无需访问磁盘,即页面缓存
操作系统以页为单位缓存,即虚拟内存的最小单位
增加内存可提高缓存的命中率,降低IO负载
sar命令
sar -r 即可查看当前的内存状态(kbbuffered缓存使用的物理内存大小)
sar 1 3 一秒1次,总共3次
sar -u 查看CPU使用率
sar -q 查看平均负载
sar -r 查看内存使用情况
降低IO负载的策略
提高缓存,即加内存
扩展到多台服务器
2实际可能未提高缓存命中率(每台机器的数据不变),需要切分(Partition)数据
切分(Partition)——利用局部性的分布式
以RDBMS的表为单位
从数据中间切分
a-c服务器1,d-f服务器2……
一致性哈希
按用途将系统分成不同的“岛”
爬虫
图像API
一般访问
以页面缓存为基础的基本运维规则
操作系统启动时不要马上投入生产环境,要先预热,即读一遍所有文件
性能测试要在缓存优化后进行
数据库横向扩展策略
灵活应用操作系统缓存
尽量让数据库大小小于物理内存
考虑表的结构设计对数据库大小的影响
建立索引
B+树
提高搜索效率(logn),改善磁盘寻道次数
MySQL的explain命令帮助查看索引是否有效
MySQL的分布式
master/slave设计(master更新,slave读)
查询可以扩展(slave)
但master无法扩展(数据一致性)
但Web应用大多数情况下90%都是读取查询
master的负载可通过分库分表或更换实现方法来解决
MySQL的Partition
将联系不紧密的表放在不同机器上
避免对不同机器上表进行JOIN操作
使用INNER JOIN或where...in…
使用自定义的ORM
Partition的代价
运维变得复杂,故障率上升,成本上升
实现冗余化最少需要多少台机器
4台——1台master,3台slave
3台slave中,一台用于提供持续服务,一台可能会故障,最后一台用于故障后复制
Web服务的基础设施重视的三点
低成本、高效率
不应追求100%可靠性
设计很重要
可扩展性和响应时间
开发速度很重要
Web服务经常添加或更改功能,需为服务提供灵活的资源
一台服务器能处理的流量极限
Hatena标准服务器:4核CPU,8G内存;
性能:繁忙时每分钟几千请求
若4核CPU*2,32G内存
100w~200wPV/月
调优
掌握负载
服务器监控工具
冗余性与系统稳定性
master的冗余化
multi-master
通常有两台服务器,组成Active/Standby结构
一台是Active的,另一台Standby
两台服务器互为slave,一方的写入数据传入另外一方,双向replication
当Standby通过VRRP协议发现Active停机,则Standby自动提升为Active,变成新的master
Active服务器有个虚拟ip,将此ip分配给哪台机器,哪台机器就是Active的master
缺点
还是有不一致的风险
系统的稳定性
资源应都保留一定余量,只用到70%左右
去除不稳定因素(尽量自动化处理)
规定SQL负载上限
减少内存泄露,遇到可自动重启
异常行为的自律控制
自动DOS判断
自动重启
自动终止耗时查询
虚拟化技术
好处
可扩展性
将额外开销降至最低
动态迁移
性价比
提高资源利用率
提高运维的灵活程度
软件层面的主机控制
高可用性
环境隔离
Hatena的虚拟化应用
Xen(CentOS 5.2、Xen 3.0.3)+ 本地磁盘构建LVM
用HyperVisor替代IPMI
使用准虚拟化(ParaVirtualization)
控制资源消耗
负载过高时警告
调整负载
检测工具:monit
提高资源利用率
CPU空闲 --> Web服务器
IO空闲 --> 数据库服务器
内存空闲 --> 缓存服务器
避免消耗倾向相同的组合在一起
虚拟化的额外开销
CPU:2%~3%
内存性能:10%
网络性能:50%
IO性能:5%
SSD的寿命
损耗程度指标:S.M.A.R.T值中的E9(Media Wearout Indicator)---> smartctl命令
Hatena写入最频繁的SSD用了9个月左右
网络的分界点
1Gbps,即30wpps,是PC路由器的极限(1Gbps是千兆以太网的界限,30wpps是Linux内核的极限)
对策:多个PC路由,购买昂贵成品路由
500台主机,是子网、ARP表的极限
对策:对网络进行层次化
RDBMS还是k-v存储
判断依据
平均数据大小
最大数据大小
新数据增加频率
更新频率
删除频率
访问频率
MyISAM vs. InnoDB
MyISAM
优点
未经update、delete的表也能快速insert
启动、停止十分迅速
表移动、改名称可直接从文件系统中操作
缺点
异常停止可能会损坏表
不支持事务
update、delete、insert(追加数据之外)会锁表,在更新较多的应用中性能不好
适合场景
只有数据追加
使用SELECT COUNT(*)
InnoDB
优点
支持事务
异常停止恢复
数据更新时执行行锁定
缺点
启动、停止慢
表操作完全通过数据库
适合场景
更新频率高
需要事务
分布式k-v
memcached
TokyoTyrant
缓存系统
Squid
用作HTTP、HTTPS、FTP等多种(反向)代理
访问控制、认证功能
Varnish
高性能HTTP加速器
灵活的设置语言
基本完全在内存中执行
速度比Squid快
nginx、pound……
缓存服务器上线时注意
两台负载均衡时,一台故障会导致另一台无法承受负载
备足服务器
即使备足服务器也要注意
新服务器(或刚启动)要预热,流量从小到大慢慢增大
Hatena的规模(2010年4月)
注册用户150w,UU1900w/月
请求数:几十亿/月
繁忙时流量:850Mbps(不含图像)
硬件(服务器)600台,通过虚拟化技术,主机超过1300台
日志每天几GB级别,数据库GB到TB级别
系统增长的战略
最小化开端、预见变化的管理和设计
平衡效率和质量
开会、规范化、文档、敏捷等
GB级别(千万)的文本数据库,不用索引,一句select查询200s也未能执行完
内存和硬盘的速度差异
寻址:前者是后者的10w到100w倍
传输速度(总线):前者——7.5G/s,后者——58M/s
找寻单机瓶颈(用足单机的性能,不要推测,要测量)
sar或vmstat查看是CPU问题还是IO问题
若是CPU问题
top或sar查看是系统进程还是用户程序
ps查看进程状态和cpu使用情况,确定问题进程
用strace或oprofile找出程序或进程的具体问题所在
若是IO问题
发生频繁页交换--->内存不足
ps查看程序所用内存
能否改善程序,减少内存占用
不行增加硬件或分布式
若无,则可能是缓存的内存不够
增加内存
不行就增加机器,分布式
CPU扩展比较方便,但IO负载的扩展比较困难
查看实际负载:top结果中的load average(1分钟 5分钟 15分钟)
查看是IO负载过高还是CPU负载过高:sar -P(多核)
处理大规模技术的重点
尽量在内存中进行,可实现分布式,利用局部性
算法的复杂度,O(n) --> O(logn)有质的飞跃
数据压缩和检索技术
缓存机制
页面缓存(page cache)
现代操作系统均采用虚拟内存
内核分配过的内存会尽量留下来,下次无需访问磁盘,即页面缓存
操作系统以页为单位缓存,即虚拟内存的最小单位
增加内存可提高缓存的命中率,降低IO负载
sar命令
sar -r 即可查看当前的内存状态(kbbuffered缓存使用的物理内存大小)
sar 1 3 一秒1次,总共3次
sar -u 查看CPU使用率
sar -q 查看平均负载
sar -r 查看内存使用情况
降低IO负载的策略
提高缓存,即加内存
扩展到多台服务器
2实际可能未提高缓存命中率(每台机器的数据不变),需要切分(Partition)数据
切分(Partition)——利用局部性的分布式
以RDBMS的表为单位
从数据中间切分
a-c服务器1,d-f服务器2……
一致性哈希
按用途将系统分成不同的“岛”
爬虫
图像API
一般访问
以页面缓存为基础的基本运维规则
操作系统启动时不要马上投入生产环境,要先预热,即读一遍所有文件
性能测试要在缓存优化后进行
数据库横向扩展策略
灵活应用操作系统缓存
尽量让数据库大小小于物理内存
考虑表的结构设计对数据库大小的影响
建立索引
B+树
提高搜索效率(logn),改善磁盘寻道次数
MySQL的explain命令帮助查看索引是否有效
MySQL的分布式
master/slave设计(master更新,slave读)
查询可以扩展(slave)
但master无法扩展(数据一致性)
但Web应用大多数情况下90%都是读取查询
master的负载可通过分库分表或更换实现方法来解决
MySQL的Partition
将联系不紧密的表放在不同机器上
避免对不同机器上表进行JOIN操作
使用INNER JOIN或where...in…
使用自定义的ORM
Partition的代价
运维变得复杂,故障率上升,成本上升
实现冗余化最少需要多少台机器
4台——1台master,3台slave
3台slave中,一台用于提供持续服务,一台可能会故障,最后一台用于故障后复制
Web服务的基础设施重视的三点
低成本、高效率
不应追求100%可靠性
设计很重要
可扩展性和响应时间
开发速度很重要
Web服务经常添加或更改功能,需为服务提供灵活的资源
一台服务器能处理的流量极限
Hatena标准服务器:4核CPU,8G内存;
性能:繁忙时每分钟几千请求
若4核CPU*2,32G内存
100w~200wPV/月
调优
掌握负载
服务器监控工具
冗余性与系统稳定性
master的冗余化
multi-master
通常有两台服务器,组成Active/Standby结构
一台是Active的,另一台Standby
两台服务器互为slave,一方的写入数据传入另外一方,双向replication
当Standby通过VRRP协议发现Active停机,则Standby自动提升为Active,变成新的master
Active服务器有个虚拟ip,将此ip分配给哪台机器,哪台机器就是Active的master
缺点
还是有不一致的风险
系统的稳定性
资源应都保留一定余量,只用到70%左右
去除不稳定因素(尽量自动化处理)
规定SQL负载上限
减少内存泄露,遇到可自动重启
异常行为的自律控制
自动DOS判断
自动重启
自动终止耗时查询
虚拟化技术
好处
可扩展性
将额外开销降至最低
动态迁移
性价比
提高资源利用率
提高运维的灵活程度
软件层面的主机控制
高可用性
环境隔离
Hatena的虚拟化应用
Xen(CentOS 5.2、Xen 3.0.3)+ 本地磁盘构建LVM
用HyperVisor替代IPMI
使用准虚拟化(ParaVirtualization)
控制资源消耗
负载过高时警告
调整负载
检测工具:monit
提高资源利用率
CPU空闲 --> Web服务器
IO空闲 --> 数据库服务器
内存空闲 --> 缓存服务器
避免消耗倾向相同的组合在一起
虚拟化的额外开销
CPU:2%~3%
内存性能:10%
网络性能:50%
IO性能:5%
SSD的寿命
损耗程度指标:S.M.A.R.T值中的E9(Media Wearout Indicator)---> smartctl命令
Hatena写入最频繁的SSD用了9个月左右
网络的分界点
1Gbps,即30wpps,是PC路由器的极限(1Gbps是千兆以太网的界限,30wpps是Linux内核的极限)
对策:多个PC路由,购买昂贵成品路由
500台主机,是子网、ARP表的极限
对策:对网络进行层次化
RDBMS还是k-v存储
判断依据
平均数据大小
最大数据大小
新数据增加频率
更新频率
删除频率
访问频率
MyISAM vs. InnoDB
MyISAM
优点
未经update、delete的表也能快速insert
启动、停止十分迅速
表移动、改名称可直接从文件系统中操作
缺点
异常停止可能会损坏表
不支持事务
update、delete、insert(追加数据之外)会锁表,在更新较多的应用中性能不好
适合场景
只有数据追加
使用SELECT COUNT(*)
InnoDB
优点
支持事务
异常停止恢复
数据更新时执行行锁定
缺点
启动、停止慢
表操作完全通过数据库
适合场景
更新频率高
需要事务
分布式k-v
memcached
TokyoTyrant
缓存系统
Squid
用作HTTP、HTTPS、FTP等多种(反向)代理
访问控制、认证功能
Varnish
高性能HTTP加速器
灵活的设置语言
基本完全在内存中执行
速度比Squid快
nginx、pound……
缓存服务器上线时注意
两台负载均衡时,一台故障会导致另一台无法承受负载
备足服务器
即使备足服务器也要注意
新服务器(或刚启动)要预热,流量从小到大慢慢增大
相关文章推荐
- 58. Length of Last Word
- Linux时间函数之gettimeofday()函数之使用方法
- 每日练习——2016.2.23
- 防止自己网站被拿来钓鱼
- 地图
- hive 学习笔记——表的入门操作和命令
- 高并发高负载系统架构-php篇
- HDU 1686 Oulipo
- 修改支付宝服务窗开发者网关
- 修改url中参数的值
- C/C++: 预处理指令
- 国内开源 java cms,Jspxcms 6.0.1 发布
- 异步复位同步释放的方法以及多时钟系统的复位设计
- 修改url中参数的值
- sequence有关问题
- 知识点小结
- C语言格式输入函数scanf()详解
- TCP连接状态
- 响应式布局基础二:设置viewport
- 第3章 发现新方法:快速分发新的测试版本