读书：大规模web服务开发技术 -伊藤直也
一 大规模和小规模
数据中心实际场景？
1 注册用户100万年以上，1500万 Unique User
2 几十亿请求/月（不含图像）
3 busy 流量430Mbps
4 硬件服务器500台以上
开源软件
路由器采用
http分派
分布式数据库同步数据复制mysql replication
深夜维护及消耗体力又消耗精力，一个晚上宕机好多次是不行
小型机房服务器增加导致电力不足，增加服务器跳闸
没能有计划的应对持续增长的流量和负载==》建立专门的系统运维团队
小型机房迁移到数据中心，重新设计网络，替换旧服务器
总结现有系统负载，测量服务瓶颈，
对于I/O负载较高的扩展内存
对CPU负载过高的升级CPU
根据用途决定硬件配置
冗余性，通过多重备份来增加系统的可靠性
LVS+keepalived Linux虚拟服务器和keepalived负载均衡器+运行状态监视
虚拟操作系统 提高设备运行效率 改善可维护性
服务器信息管理系统
重新设计服务器基础设施的架构【运维和架构师干】
重新设计应用程序的各种逻辑和数据库的表结构，逐步排除效率低的地方【开发者和DBA以及架构师干，对于开发者的职责而言，在开始写代码之前设计应用程序的逻辑和数据表结构==》引申为如何根据业务设计应用程序以及设计表结构】
必要时自己开发搜索引擎子系统
过早优化绝不是最佳方案，开始建立负载均衡成本很高
实施系统维护后讲操作方法作为工作日志发布到博客上，以便日后参考
是否有维护计划，判断系统更新，查看负载情况
服务器虚拟化的七大好处：
运维：维护硬件与软件
虚拟化-》阿里云：节省基础服务架构和网络维护和硬件购买维护
虚拟化后的好处：
1 服务器硬件的资源池，提高资源利用率。将服务器物理资源抽象成逻辑资源，让一台服务器变成几台甚至上百台相互隔离的虚拟服务器，我们不再受限于物理上的界限，而是让CPU、内存、磁盘、I/O等硬件变成可以动态管理的“资源池”，从而提高资源的利用率，简化系统管理，实现服务器整合，让IT对业务的变化更具适应力--------这就是服务器的虚拟化。
2 降低物理成本，节省空间，节约成本，提高基础架构的利用率，提高稳定性，减少宕机，提高业务灵活性，快速迁移。提高可用性，带来具有透明负载均衡、动态迁移、故障自动隔离、系统自动重构的高可靠服务器应用环境。通过将操作系统和应用从服务器硬件设备隔离开，病毒与其他安全威胁无法感染其他应用。
3 通过动态资源配置提高IT对业务的灵活适应力，支持异构操作系统的整合，支持老应用的持续运行，减少迁移成本。支持异构操作系统的整合，支持老应用的持续运行，支持快速转移和复制虚拟服务器，提供一种简单便捷的灾难恢复解决方案。
每天早上小团队10分钟短会 前日进度和今天计划
其他工程师审核代码，挑bug,找出负载过高的代码，灵活测试后，上线
不代码审查和结对编程，提交系统容易造成致命的bug
搜索引擎对内存要求苛刻的地方也有人使用c++
主要的中间件有Linux apache mysql memcache
表中数据三亿条 select * from table 根本无法返回查询结果
不使用索引查询 大数据时候 200秒也返不回查询结果
数据太大 出于调试也会导致过高的负载
大规模数据的难点在于无法在内存中计算
内存比磁盘快10万倍到百万倍
在现在计算机编写程序 必须考虑内存和磁盘的差异，必须考虑可扩展性 ，scalability极其重要的一点
不要推测 要测量
单台服务器性能发挥大极致
瓶颈：
0 查看平均负载 top uptime
1 sar 查看CPU使用率和io使用率 ，确认cpu/io有无瓶颈
top sar/vmstat 查看cpu 使用率和i/o等待率
系统程序原因？用户程序原因？
ps 查看进程状态 CPU使用时间 确定导致问题的进程
strace跟踪 oprofile剖析
一般CPU负载来自于以下：
磁盘或内存容量处于理想状态，程序失控消耗太多CPU
如果吞吐量有问题——>增加服务器——>改善程序逻辑和算法
此时算法就很重要了
内存不足就要增加内存——>内存无法增加就可以考虑分布式——>分散存储数据或者增加缓存服务器；或者改进减少i/o频率的方法
操作系统调优，如何改善i/o性能?
能否通过增加内存的方式保证缓存区域的方法解决?
数据量本身是否过多?
有无必要改变应用程序的i/o算法?
(1)如果物理内存比数据规模还大，考虑全部缓存
(2) 经济成本的平衡选择性能最为经济的服务器8-16gb
(3)无法全部缓存，扩展多台服务器
1 为了服务器性能的scalability, scale up和scale out 哪一种比较好的提高服务器的性能，说出你的理由。
当然是scale out，因为硬件和性能并不成正比。
2 应用程序造成的服务器内存不足如何解决，说出2种方法。
(1)能否通过增加内存的方式保证缓存区域的方法解决：内存增加,缓存容量增加可以降低i/o负载
(2)数据量本身是否过多,有无必要改变应用程序的i/o算法
3 web应用程序和服务器负载的关系
web 的三层结构：代理服务器，应用程序服务器，数据库
web application 在进计算时也就是接受http请求，查询数据库，数据库返回变成html发给客户端基本只消耗CPU;数据库计算时需要较多i/o资源
4 为什么说数据库的可扩展性很难保证
数据库进行大量的读写操作，数据量越大，越无法在内存上处理。大规模环境中产生i/o负载的服务器本来就很难分散，加上频繁产生的磁盘io,很容易导致服务器变慢。也就是说，大规模必须使用磁盘，而频繁的磁盘io造成了瓶颈。但是仅仅增加服务器是不行的，一旦这样说，立即就会被看到你知识背景的匮乏，太可怕了，对你自己和公司来说。一个是不可分，一个是磁盘io频繁，不是增加服务器就能解决的。
5 CPU负载的扩展
增加相同结构的服务器，通过负载均衡来实现
web/应用程序服务器/爬虫
i/o负载的扩展
数据库
大规模数据
6 top 仅凭平均负载无法确定是CPU负载还是io负载
CPU负载=计算密集型 ；io负载=io密集型
大多数情况下应用程序服务器是计算密集型的服务器
数据库服务器是io密集型的服务器
多核CPU，CPU负载可以分散然而io负载不可以分散
7 程序开发的底层基础
大规模数据处理的技巧就是他在内存中能完成多少
为什么必须在内存中完成
磁盘寻道次数极大的影响着可扩展性和性能，应该在最大限度减少磁盘寻道次数的意义上灵活运用内存，充分利用局部性的分布式
使用能应对数据量增加的算法
有时候可以利用数据压缩（缩小数据，减少寻道次数，使磁盘读取次数降到最低，而且容易缓存到内存中）和搜索等技术
操作系统的缓存
以分布式为前提应用关系数据库管理系统
大规模环境中算法和数据结构要怎么用
8 处理大规模数据的要点，IO由操作系统负责
以缓存为基础的io负载降低策略——>尽可能在内存中完成——>无法在内存中完成的分分到多台服务器上。如何保证分散的可扩展性。
数据压缩和速度：造成少量的CPU负载，降低i/o负载
9 操作系统访问磁盘的机制
磁盘和内存有10万到100万的速度差异，操作系统本身有迅速访问磁盘数据的机制。操作系统利用内存减少磁盘的访问次数。Linux有页面缓存，文件缓存，缓冲区缓存这些机制。
10 进程从磁盘读取数据的过程
进程无法直接访问磁盘，进程只能访问虚拟内存，
操作系统读出4kb的块先放到内存，操作系统把内存地址变成虚拟的告诉进程。
进程读取完毕不会释放，保留下来成为页面缓存
Linux 只要有空闲内存 就会全部用于缓存
11 mysql 应用的三大要点
（1）灵活应用操作系统的缓存
考虑所有数据的大小，尽量将数据量维持在内存量之下；内存不足时候增加内存；如何判断内存？
很多人会随意的按照自己喜欢的方式来设计表结构；但是表结构的设计非常重要。每个记录增加8字节，如果有3亿条记录，就是24亿就是2.4GB,3GB,表结构稍有错误，数据量以GB为单位增减；大量数据的时候，表结构要设计紧凑
（2）正确设置索引
基本使用索引的是where，order by, group by
什么时候索引有效：明确设置索引，主键和unique约束
复合索引
查看索引效果
explain select * from table where ID= 2
长时间的运营出现服务难免会出现索引不生效的情况；对于事先堵不完的漏洞，准备一套机制是很有效的
（3）以横向扩展scale out为前提的设计
master/slave 架构
查询发给slave,多slave,更新发给master，统一更新
partitioning 表分割 充分利用局部性进行分散，提高缓存利用率；表的结合不是很紧密的；表的数据大小来看又不得不分割；库的额外开销过大就需要直接写sql语句
表分割降低负载，增加局部性，提高缓存实现分布式；但是增加了运维难度，导致故障恢复时间变长，故障率上升，经济成本上升
开发：
web API (son + http)取代rpc
超出rdbms处理能力怎么办
用批处理取出数据
创建专用的索引服务器，通过web api 访问
12 数据结构和算法基本讲到算法实现，从来不讲怎么应用到系统中，以及怎么运维：
CPU 和内存的计算机资源都是有限的，算法太重要了。
【非常棒的思考方式：如何用有限的资源解决必须解决的问题。】
13 java python 语言不通用，但是算法是通用的语言
学习贝叶斯过滤器，就可以编写自动化分类，编写垃圾邮件过滤器。
14 算法评测；在开发中评测和估算非常重要
散列搜索的给定的键是几乎唯一，搜索值处理是o（1），散列搜索整体复杂度为o(1)
线性查找为o(n)
二分查找为o(log n)
一般基于比较的算法无论怎么优化都不可能比nlog n fast;能达到nlog n可以被认为是高速算法
15 提高整体的吞吐量
数据压缩和速度：造成少量的CPU负载，降低i/o负载
