《大规模web服务开发技术》笔记
前段时间趁空把《大规模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……
- 缓存服务器上线时注意
- 两台负载均衡时,一台故障会导致另一台无法承受负载
- 备足服务器
- 即使备足服务器也要注意
- 新服务器(或刚启动)要预热,流量从小到大慢慢增大
学习时的痛苦是暂时的 未学到的痛苦是终生的