自从看了《编程珠玑》第7章粗略估算之后就养成了一个奇怪的习惯，喜欢去计算身边的数字。比如一个城市共有多少台电梯，中国共有多少座桥梁等。
粗略估算又叫费米近似(Fermi problem)，比如坐广州到深圳的和谐号动车组时候就想，广深线每分钟进入火车站人流量有多大？这个似乎要请专业的调查公司才能得到结果，但实际上每个人几乎都可以算出来，尤其是程序员。
- 和谐号列车有8个车厢，1号和8号是头等车厢，一般坐不满 ，满员估算50人。除去5号餐车。因此共有5×100+100=600个座位。
- 15分钟一趟，每天从6点到22点，共发车18*(60/15)=72次
- 根据观察，广深线平时都有座位，但也不会太空。假如平均坐满70%座位的话，每天单向人流量为 72 * 600 * 70% = 30240 人
- 每分钟人流量为30240/18/60=28人
- 进一步考虑，需要几个售票窗口。估算平均每个乘客购票需要15秒，则至少7个窗口才不会引起排队现象。这跟平时观察一致，平时非高峰时刻如果窗口在5个以下会出现排长队现象。
72法则
72法则是会计上的一个经验。假设最初投资金额为100元，复息年利率9%(r%)，利用“72法则”，将72除以9（增长率），得8(y)，即需约8年时间，投资金额滚存至200元（两倍于100元），而准确需时为8.0432年。上面的r和y换成任何数字，只要相乘总数是72, 该法则都成立。
72法则在初略估算中经常要用到，比如上面广深线的例子，假如客流月增长率3%, 则24月之后，广深线客流量会翻一番。(24*3=72)
编程领域估算
服务器编程领域经常面临预先估算，因为在程序开发前实际的场景并不存在。据去年《程序员》杂志介绍，奥运订票网站的瘫痪，是因为每秒请求数超过2200次。假如这个请求数都不能预先估算到的话，应该算是架构设计的失败。
更多有趣例子及深入阅读
- 中国共有多少台正在运行中的服务器？
- 你有多少根头发?
- 成年人体的骨头块数。
- 孔子的出生年份（公元）
更多有趣的例子可参看美国马里兰大学更多初略估算测试大全(英文)
这个问题是否应该从电信/网通的全国机房数和每个机房数的服务器这两个数据入手进行估算。不过从google上随便搜了一下，貌似这些数据不好得出
“粗略估算” 貌似很有意思，也去买本《编程珠玑》看看~~~
文章很有意思。八封一下奥运订票网站的瘫痪，高并发的情况他们肯定是想到的，能接这种国家级系统项目的公司，实力和牛人肯定也不差不少；我个人认为宕机几乎是必然。原因有：
1大量非常规的请求，如黑客攻击等
2购票流程复杂和应用设计的不合理，使得多了很多不需要的请求。当时我实际购票的时候深有感触，当页面出不来的时候，很多用户并不是等待处理完，而是拼命地F5、刷新，结果就是造成新的数据库的压力和脏数据。我记得当时页面有好几个，如果一个页面失败，等于都要重新来过。每个页面，都要操作数据库。
每秒2000的并发，实际上并不是一个非常大的量，10-15台前端都算保守了。优化好更省机器。
有趣、有用
奥运订票网站的瘫痪
是DB的压力过大造成
像这种项目，主要是吞吐量不太好估算 当然可以做超大容量的平台，但是这是花银子的
“1.和谐号列车有8个车厢，1号和8号是头等车厢，一般坐不满 ，满员估算50人。除去5号餐车。因此共有5×100+100=600个座位。” 5 是什么，100 是什么？
“2.15分钟一趟，每天从6点到22点，共发车18*(60/15)=72次” ， 从6点到22点应该是16个小时吧？
to renenglish
1、5是除开1号、8号、5号车厢后的其余车厢数；100是这5节车厢的乘客数。
2、包括6和22就是18