大规模web服务开发技术
《大规模web服务开发技术》笔记
2012-02-02 15:06 by teloon, 1727 visits, 收藏 , 编辑
前段时间趁空把 《 大规模 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 …… 缓存服务器上线时注意 两台负载均衡时，一台故障会导致另一台无法承受负载 备足服务器 即使备足服务器也要注意 新服务器（或刚启动）要预热，流量从小到大慢慢增大http://www.cnblogs.com/teloon
作者： Leo_wl
出处： http://www.cnblogs.com/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息