作者文章: Fenng

Founders at Work

为什么有些人创业成功，而更多人失败? 成功的人当初承担过哪些压力，做过那些重要的抉择? 有没有初创公司的创业者们必须要看的一本书? Founders at Work 或许能担当此重任。

前一段时间在财帮子网站创建人孟岩的推荐后读完了这本书，最近这几天分析 Paypal 的一些东西，又把电子版翻了出来。重新读了一遍对 Paypal 创始人 Max Levchin 的采访。10 年前创建的 Paypal 现在是美国互联网最赚钱的互联网企业，而走出 Paypal 的创建者们，也已形成了 Paypal 黑帮，手握着世界 Web 2.0 公司的权柄。

Paypal 最早并不是做在线支付的。因为 Levchin 对软件安全兴趣由来已久，最初做过软件加密、手持设备转帐软件等，在为手持设备用户开发软件的过程中发现了在线支付的庞大需求量和无限商机，这里面比较关键的一点是Paypal 的及时转身。

如果用一句话概括 Paypal 该怎样描述? 表面是财务服务公司，实际是一家安全公司。 Paypal 最开始的一段时间，最大的挑战倒不是来自竞争对手那里，而是恶意用户的欺诈行为。最高的时侯 Paypal 每个月因为欺诈造成的损失超过 1000 万美元（前面有篇文章我提到 Paypal 现在有达 0.25% 的资损，我还觉得挺高的，没想到以前更高)，而开始大家对于可能存在的欺诈损失还有些一头雾水，可见摸着石头过河的事情，大家都干过。

与 X.com 合并后，Max Levchin 作为 CTO，而来自 X.com 的”那个家伙”做 CEO 。Paypal 技术架构差点转向 Windows 平台，因为 X.com 是运行在 Windows 上的。工程师的文化对立也比较明显，貌似一场冲突不可避免。问题如何化解呢? Levchin 精心构造了一次测试，对 Unix 、Windows 针对某应用作压力测试，”证实” Windows 扩展性只有 Unix 上的 1%。”那个家伙”闭上了嘴。随之不久，那个家伙离开了 Paypal。如果当初转向 Windows，或许现在的 Paypal 也不是这个样子了…

仅仅因为这篇对 Max Levchin 的采访，就让我要推荐一下这本书。其实，看看其它 Founder 的访谈记录，有趣的东西还有很多，各取所需吧。

–EOF–

从 Flickr 的 DB 服务器配置说起 Swap

又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这”甘蔗”已经被吃过了。

针对主机环境的实践参考

Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器模式。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。

大内存数据库服务器的 Swap 设置问题

上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:

echo 0 > /proc/sys/vm/swappiness

个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：

swap_tendency = mapped_ratio/2 + distress + vm_swappiness;

其中 vm_swappiness 默认值是 60.

这是个防御性的措施。Linux Kernel 2.6 （个别版本）有些诡异行为，当有大量物理内存空闲的时候，Linux 仍(或许)会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。

如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。

还有人用的方式是把 Swap 建立到 RAM 盘上。

Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。

我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑…

–EOF–

Paypal 的数据仓库管窥

一直以来，Paypal 的技术信息都很封闭的，很少能看到披露后台关于信息架构的东西。

Paypal 当前的数据仓库用的是 NCR Teradata ，32 个节点，50 TB 的数据，耗时三年打造。而整个公司投入在 BI 范围上的资金占据全部 IT 投入的 60%。

之前 Paypal 用的是 Oracle 数据仓库的解决方案，旧的 Oracle 数据仓库环境其实类似生产环境 Schema 数据的镜像。从 Oracle 到 Teradata ，不是简单的迁移，而是完全重构了数据模型，对数据重新清洗并提高数据质量。

因为欧美是依赖信用卡的消费习惯，所以 Paypal 面对的信用卡消费欺诈还是很严重的，一度高达 0.25% 的资损(印象中好像有段时间来自俄罗斯和东欧的欺诈特别多)，这可能也是 Paypal 在数据仓库/BI 上投入重金的一个原因(此外还收购了 Fraud Sciences 公司来减少这方面的风险)。

除了有效提供损益报告，Paypal 的数据仓库还必须即时有效的提供的一个指标叫做 “Funny Mix”，代表信用卡资金交易帐务平衡指标与 ACH(自动化清算所，Automated Clearing House) 帐务平衡。

作为对比 eBay 数据仓库环境每天新进来的数据就有 40TB(和Yahoo! 的DW不相上下)，这样的数据量，处理起来的难度还是有一点点的，据说原来技术人员 90% 的时间要花费在数据清洗上，现在也开始用 Teradata 大集中式数据仓库的模式了。

尽管收集 Paypal 的信息非常不容易，但也希望能挖掘出点有意思的东西来。

–EOF–

CAP：高可用架构的另一基石

在上周六的 QClub 上，BASE 成为了一个热点话题，其实除了这个 BASE 之外，还有个 CAP 理论也是值得关注一下的。这个概念也来自 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer ，应该说他 10 年前的那篇 Lessons from Internet Services: ACID vs. BASE 是互联网技术最为重要的一篇文章了。

C: Consistency 一致性 
A: Availability 可用性
P: Tolerance of network Partition 分区容忍性(有翻译为耐受性的，个人觉得不妥)

熊掌与鱼不可兼得，三个目标不能同时满足。如果对”一致性”要求高，且必需要做到”分区”，那么就要牺牲可用性；而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。

CAP 不是什么高深的东西，应该说 CAP 只是一个经验理论，切不可钻牛角尖，号称自己做的东西能打破 CAP 理论，那只是无意义的事情罢了。

如果知道 ACID(酸) 、BASE(碱) 在词典中的含义，那么这个 CAP 的辞典含义也很有趣。

–EOF–

最后推荐阅读一下这篇：可伸缩性原则