在 IBM developerworks 网站看到一篇不错的介绍 Nginx 的文档：使用 Nginx 提升网站访问速度。针对其中的几个描述，我个人感觉不是很清晰：
# 目前官方 Nginx 并不支持 Windows，您只能在包括 Linux、UNIX、BSD 系统下安装和使用；
虽然 Nginx 官方并不提供 Windows 平台的下载，但还是有热心的开发者维护 Windows 平台上编译好的版本，而且，从邮件列表中观察了一段时间，和官方发布的版本基本上是同步的。
当然，我相信不太会有人在 Windows 上跑 Nginx 吧?
还有一句话我觉得也不太妥当：
# Nginx 本身只是一个 HTTP 和反向代理服务器，它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本，例如 PHP、CGI 等；
其实针对 Nginx 的内建的 Perl 模块现在就是支持的(当然，更准确的说是在实验阶段)。
–EOF–
一直以来，支付宝的技术人员都比较低调，这次总算利用网络侠客行大会的机会，促成了对支付宝首席架构师程立的采访。如果你对支付宝的架构和开发实践感兴趣，请不要错过 InfoQ 中文站 的这次专访：《程立谈架构、敏捷和SOA实践》 。
InfoQ 编辑在 介绍页面中引用程立的这段话我很欣赏：
老子说"道生一、一生二、二生三、三生万物"。在业务愿景的技术实现过程中，
假设"道"为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。
因为支付宝一直以为用户提供良好支付体验为目标，以致于有技术人员误认为简单的支付环节背后的支付宝后台技术也是非常简单的。其实想想看为将近 1 亿用户提供服务，每日交易额几个亿人民币，技术上没有独到之处怎么能做到?
和程立一起共事也有三年多了。我工作这么多年，很少遇到这么功力深厚、勤奋、敬业的技术人，感觉他就像一台自我修正的计算机，能一直朝着既定的目标前进，这一点值得很多技术人员学习。
如果觉得这次采访不过瘾，请关注接下来的 7月26日QClub杭州站– 支付宝首席架构师程立与您分享”当SOA遭遇现实”的心得。
–EOF–
前两天在上海参加技术研讨，讨论了关于 MySQL 的一些面向企业级应用的思路，今天和几位同事开会，也谈及了能否用 MySQL 替代当前 Oracle 的问题。干脆整理一下思路，算是做个备忘。
首先说明一点的是，我不是说 MySQL 没有大企业级的应用，事实上，可以看到越来越多的成功布署 MySQL 的应用，但是，还不够多，还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较”虚”的东西。
由于 MySQL 自己一直没有一个成熟可靠的存储引擎，估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后，建树不大，而该项目带头人 Jim Starkey 前不久又离开了 MySQL，陋屋偏逢连夜雨。
Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非，Sun 从 Oracle 手里把 InnoDB 买回来。
如果进行大企业级应用，考虑到引擎本身的稳定性，似乎可选的也只有 InnoDB 了，但 InnoDB 的备份工具又是收费的。至于 MyISAM ，尽管有人的确喜欢用，但对于并发能力要求稍微严格一点，MyISAM 根本不行。
MySQL 中，在线对表对象做 DDL 操作是要锁表的，对于可用性要求比较高，而应用变化又比较频繁的环境，这是个非常很糟糕瓶颈。没想到有什么好的办法，除非，像大家开玩笑说的，把所有的表都预留出足够的空闲列，减少类似增加列的变更麻烦。
这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的，比如创建索引，可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题：添加了 ONLINE 关键字)
这个看似是个小问题，但实际上却是对很多人最为困扰的。
谢天谢地，MySQL 6.0 后终于具备在线备份的能力了。但现在，恐怕比较激进的用户也只能用版本 5 而已。
很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷，比如基于时间点的恢复)。
至于另一个常用来衡量 DB 可扩展性的特性：分区，现在 MySQL 已经能够支持了，尽管实现的的确有点晚。而使用 MySQL 的用户，一般都采取 Sharding 的策略对数据进行切分，所以，分区的问题倒似乎并不是最为关键的。
因为是整理思路，这算是这个系列的第一篇。
很多 Discuz! 的用户在论坛规模达到一定程度上，就要经常性的考虑优化的问题。现在网络上的很多热心的技术人都分享了 Discuz! 的优化经验，应该说，很多经验还是不错的，但也有的帖子可能会让用户走入误区。
多数情况下，数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难，于是有的人一看 SQL 走了全表扫描，干脆添加个索引好了。
其实这个地方值得商榷的。第一，必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以，尽量不要添加索引，索引本身对表的负面影响也是很大的，比如降低更新速度，影响并发能力等。
前面说，数据库”可能”是瓶颈，但不总是瓶颈，优化的第一步，必需要有针对瓶颈优化。很多时候，图片访问带来的压力甚至比数据库压力还大 — 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上，这时候，第一手去调整 MySQL 或许会有作用，但价值不大。
应该说，瓶颈的有效定位的确是个技术活儿，对于一个新的论坛环境，也有人用逐一尝试法来做，这倒也没什么。
静态编译 MySQL 有好处，但如果系统已经在线上运行了，在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友，静态编译到底带来多大好处? 没有几个人能说清楚。
对于 PHP 也是这样，如果一次优化从其它方式上能带来更清晰、直接的开销，就不要重新编译
这其实是第四点的延伸。而建立基准数据，实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话，象误区一描述的，添加了一个索引，短期内可能感觉快了，长期看，性能可能又会慢下来。
这可能是比较普遍的”习惯”了，有的朋友喜欢一次调整多个参数或是多个环境的设置，然后观察效果。如果每个步骤都是”对”的话，那么效果看起来是好的。如果有的步骤调节”错”的话，可能会抵消那些有效果的优化步骤。
优化策略是个见仁见智的问题。以上只是个人浅见，欢迎留言探讨。
–EOF–