一直以来，支付宝的技术人员都比较低调，这次总算利用网络侠客行大会的机会，促成了对支付宝首席架构师程立的采访。如果你对支付宝的架构和开发实践感兴趣，请不要错过 InfoQ 中文站 的这次专访：《程立谈架构、敏捷和SOA实践》 。
InfoQ 编辑在 介绍页面中引用程立的这段话我很欣赏：
老子说"道生一、一生二、二生三、三生万物"。在业务愿景的技术实现过程中，
假设"道"为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。
因为支付宝一直以为用户提供良好支付体验为目标，以致于有技术人员误认为简单的支付环节背后的支付宝后台技术也是非常简单的。其实想想看为将近 1 亿用户提供服务，每日交易额几个亿人民币，技术上没有独到之处怎么能做到?
和程立一起共事也有三年多了。我工作这么多年，很少遇到这么功力深厚、勤奋、敬业的技术人，感觉他就像一台自我修正的计算机，能一直朝着既定的目标前进，这一点值得很多技术人员学习。
如果觉得这次采访不过瘾，请关注接下来的 7月26日QClub杭州站– 支付宝首席架构师程立与您分享”当SOA遭遇现实”的心得。
–EOF–
在讨论 eBay 的Scalability最佳实践 的时候，结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然，我不是说 ACID 就不重要了)
BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义：
“Soft state” (SS) 是与 “Hard state”(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的，这样就清晰多了。
最终一致性， 也是是 ACID 的最终目的。对于 eBay 这样的大架构，是通过强大的消息总线能力来保证的。
对于 eBay 这样的大架构，另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文：BASE: An ACID Alternative，注意其中提到的的事件驱动(Event-Driven)的架构的说法。
相信在今后几年，BASE 将成为一个技术热词。ACID 当然没过时，只是各自需要合适的应用场景而已。随着互联网技术的开放性，更多的时候，一个架构师需要反复的衡量合适的应用场景。
BTW: “ACID” 英文里面有”酸”的意思，而 “BASE” 有”碱”的意思. 酸碱在一起才能中和啊，哈
–EOF–
对着眼前黑色支撑的天空 / 我突然只有沉默了
我驾着最后一班船离开 / 才发现所有的灯塔都消失了
这是如此触目惊心的 / 因为失去了方向我已停止了
就象一个半山腰的攀登者 / 凭着那一点勇气和激情来到这儿
如此上下都不着地地喘息着 / 闭上眼睛疼痛的感觉溶化了
--达达乐队《黄金时代》
好几个地方看到这个 Facebook – Needle in a Haystack: Efficient Storage of Billions of Photos，是 Facebook 的 Jason Sobel 做的一个 PPT，揭示了不少比较有参考价值的信息。【也别错过我过去的这篇Facebook 的PHP性能与扩展性】
作为世界上最大的 SNS 站点之一，Facebook 图片有多少? 65 亿张原始图片，每张图片存为 4-5 个不同尺寸，这样总计图片文件有 300 亿左右，总容量 540T，天! 峰值的时候每秒钟请求 47.5 万个图片 (当然多数通过 CDN) ，每周上传 1 亿张图片。
前一段时间说 Facebook 服务器超过 10000 台，现在打开不止了吧，Facebook 融到的大把银子都用来买硬件了。图片是存储在 Netapp NAS上的，采用 NFS 方式。
尽管这么大的量，似乎图片写入并不是问题。如上图，是直接通过 NFS 写的。
CDN 和 Cachr 承担了大部分访问压力。尽管 Netapp 设备不便宜，但基本上不承担多大的访问压力，否则吃不消。CDN 针对 Profile 图象的命中率有 99.8%，普通图片也有 92% 的命中率。命中丢失的部分采由 Netapp 承担。
图中的 Cachr 这个组件，应该是用来消息通知(基于调整过的 evhttp的嘛)，Memcached 作为后端存储。Web 图片服务器是 Lighttpd，用于 FHC (文件处理 Cache)，后端也是 Memcached。Facebook 的 Memcached 服务器数量差不多世界上最大了，人家连 MYSQL 服务器还有两千台呢。
这么大的数据量如何进行索引? 如何快速定位文件? 这是通过 Haystacks 来做到的。Haystacks 是用户层抽象机制，简单的说就是把图片元数据的进行有效的存储管理。传统的方式可能是通过 DB 来做，Facebook 是通过文件系统来完成的。通过 GET / POST 进行读/写操作，应该说，这倒也是个比较有趣的思路，如果感兴趣的话，看一下 GET / POST 请求的方法或许能给我们点启发。
总体来看，Facebook 的图片处理还是采用成本偏高的方法来做的。技术含量貌似并不大。不清楚是否对图片作 Tweak，比如不影响图片质量的情况下减小图片尺寸。
–EOF–
几乎每个接触类 Unix 操作系统的工程师都知道如何查看系统负载。但这东西的工作机理到底是怎样的，可能没有多少能说清楚。对比了一些相关信息，加上自己的理解，做一下笔记。
Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章：UNIX® Load Average Part 1: How It Works】
下面是一个 uptime 命令输出：
$ uptime
18:57:48 up 423 days, 3:55, 2 users, load average: 1.16, 1.12, 1.20
尽管各种信息来源的定义都不太确定。能确定的一件事情是，你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟，这里的 HZ 是系统定义的变量). 参见 Linux Kernel 这段代码:
869 count -= ticks;
870 if (unlikely(count < 0)) {
871 active_tasks = count_active_tasks();
872 do {
873 CALC_LOAD(avenrun[0], EXP_1, active_tasks);
874 CALC_LOAD(avenrun[1], EXP_5, active_tasks);
875 CALC_LOAD(avenrun[2], EXP_15, active_tasks);
876 count += LOAD_FREQ;
877 } while (count < 0);
878 }
879}
对一般的系统来说，根据 CPU 数量去判断，如上面的例子， 如果平均负载始终在 1.2 以下，而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。
这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书，尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个 DBA、架构师 的必须书。】
这么说实际上带来另外两个疑问：
1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器，我的建议是看操作系统怎么识别的 CPU，根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数，建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。
2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。
多数情况下，Load 过高都未必和 CPU 有关。或许倒是有一个例外的，就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器，麻烦就来了
任何一个相对成熟的站点都会利用 Cacti（基于RRDTool） 等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去，这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。
很多对可用性要求比较高的环境都建立了 邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为 物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话，意义就不大了。比如，数据库服务器有 4 颗 CPU，那么 Load 高于 4 就应该报警出来，设置比 4 高可能意义不大，因为接到报警还有个人为响应时间...
真相：系统 Load 高也或许是因为在进行 CPU 密集型的计算(比如编译)
真相：Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的，也可能是耗 I/O 乃至其它因素的。
真相：Load 只是表象，不是实质。增加 CPU 个别时候会临时看到系统 Load 下降，但治标不治本。
小小一个 Load 讲究其实不少。英文信息其实比较全的，尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议，请指正或告知。
--EOF--
A ：一般情况下，这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ，针对 I/O 开销比较大(重点看全表扫描）的 SQL 进行优化。根据经验值，每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作，尽管存储的吞吐可能还没那么大，也可能会把 CPU "塞满"。