说说大量列表项的排序展示问题

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

上周五去了一趟淘宝，在淘宝二楼实时展示交易信息的大屏幕前看了一会儿。发现关于商品显示的排序列表是两排，左右排列的。

1 商品名一 2 商品名二
3 商品名三 4 商品名四
5 商品名五 6 商品名六
......
N-1 商品名N-1  N 商品名 N
......

尽管符合从左到右的阅读习惯，看起来感觉怪怪的。前一段时间有不少关于电梯楼层按钮排列问题的帖子(一，二），针对电梯的按钮应该说已经讨论的很好了，但我感觉如果针对 Web 页面上大量列表项的排列显示来说，很有值得商榷的地方。

我再抛一个另外的反面例子，关于百度 Mp3 歌曲 Top 500 的列表展示：

(点击图片看大图或者到 Baidu 站点上体验)

假设 M 行 x N 列的展示，如果 M 很大，而 N 很小，在前面几行过去之后(一般是 N行*N列后)，会发现非常难以定位你要找的歌曲。尤其是越到后面效果越差。如果 M 和 N 都很小，那么相差是不大的(不知道这是什么心智模型? 尤其是对该项的描述也符合 M：N 值很小，比如 Flickr 的图片展示）。

这个其实和电梯楼层按钮排列的问题不太一样：电梯上面只有一个按钮(楼层号)，而 MP3 列表排列项后面还有该项的名字或描述(MP3 名字, 艺术家名字)。需要展示的内容性质和信息量已经变化了。

这只是 UE 门外汉的个人看法。供参考。

–EOF–

BTW, 注意到火车站和机场的公示牌显示倒是挺符合阅读习惯的。

关于 Nginx 的几个误解

在 IBM developerworks 网站看到一篇不错的介绍 Nginx 的文档：使用 Nginx 提升网站访问速度。针对其中的几个描述，我个人感觉不是很清晰：

# 目前官方 Nginx 并不支持 Windows，您只能在包括 Linux、UNIX、BSD 系统下安装和使用；

虽然 Nginx 官方并不提供 Windows 平台的下载，但还是有热心的开发者维护 Windows 平台上编译好的版本，而且，从邮件列表中观察了一段时间，和官方发布的版本基本上是同步的。

当然，我相信不太会有人在 Windows 上跑 Nginx 吧?

还有一句话我觉得也不太妥当：

# Nginx 本身只是一个 HTTP 和反向代理服务器，它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本，例如 PHP、CGI 等；

其实针对 Nginx 的内建的 Perl 模块现在就是支持的(当然，更准确的说是在实验阶段)。

–EOF–

InfoQ 专访支付宝首席架构师程立

一直以来，支付宝的技术人员都比较低调，这次总算利用网络侠客行大会的机会，促成了对支付宝首席架构师程立的采访。如果你对支付宝的架构和开发实践感兴趣，请不要错过 InfoQ 中文站的这次专访：《程立谈架构、敏捷和SOA实践》。

InfoQ 编辑在介绍页面中引用程立的这段话我很欣赏：

老子说"道生一、一生二、二生三、三生万物"。在业务愿景的技术实现过程中，
假设"道"为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。

因为支付宝一直以为用户提供良好支付体验为目标，以致于有技术人员误认为简单的支付环节背后的支付宝后台技术也是非常简单的。其实想想看为将近 1 亿用户提供服务，每日交易额几个亿人民币，技术上没有独到之处怎么能做到?

和程立一起共事也有三年多了。我工作这么多年，很少遇到这么功力深厚、勤奋、敬业的技术人，感觉他就像一台自我修正的计算机，能一直朝着既定的目标前进，这一点值得很多技术人员学习。

如果觉得这次采访不过瘾，请关注接下来的 7月26日QClub杭州站– 支付宝首席架构师程立与您分享”当SOA遭遇现实”的心得。

–EOF–

MySQL 大企业级应用可行性分析(之一)

前两天在上海参加技术研讨，讨论了关于 MySQL 的一些面向企业级应用的思路，今天和几位同事开会，也谈及了能否用 MySQL 替代当前 Oracle 的问题。干脆整理一下思路，算是做个备忘。

首先说明一点的是，我不是说 MySQL 没有大企业级的应用，事实上，可以看到越来越多的成功布署 MySQL 的应用，但是，还不够多，还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较”虚”的东西。

存储引擎

由于 MySQL 自己一直没有一个成熟可靠的存储引擎，估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后，建树不大，而该项目带头人 Jim Starkey 前不久又离开了 MySQL，陋屋偏逢连夜雨。

Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非，Sun 从 Oracle 手里把 InnoDB 买回来。

如果进行大企业级应用，考虑到引擎本身的稳定性，似乎可选的也只有 InnoDB 了，但 InnoDB 的备份工具又是收费的。至于 MyISAM ，尽管有人的确喜欢用，但对于并发能力要求稍微严格一点，MyISAM 根本不行。

在线 DDL 锁表问题

MySQL 中，在线对表对象做 DDL 操作是要锁表的，对于可用性要求比较高，而应用变化又比较频繁的环境，这是个非常很糟糕瓶颈。没想到有什么好的办法，除非，像大家开玩笑说的，把所有的表都预留出足够的空闲列，减少类似增加列的变更麻烦。

这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的，比如创建索引，可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题：添加了 ONLINE 关键字)

这个看似是个小问题，但实际上却是对很多人最为困扰的。

在线备份问题

谢天谢地，MySQL 6.0 后终于具备在线备份的能力了。但现在，恐怕比较激进的用户也只能用版本 5 而已。

很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷，比如基于时间点的恢复)。

至于另一个常用来衡量 DB 可扩展性的特性：分区，现在 MySQL 已经能够支持了，尽管实现的的确有点晚。而使用 MySQL 的用户，一般都采取 Sharding 的策略对数据进行切分，所以，分区的问题倒似乎并不是最为关键的。

因为是整理思路，这算是这个系列的第一篇。