车东[Blog^2]

在前一期山寨交流会上：桂新说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。

以下是我在博客大巴开发中的一些实践小结：
1 数据库相关
1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，
1.2 解决这个问题目前的主要策略就是分片(share nothing)，单个数据库连接数超过100，就想办法拆分并用多个daemon提供服务，数据的拆分也降低了单表的数据量；
做个实验：
单个用户名密码表1000万数据（单个deamon 单个数据库） 可以承受多大的QPS（负载单位：query per second）？
将这个表：存储到10个Deamon 10个数据库 10个表中，单表的记录数会降低3个数量级（千万级==> 万级） 这样的情况下，可以承受多大的QPS？
1.3 对于需要全局访问的数据（比如做每天的汇总统计），可以通过另外冗余存储一份专门用于全局对比的操作用（会增加一定应用为保持数据一致性所带来的开发量）；
1.4 slowquery一般是遇到问题才去看的，其实binlog转换成文本格式后，也可以用mysqldumpslow统计的，slowquery就是执行时间超过一定阈值（缺省是1秒）的binlog，更全面查询统计，则需要打开数据库的query log，binlog其实就是没有只读操作的querylog；

2 日志相关
2.1 对于应用来说：容忍过多的非致命错误容易让错误日志变得非常难读，从而对发现很多致命错误造成麻烦；在各种系统开发间隙，统计各种错误日志也是我非常乐于去做的一件事儿，从warning faital级的PHP错误信息到404错误日志；报警后的急救车固然重要，日常的体检及时发现潜在风险较高的漏洞或缺陷并修正都会在系统真正发生报警的时候为成功抢修节约大量时间；
2.2 经常出问题的环节要有错误日志，并且格式设计的比较便于sort和grep也是很重要的一方面；

3 需求削减：
3.1 并非所有用户都需要被满足： 发现spammer和盗链者，并设法降低资源流失的速度；
3.2 通过日志统计发现用户使用较少但对系统负载很高的功能；

此外：一个管理方面问题： 开发过程本身是日志是最少的，怎么解决？