大规模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负载的策略

  1. 提高缓存，即加内存
  1. 扩展到多台服务器
  1. 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服务的基础设施重视的三点

  1. 低成本、高效率
    • 不应追求100%可靠性
  1. 设计很重要
    • 可扩展性和响应时间
  1. 开发速度很重要
    • 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……
  • 缓存服务器上线时注意
    • 两台负载均衡时，一台故障会导致另一台无法承受负载
      • 备足服务器
    • 即使备足服务器也要注意
      • 新服务器（或刚启动）要预热，流量从小到大慢慢增大
posted on 2012-12-27 16:23  一个人的天空@  阅读(407)  评论(0)  编辑  收藏  举报