随着国内游戏公司不断上市，相关从业人员也是水涨船高。钱多、人傻、速来，以此为诱饵，猎头公司估计也大赚一票。作为控制用户数据的 DBA 肯定是颇为短缺的。
长夜漫漫，闲极无聊，收集了一下当前游戏公司都在招聘什么数据库的 DBA。未必完全准确，权做参考。
| 公司－ | 数据库 |
| 盛大－ | Oracle/MySQL/SQL Server |
| 金山－ | Oracle/MySQL/SQL Server |
| 网龙－ | MySQL |
| 九城－ | Oracle |
| 网易－ | Oracle |
基本能看出来，Oracle DBA 还是比较多，多数公司还是会把核心的数据或应用跑在 Oracle 上。而排在第二的就是 MySQL了。至于 SQL Server 排在最后的原因，可能还是因为有些小游戏跑在 SQL Server 上，而维护基本是开发人员搞定，专门的 DBA 就不需要了。至于 DB2 ，还真不知道哪家游戏公司用。
至于核心的技能，MySQL 在 Replication 与 Cluster 架构两个方面是必须的。而针对 Oracle 来说，优化、 Data Guard / 备份恢复则是必须要求的技能。
--EOF--
今天参加了 EMC 组织的存储技术培训。因为频繁被电话打扰，导致听课效果并不是那么好。很多内容似曾相识，只是都断断续续的，几乎每次培训都是这样的，总有"断点"。
上午是 CLARiiON 的简单介绍，在模拟操作的时候我发现了以前漏掉的一个盲点：Binding LUN 的时候，那个 Alignment Offset 的选项到底是干啥的? 讲师简单说了一下，感觉不太对路子。刚才闲下来，查找了一下这个信息，大致搞明白了这个 ”Alignment offset“。
用 ”Alignment offset EMC“ 作关键字搜索到的第一篇文档是 Dell 工程师写的。这里面用了一个词 "signature block" , 莫名的一个词，我相信是 Dell 工程师自己发明的(用 Metadata 不就得了)。另外两个关键词是 "Windows" 和 "31.5KB" ，为啥是 31.5KB ，不知道。接下来在 EMC 的 Powerlink 网站上找到了比较详细的说明。
首先确定一下，这个问题更多是影响 Windows 系统。
老的 BIOS 代码，使用 ”柱面、磁头、扇区数“这一套机制而不是 LBA （Logical block addressing ）的模式来寻址。Linux 的 fdisk 工具还是 Windows 磁盘管理器，在每个格式化的设备上都放置一份 MBR 。这个 MBR 占用 63 个隐含扇区 (63*512=31.5KB, Bingo!)。这个问题在 Windows 上存在，在 VMware 上也存在，offset 同样是 63。 在有些 Linux 上，因为 Boot Loader 的不同，也会有类似的问题。
无视 Alignment offset 会导致的问题:
如图所示，一个 IO 会分裂到两个 Disk(Device/LUN) 上去，后果很严重。和我以前描述过的 4k Offset 问题本质上是一样的。只是这个是针对文件系统的。
那么，如何校正这个 ”对齐偏移量" 呢?
存储厂商的推荐是如果用 Snap View / SAN Copy 等存储级别的操作的话，不要折腾，用系统默认的就成，否则，用主机端的解决方案。
主机端的解决方案分为 Windows 32位、Windows 64 位、Linux、VMware 几种。
1） 对于 32 位的 Windows ，使用 Windows 系统资源包的 diskpar.exe 来设定 offset ( 据说 Windows 2003 SP1 上的 diskpart.exe 已经具备了 diskpar.exe 的功能。refer)
2）对于 64 位的 Windows ，GPT(GUID Partition Table)类型的分区默认有 32M 保留区，MBR 类型的分区自动校准。不存在这个问题。这就是 64位 的 Windows 众多优点之一啊。
3) 对于 Linux ，fdisk /dev/{devicename} 然后进入 expert 模式, 然后输入 b ...
4) 对于 VMware，分为两种情况。虚拟机层（用虚拟机下操作系统的方案) 以及 ESX 服务器层 (fdisk).
上面几个步骤描述不详细，更详细的介绍你需要寻找一份白皮书： EMC CLARiion Best Practices for Fibre Channel Storage ，这个白皮书有针对 Flare 不同版本的，Flare 2.6 对这个问题有了比较好的改进。
是的，有的时候白皮书就在那里，只是没有人注意，没有看而已。
--EOF--
很早就答应了 Oracle 的 Jack Han 一件事情：为 OTN 中文技术网录制一份视频的讲座。因为种种原因，一拖再拖，搞到最后实在不想做了，自己感觉还挺惭愧，好在 Jack 也没怎么催促我。PPT 倒是修改了好几次，干脆放到网上来吧。
内容是关于 Oracle 安全的，其实最初的版本中的一些案例和示例倒是有些用途的，修改了之后觉得好像公关稿。
顺便整理了一下以前的一些技术文档:
最后，附送一个《丽塔·海华丝和肖申克的救赎》. 这部小说最早出现在 D 版《肖申克的救赎》碟片中。非常佩服翻译这部小说的人，我最近买了那本《肖申克的救赎》（四季奇谭)，那个翻译版本似乎就是照抄这个网上的这个版本。
--EOF--
等级界限森然,身分壁垒如山,权能使鬼推磨,势可令人成仙
--同事 Jametong 的 MSN 签名。这句话第一次在秦晖的文章《中国能否走出“尺蠖效应”的怪圈?》中看到
PayPal与谷歌的最大不同在于：谷歌希望招聘博士，而PayPal则希望招聘那些读到博士又放弃的人。这是两种完全不同的气质。
--曾经担任 PayPal 首席财务官的罗勒夫·巴萨(Roelof Botha)说
你是否不敢结婚，或不打算生儿育女? 孩子未来的教育费用是否让你忧心忡忡? 如果有任何一个答案为“是”，你就不算中产!
--这是日本人大前研一给出的中产标准
一个人的个人魅力大小取决于另一批无知者数量的多少
--带三个表《三个记录片》
该软件(瑞星2008防火墙)对网络的干扰和破坏力甚至大于很多计算机病毒。
--吉林大学网络中心发布的重要通知(来源)
翻看以前的 Twitter 记录，把这三句话检了出来：
GFW 第一定律：只要是 "用户产生内容"(User-generated content, UGC) 的国外网站都会被和谐。
GFW 第二定律：只要是被和谐的网站，国内一定会至少有一个克隆版。
GFW 第三定律：没有被和谐的网站一定不是同类竞争者中最出色的。
今天是几个月来非常郁闷的一天。是以为记。
--EOF--
现在是 SNS 的春天，最近又有消息传言新闻集团准备收购 LinkedIn。有趣的是，LinkedIn 也是 Paypal 黑帮 成员创建的。在最近一个季度，有两个 Web 2.0 应用我用的比较频繁。一个是Twitter，另一个就是 LinkedIn。
LinkedIn 的 CTO Jean-Luc Vaillant 在 QCon 大会上做了 ”Linked-In: Lessons learned and growth and scalability“ 的报告。不能错过，写一则 Blog 记录之。
LinkedIn 雇员有 180 个，在 Web 2.0 公司中算是比较多的，不过人家自从 2006 年就盈利了，这在 Web 2.0 站点中可算少的。用户超过 1600 万，现在每月新增 100 万，50％ 会员来自海外(中国用户不少，也包括我).
开篇明义，直接说这个议题不讲"监控、负载均衡”等话题，而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ，关键 DB 用的是 Oracle 10g。人与人之间的关系图生成的时候，关系数据库有些不合时宜，而把数据放到内存里进行计算就是必经之路。具体一点说，LinkedIn 的基本模式是这样的：前台应用服务器面向用户，中间是DB，而DB的后边还有计算服务器来计算用户间的关系图的。
问题出来了，如何保证数据在各个 RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。
第一个方式是用 Timestamp . 对记录设置一个字段，标记最新更新时间。这个解决方法还是不错的---除了有个难以容忍的缺陷。什么问题？就是 Timestamp 是 SQL调用发起的时间，而不是 Commit 的确切时间。步调就不一致喽。
第二个办法，用 Oracle 的 ORA_ROWSCN (还好是 Oracle 10g). 这个伪列包含 Commit 时候的 SCN(System Change Number)，是自增的，DB 自己实现的，对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度，当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂：增加一个 SCN 列，默认值"无限大"。然后用选择比某个 SCN 大的值就可以界定需要的数据扔到计算服务器的内存里。
ORA_ROWSCN 是 Oracle 10g 新增的一个特性，不得不承认，我过去忽略了这一点。我比较好奇的是，国内的 Wealink、联络家等站点是如何解决这个关系图的计算的呢?
--EOF--
一点题外话：我的 LinkedIn Profile (Mail : [email protected]). Keep in Touch!。 另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他~~
本周有幸听了阿里巴巴首席顾问关明生(Savio) 的一次演讲分享。记住了几句很有意思的话：
1）创新不是在"家里"发生的
2）今天最高的表现只是明天最低的要求
3）年轻人要的是前途，而不是钱途
这几句真的有"可意会不可言传"的那么一点感觉在内。当然，有意思的话往往不是绝对正确的。慢慢琢磨才有意思。
如果错过这次讲座，不妨阅读一下Savio 过去的一次演讲提要。内容或许类似，但是缺乏现场互动，怕是很难得到深刻的印象。比如同样是那个 “狗、野狗、小白兔、牛、明星” 的坐标系描述，不同的人就是能讲出来不同的理解来。
--EOF--
今天洋节是感恩节，嗯，要常感恩之心。
旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站"晒架构"也是个比较过瘾的事情。请参观并收藏这个页面：Architectures you've always wondered about。
eBay 的架构和去年相比基本是换汤不换药，倒是 Yahoo! 的 Ian Flint(这位老兄是 Bix 的运营总监. Bix 已被雅虎收购) 这个 PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思，披露了一些鲜为人知的信息。
Yahoo! 社区包括我们比较熟悉的 del.icio.us、Flickr、Yahoo!群组、Yahoo! Mail、Bix等。相当于 Yahoo！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。
有两点值得注意：1）层次化 2）模块化。这也是大规模作业下的比较经济的途径。
首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux，这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle，构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon（监控），还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于 Yapache，请参考我以前写的 Yapache-Yahoo! Apache 的秘密
这是 Bix 与 DB 有关的部署架构:
数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了)，通过快照复制到其他数据中心。
Yahoo! Mail 架构：
这里面居然部署了 Oracle RAC，用来存储 Mail 服务相关的 Meta 数据。非常有趣。
监控工具主要用的是 Nagios，用以监控集群。使用标准插件，另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo！自己 Y 字头的 Ywatch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo！的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。
应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。
Note: 上面所有截图版权都属于 Ian (Image COPYRIGHT@IAN) 。如果去看那个 PDF 文件，你或许比我收获更多。我只是让你知道我的想法而已。
--EOF--
每天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。
专门爆料网站架构的 Todd Hoff 对 Kevin Burton 进行了采访。于是我们能了解一下 Tailrank 架构的一些信息。每小时索引 2400 万的 Blog 与 Feed，内容处理能力为 160-200Mbps，IO 写入大约在10-15MBps。每个月要处理 52T 之多的原始数据。Tailrank 所用的爬虫现在已经成为一个独立产品：spinn3r。
目前大约 15 台服务器，CPU 是 64 位的 Opteron。每台主机上挂两个 SATA 盘，做 RAID 0。据我所知，国内很多 Web 2.0 公司也用的是类似的方式，SATA 盘容量达，低廉价格，堪称不二之选。操作系统用的是 Debian Linux 。Web 服务器用 Apache 2.0，Squid 做反向代理服务器。
Tailrank 用 MySQL 数据库，联邦数据库形式。存储引擎用 InnoDB， 数据量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些 多核模式下互斥锁的问题(This Bug?)。到数据库的JDBC 驱动连接池用 lbpool 做负载均衡。MySQL Slave 或者 Master的复制用 MySQLSlaveSync 来轻松完成。不过即使这样，还要花费 20％ 的时间来折腾 DB。
任何一套系统都离不开合适的 Profiling 工具，Tailrank 也不利外，针对 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是开放的。
Tailrank 的一个比较大的竞争对手是 Techmeme，虽然二者暂时看面向内容的侧重点有所不同。其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。从现在来看，Tailrank 离预期目标还差的很远。期待罗马早日建成。
--EOF--
Steve Wozniak 的自传名为 iWoz: Computer Geek to Cult Icon ，这个小写的 i 蛮符合苹果近年来的产品命名习惯。IJobs ，这个大写的 I 倒也比较符合一切以自我为中心的那个被神话的商业偶像 Steven Jobs。
Jobs 没有为 iWoz 这本书做序，看完这本书你会明白当然不是因为 Jobs "太忙了"(你会想象郭敬明给庄羽的新书写序麽?) Jobs 获得了苹果的大部分荣耀(虽然 Woz 并不在乎)，到今天怕是还有很多人认为是"他和沃兹"一起发明的 Apple I。老罗的那篇《关于苹果的老总》只是说了真话而已，从那个"设计电子游戏的活儿"的报酬的故事来看，老罗应该是看过 iWoz 这本书的。
整本书你不会找到沃兹对 Jobs 的一句坏话。但是沃兹对 "苹果 III" 的厌恶以及对 "苹果 II" 的喜爱足以说明一切。虽然沃兹说 "苹果III" 的失败的原因在于那是一个市场部门开发的产品，而不是工程师开发出来的产品，言犹未尽。我好奇的查了一下维基百科，有这样一段话：【Apple III的设计师被迫遵循乔布斯的极高和有时不切实际的要求，据说乔布斯觉得散热扇"不雅致"因而被省略了，结果导致电脑容易过热，这迫使最早期的型号被回收。】
Jobs 一毛不拔，Woz 乐施好善; Jobs 够 Great ，但并不是神; Woz 头上没有Jobs 那样耀眼的光环，而他才是仙！
(很多人非常推崇的 Jobs 在斯坦福大学毕业典礼的讲座，视之为经典，我跑到 YouTube 上看了看，Jobs 拿着稿子念来念去的感觉不到怎么牛，还不能证实那些话是不是都是他自己写的呢)
"你可以告诉记者或者政治家任何事情，他们都将深信不疑", 你可以告诉 Fans 任何话，他们都将深信不疑。在自传中沃兹澄清了一些事实：
关于 iPod 、iMac ，在 Jobs 返回苹果之前就已经在研发，而且主要设计师是 乔纳森·艾维, 只是 Jobs 的重返苹果容易让人产生"他一回来，这么牛的产品就有了"的错觉--谁知道是不是 Jobs 故意为之呢?
苹果不是"车库创业"的公司，更为准确的说是"宿舍创业"的公司, 沃兹强调了这一点。
沃兹掏钱举办的是 US Festival 音乐节，而不是 WoodStock 。(这可能只是自己长久以来的错误记忆)，真正的 一掷千金(千万美金)。
顺便说一下，这本书的中文版副标题为 "一段硅谷和苹果的悲情罗曼史"，恶俗到家，而且和原书的主旨南辕北辙。沃兹有必要"悲情"麽? 一个视金钱如粪土的人有必要悲情麽? 一个一心要给五年级孩子做电脑课教师的 IT 英雄有必要悲情麽?
--EOF--
国内媒体还是很快的，关于 Paypal 黑帮 的话题现在已经遍布各个新闻站点了，虽然对照该文英文版来看，中文版本漏掉了不少信息。
为什么会形成 "Paypal 黑帮"? 公认的一个原因应该是那是在美国硅谷，而不是中国的中关村。要有那样的土壤才会产生那样的生命。
中文版的翻译者自做主张的加上了个章节叫做“为何成为创业者摇篮”，可是读完了那一段发现并没有解决这个问题。没错，Thiel 和 Levchin 只招聘跟他们一路的人，用 Web 2.0 行话来说，就是他们只用自己的 "SNS" 圈子的人，这样的确会让这个团伙彼此产生深厚的友谊。缺钱? 缺人脉? 创建新公司的最主要的两个问题在这个圈里不是问题。
为什么会形成 "Paypal 黑帮" ? 我认为最主要的还是 Thiel 的开放性管理风格下的公司管理信息开放使得这些家伙都"学会"了如何成为企业家。Thiel 把“客户记录、营收流、欺诈损失、以及资本支出等方面的数据” 公之于每个员工，耳濡目染大家也能学会公司运转是怎么回事了吧? 换了另一家公司能做到麽? 比如那个被神化的 Google 能做到这样麽?
若干年后或许就像曾经的 Palo Alto 研究中心那样，人们在感叹那些商业 Geek 的时候也会想起 Paypal。
--EOF--
虽然我所服务的公司性质和 Paypal 很类似，但是我却从来不知道榜样 Paypal 的背后故事，而且一直以为 Paypal 被 eBay 收购之前是个很低调的公司。FORTUNE 杂志的这篇 The PayPal mafia 比较成功的勾勒出 Paypal 前公司成员的'帮派'。虽然'旁观者'张亮认为这不过是"过时的自我标榜"，我还是认为这篇文章很让我震惊。
(refer)
eBay 收购 Paypal 之后，Paypal 干将一窝蜂似的离开。短短几年间，"Paypal 黑帮"的成员控制的商业规模有 300 亿美金，几乎多数明星 Web 2. 0 公司都和这个"帮派"有关，或是投资，或是创建者。我的天！Facebook. YouTube, Flickr, Yelp, LinkedIn, Geni, Digg, Flickr, Last.FM, Mozilla, Ning, Technorati, Kiva,Joost.....长长的一串
每个成功的企业都有独特的基因，文章中用了不小篇幅描述 Paypal 的招聘原则：只招聘和自己相像的人。Paypal 的基因似乎就是"反主流"，"Google 雇佣博士，而 Paypal 招聘那些读到博士又弃之的人"。这一群臭味相投的人在一起，倒也无愧于 "mafia" 这个标题。黑帮哪有不火拼的? Paypal 和 X.com 合并后的内斗就好比 "火拼王伦": Musk 要把系统迁移到 Windows 平台上(这想法真不是一般的糟)，结果引起 Paypal 黑帮众怒，群起攻之，Musk 卷了铺盖。
"Paypal 黑帮"主要成员介绍(每个人还真是黑帮打扮，笑死). 下一个"黑帮"会出现在哪个公司呢?
--EOF--
我必须要说，这是我今年看过的最差的 SNS startup ，尤其这还是软件巨头 Oracle 弄出来的。为了验证我所言不虚，请登陆 Oracle MIX. 这 UI 啊...
此前，Oracle 低调的推出了官方 Wiki, (友情提示,可能会经常的打不开该页面)。在 SNS 如此火爆的今天，卖水的也都开始甩开膀子准备下场掘金，最起码，也要把自家院子里的金子挖一下不是?
--EOF--
Yahoo! 和 Carnegie Mellon 大学合作的开源分布式计算项目代号为 M45，这个 超级计算集群 有 4000 个处理器，3T 内存，1.5 PB 存储空间，自称足以跻身世界超级计算机 50 强。这两天网络上搜索最火的一个词应该就是 Hadoop 了吧? 雅虎的这套集群就是跑在 Hadoop 上。
Hadoop 现在已经有很多不错的应用案例可以参考，比如这篇 Running Hadoop MapReduce on Amazon EC2 and Amazon S3
Yahoo! 或许早意识到自己的 Web 1.0 方式下的计算能力比 Google 差的太远，干脆放手一博，助力 Hadoop 项目，期望能借助开源的力量与 Google 掰一下手腕。从这里我们得知 Yahoo! Hadoop 团队早在 06 年就成立了，当然，这个团队成立的前提是 Doug Cutting 入职雅虎。
雅虎现在不应该担心追不上 Google ，应该担心 Doug Cutting 别被 Google 挖去，否则，可真的没机会了。
--EOF--
国内 Web 2.0 网站的代表之一豆瓣网的用户正式突破 100 万，祝贺豆瓣团队！如果一个国外的 2.0 站点拥有百万用户的话，估计会有 N 多巨头来谈收购了。国内用户的价值就不值钱麽? 是的，的确是这样。不过豆瓣在用户的心中是最有价值的。
或许今天才算是 Oracle 11g 正式发布。因为各平台的都可以下载了。非常喜欢 收购的 Oracle 为什么不干脆把 Quest 收购算了? 或许这样才能把 Quest 那款非它不可的软件价格降下来。当然，Quest 也不是吃素的，也会玩收购，把提供虚拟桌面环境解决方案的 Provision Networks 收购了。
--EOF--
IBM 为配合 Power 6 CPU 而推出的 AIX 6 即将正式发布。在 AIX 5 的基础上学习 AIX 6，最好的入手点就是 IBM AIX Version 6.1 Differences Guide（PDF) 了。匆匆看了一下，记录几个比较感兴趣的点。
关掉 JFS2 的 Log: mount 的时候 log=NULL 可以关掉 JFS2 的日志。在一些特定的场合(如：恢复)会比较有用。另外一个特性是内部快照(internal snapshot)，即可以在同一文件系统上创建快照。
在以前的版本中这是做不到的，AIX 6 可以通过静态或者动态的方式修改每个进程的线程数量。属性由RLIMIT_THREADS 与 RLIMIT_NPROC 值控制. ulimit -a 可以查看值。
pthread 也就是 POSIX Threads，AIX 6 对 "contention scope" 的 m:n 做了调整。
AIX 5 上 跑 Oracle RDBMS, Oracle 建议 export AIXTHREAD_SCOPE=S. 看来以后不用这么费事了。
补充一下这个 M:N ，一共有三种:
这个变化多少了反映了 IBM 在计算模式变化的方向上的倾斜。
AIX 6 支持四种值，4k、64K、16M、64GB. 一个新的需要知道的缩写：Dynamic variable page size support (VPSS)。VMM 可以动态修改 Page size ; 大的 page size 对应用是透明的(是不是会触发Bug，鬼才知道); 硬件支持(Power 6)的情况下 VPSS 是激活的。
AIX 6 对一些比较关键的参数划了个类别：”限制性可调“(restriccted tunables) ，调整的时候会警告用户, 建议在厂商指导下进行:)
安装程序更新了，现在是......图形化安装了
--EOF--
财帮子(caibangzi.com) 定位在”基金理财社区"。是国内访问量最大的基于 Ruby on rails 的 startup 项目。“理财”这个词据说是光大银行发明的，且不去管，不可否认的是，目前国内"理财"是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。
创建者有三人。Robin Lu(石锅拌饭)、Meng Yan ( 孟岩 ) ，还有一位"不写Blog的家伙"。前两位都是技术人员。很早就看过孟岩 的 Blog，那时候他还在 Sun。Robin Lu 的 Blog 也一直在我的订阅列表中的，所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也是工程师，叫赵路，曾经是 Mozilla 项目accessibility模块的module peer."
Web 服务器用的是 Lighttpd ，出于节省成本的目的，服务器是自行组装的。数据库采用的是 MySQL 5，目前还没有使用 Replication. 正准备扩充服务器，服务器数量...暂且保密一下。
统计分析采用 Google Analytics 和 Awstats 。目前 Alexa 排名是 2 万一点。监控工具用 monit，"以及自己写的一些分析 Proc 的脚本"，再有就是 Unix 性能工具等。(Fenng: 服务器处于规模化之前基本上要这个样子)。
Robbin 在此前的一篇 财帮子性能优化简报披露：“财帮子两个星期以前，遇到严重的性能问题，最终我们采用了相当非主流的部署方案和打了自己补丁的web server，成功度过了难关”，我很好奇这具体是个什么问题。得到的答案是：“Apache的负载均衡是有问题的，算法太简单了，对Ror的应用来说，会造成某一个app instance的阻塞，从而阻塞了所有的request”。
谈及 Cache 的感慨:
Fenng: ... 我个人感觉你们需要Cache服务器， 这一类的站点内容需要 Cache 的太多
Meng Yan: ...Web 2.0网站的 cache 非常重要。我们从Mem的cache，到disk的cache，
再到数据库的cache，架构还不错，否则当前机器撑不住 :)
Fenng: 很多站点扩展作不好，也是Cache没用好
Meng Yan: 是啊，Cache非常重要，非常非常
Fenng: 豆瓣的阿北说他们 Memcached 用的非常爽，命中率非常之高
Meng Yan: 确实，我们的内存cache就是用的memcached，真的很棒
Fenng:还要采访你一个问题：caibangzi.com 现在运营、开发面临的最大的一个问题是什么?
Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。
这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线，到现在已经积累了一定数量的用户，当然不是十全十美的(我个人就感觉应该提供更多的RSS输出才是，不要太在乎站点流量，流量本身也是开销)，网站也还有很长的路要走。真诚希望财帮子能成为更多人的理财工具(至少我已经开始用了)。
这是我第一次写国内 Web 2.0 网站架构技术。感谢 Meng Yan 提供的第一手信息。关于网站架构，我在这个 Blog 上写过不少国外的站点分析。一直想采访一些国内的 Web 2.0 站点并且能披露点技术信息，相对来说，国内站点还是比较保守，各自闷头折腾。为什么不换个角度，分享、借鉴、壮大，这个方式不也不错麽?
BTW: 如果你有 Web 2.0 站点技术信息要报料，联系我！(要写软文就免了)。
--EOF--
每个周六，如果没有事情出去的话基本要在电脑上做两件事情，一是看看《南方周末》等报纸杂志的电子版，二是看看最近 BT 来的一些电影。
今天很有幸，又看了一部烂片子《葬礼揸Fit人》(《龙头葬礼》)。港产电影的剧本似乎可以好几家共用的，这个《葬礼》和最近的那部《兄弟》大情节有很多相似之处。导演也不说考虑一下大陆观众，“揸Fit人"这词谁懂啊？查了半天才知道大致是“话事人”、“总瓢把子”的意思。演员莫名的神经兮兮，情节也莫名的不合常理。看港产片子容易产生审美疲劳，翻来覆去就是那几个演员，本片居然看到了好几个还不那么熟悉的面孔，扮演兄弟的那个貌似林志颖，表演那不是一般的生硬，下次建议导演来大陆招几个演员算了。
说烂片有烂片的看法，主要是里面的一些场景和台词挺有意思。来参加葬礼的世界各地老大，无论哪个人怎么看都不像个老大的样子，倒好象来香港的游客跑了个龙套。那个帮会是"红“字头的，那个兄弟，叫做“家宝”，帮会老大去世后，下面的兄弟们准备”选举“；四个老头子自持资格老，开始底气很足，没过一会儿就临阵倒戈，这些似曾相识的情节会让人联想许多。记得的台词有：”一个人是斗不过社团的，社团斗不过政府，政府最大"。
接下来看疑似烂片的《神枪手与智多星》，第一句记得的有趣台词是：
时代进步了，黑社会不能再存在了
--帮会老大校长深沉的说
烂片的另一个作用是消磨时间
--EOF--
国内数据库技术牛人, Oracle ACE Fangxin Lou 自行开发的 AUL 最近有了一次比较重要的升级：支持压缩表。有趣的是，据他自己说是经过了 20 分钟的发呆 想到的解决方法。很多人都知道 Oracle 的 DUL(Data Unloader) 是数据恢复的最后一招，一般来说是密不可宣的，一旦给用户恢复数据则代价昂贵，而 AUL 则平民化了许多，虽然不是开源的，但是国内用户如果使用的话，基本还是不收费用的(功能还毫不逊色)。
Lou 最近也作了一次 AUL/MyDUL发展历史回顾, 这个工具都三岁了。难得的是坚持，这一点我很服气他。
关于 AUL 更多信息可以参考他为推广 AUL 而做的 英文 Blog
--EOF--
BTW: 鲜果上我的BLOG验证代码: BANG1F1D675F0C335CE77C173BA6XIANGUO
对于 eBay ，我盲人摸象一样写了好几篇 Blog ，暂列一下：
今天又重新读了一下这篇《The eBay Architecture --Striking a balance between site stablility, feature velocity, performance, and cost》，觉得数据层的扩展经验也很有意思。
通过功能划分不同数据库，然后根据主要访问路径水平分割数据库。这句话太空了，类似 MySQL DB 大家常采用的 Shard 思路。
数据库上没有业务逻辑。这包括：不用存储过程; 只有少量比较简单的触发器。
把CPU 开销比较高的工作迁移到应用上。这包扩：参考完整性检查(嗯，检查一下你的 DB 是否再用外键? ); 连接(Join), 排序。
应用服务器尽量 Prepared 语句以及绑定变量的广泛使用。
自动提交(Commit)大多数主要的数据库写操作。 客户端绝对没有事务(业务逻辑) 。这包括: 单个数据库通过匿名 PL/SQL 块进行事务管理; 没有分布式事务。对于"事务", 相关信息可以从 eBay 首席架构师 Dan Pritchett 的访谈得到确认。没有事务更没有分布式事务这一点比较关键，这也是因为 eBay 的商业逻辑天然性质(否则也不容易做)，所以可以做到 Scale Out，而最近了解到 Paypal 则因为交易逻辑比较复杂，只能是 Scale Up. Paypal 的技术信息一向比较封闭，谁能告诉我一点额外的信息呢?
--EOF--
Oracle 10g 开始 引入了AWR (Automatic Workload Repository). Oracle 建议用户用这个取代 Statspack。不过这个需要注意的是使用 AWR 需要有 Diagnostic Pack License。Oracle 后来推出了一个解决方案可以禁止掉该特性。
在 Note. 436386.1 有说明:
SQL> @dbms_awr.plb然后执行：
dbms_awr.disable_awr();
如果用 sys 之外的用户创建 AWR 报告，则需要进行合适的授权。否则会报告错误 PACKAGE 执行错误。
CONNECT / AS SYSDBA;
GRANT ADVISOR TO foo;
GRANT SELECT_CATALOG_ROLE TO foo;
GRANT EXECUTE ON sys.dbms_workload_repository TO foo;
要注意 Bug 4597354 在创建基线数据的时候，对性能有很大影响。在一个非常繁忙的系统上不要进行此操作。
如果结合企业管理器用 AWR 是很方便的，如果用手工方式收集性能数据，多了很多可供调整的地方，是更加方便了呢？还是更加麻烦了?
--EOF--
昨天已经约好了今天集团几个 DBA 到上海与盛大的同行进行技术交流。今天还算起的早，到创业大厦楼下等同事。大门口已经热闹非凡，红彤彤一片。很多同事在那里摆 Pose "敲上市钟"，还有很多排队买纪念品(接下来还有抽奖活动，没我的份儿了)。差 5 分钟 9:30 ，我们出发了 -- 没看到宣布上市那一刹那的沸腾场面。
一下午都在盛大参加讨论，盛大作为游戏厂商的领头羊，运维技术自有独到之处，讨论气氛也比较热烈，当然这一天下来也比较累。在盛大的园区用手机拍了几张照片(出大门的时候看到陈天桥领着一群人进来参观)。晚上住的地方......别说了，堪称今年出差最差的一次。一个有趣的插曲是，吃完晚饭出来，我们几个看到路边有卖DVD的，Biti 买了一张《色戒》，小贩告诉他是香港影院录下来的枪版.....路上 Biti 说"如不是，肯定打车回去找那个小贩"。结果，经过仔细检验，结论是100%的国内影院录的枪版。
晚上回来，看看新闻，市场反应出乎大多数人的预料。好多人对财富榜开始津津乐道，好多旧故事、旧的细节又被翻了出来，有些我都快能背下来了。这一天就过去了。
嗯，2007 年 11 月 6 日，阿里巴巴 B2B 业务香港成功上市!
--EOF--
很多人问我雅虎有没有可能在搜索领域赶上谷歌，我明确地回答--没有，因为雅虎不可能专注在这个领域。有时，一个好的公司不能完全按华尔街的意愿办事
--Google 吴军
支持方言编程!
--在 Twitter 上有人讨论到"汉语编程"这个笑话一般的话题. Yining 干脆来个荒谬到底.
大唐今天倒闭，我们明天就能用上3G
--网友 xlight 针对明白了大唐 3G 为啥不行的留言.
辞职完全属于员工自愿，没有公司强迫行为。绝大部分员工会通过竞岗回到原来的岗位
--华为回应媒体报道的"华为让万人辞职、重新签订合同"事件
抄一段独白：
该死的
整整一代人都在当加油工、招待员或者白领奴隶
广告诱惑我们追逐汽车和时尚
于是我们拼命工作
买那些没用的狗屎
我们是被历史遗忘的一代
没有目的、没有地位
没有世界大战、也没有经济大萧条
我们的战争就是心灵的战争
我们的生活就是经济大萧条
我们看着电视
相信有一天我们会成为百万富翁、影帝或是摇滚明星
但是
我们不会
这就是我们渐渐面对的现实
所以
我们真他妈的被激怒了
Twitter 是我最近一段时间用的最多的网络服务之一.还记得刚开始有段时间发消息速度那叫一个慢. 难得的是 Twitter 的开发者在用户激增的情况下性能提升的不错, 据说,相比当初有 100 倍的性能提升, 那我们就来看看他们都做了什么.(发现我这个 Blog 快成了 High Scalability 的中文镜像站了.)
是否真的是 100 倍性能提升, 大可不必较真, 但 Twitter 的一些经验是足以借鉴的.
似乎 Twitter 是用 RoR 开发的流量最大的站点(有待于求证). 开始使用DRb ("Distributed Ruby".), 该库可以通过 TCP/IP 从远程 Ruby 对象发送接收消息, 其缺点是不那么好用,并且没有冗余, 于是转向 Rinda , Rinda 基于 DRb 开发, 使用简单. Twitter 也证明了 Ror 应用同样可以支撑比较繁忙的站点, 工具没有对于错,关键是否能运用好.
图片来源. (这里面我非常疑惑的一点是据说只有两台DB(Master/Slave),可要支撑这么大的并发更新似乎有些难度.)
Twitter 对于Etag 的态度让不少人疑惑. 这恰恰是因技术制宜的一个体现, 因为 Etag 不是万能药. 另外一点比较重要的原因是 Twitter 有超过 90% 的流量来自 API, 而 多数 API 客户端不支持 Etag.
尽可能的索引(Fenng补充:不要过度索引). 因为 RoR 应用的特殊性, 索引是在代码中向 DB 提交的. 另外一个值得议题的是, 反范式. 严格遵守范式是要吃苦头的.建立可行的测试方法,明确的知道你的SQL都在用什么方式运行.(另外,我有个疑问是 rails 不支持 2 阶段提交的吧?)
哪个站点都不避免的有"水葫芦用户",对于这样的 Spam 类型用户, 肯定会影响原有的应用处理资源. 该处理就要处理掉. 另一个方面,对于间歇性占用系统资源过多的进程用 Monit 处理.
另外一个很重要的环节是 Cache, 不废话了,没有好的Cache机制怕这样的站点不会成功的. (建议阅读车东辛苦翻译的这篇面向站长和网站管理员的Web缓存加速指南[翻译]). Twitter 运营的一个可取之处是能够积极听取社区的意见并改进, 同时社区上也有很多用户给他们提供了不少技术支持. 这也是开放而带来的好处吧.
--EOF--
维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。
来点直接的数据：
架构示意图如下：
Copy @Mark Bergsma
在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? "A 40-line patch for BIND to add geographical filters support to the existent views in BIND", 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的--面向各个国家，各个地域。
WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.
Lighttpd 现在成了准标准图片服务器配置了。不多说。
维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。
MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。 复制、读写分离......应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。
运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。
参考文档：
Wikimedia architecture （PDF)
Todd Hoff 的文章
--EOF--
奥运购票网站据说刚上线就瘫痪了，听说而已，没有亲见。奥运会这种"钱多人傻"的项目，自是财大气粗，听说购票系统所用的存储都是花费人民币千万级别的，即使花了大钱还是没办好事，遭到批评也是活该。
开始说是因为网络负载导致瘫痪，后来又辟谣说，“主要还是系统后台的数据库的处理能力，在设计、规划方面，还有待于改进”
那我们实际看一下具体数据。“票务系统已经做了多次压力测试，票务系统每小时将能处理3万张门票的销售(另外又说：三个售票渠道共同能够处理的售票能力是每小时15万张），以及承担每小时100万次以上的网上浏览量。”，这算下来，也就是每秒钟处理不到 9 个交易请求，平均每秒钟 278 个点击(这也难怪百度李彦宏唏嘘一把: 不要说800万次，就是每小时8000万次，对百度来说，也只是a piece of cake)，这真是一个非常业务指标非常低的系统了。整个系统启动后，系统一个小时涌进来 20 万订单，其实平均每秒钟不过 56 个交易请求罢了。如果把问题推到数据库身上，还不如把问题推到开发人员数据库水平上。
抛开技术限制，门票的销售策略也让人觉得很傻，难道就不能一次只售一种项目的票麽? 先售那些比较冷门的项目分流一下访问压力，是很简单方便的真实压力测试。这只是奥运 IT 体系建设的第一次公共亮相，不由得让人担心其他方面的健壮性。
回头说李彦宏的自大。每小时 8000 万次，一天就是 19 亿 的 PV，百度能有多少? 雅虎也不过是 40 亿PV而已。就别小菜一碟了，再说这只是 PV，如果加上事务量，那是更难搞的。
对比一下国内比较大的交易网站，中国彩票协会的数据：
营收35,000,000元/日(博彩业钱真好赚）, 目前系统每天交易笔数50,000,000笔,峰值处理4000笔/秒
这种压力估计还有的一搞。
--EOF--
Updated: 有人说其实是临时工的错，很有道理
看到一篇十分有趣的关于 DBA 的帖子。10 种迹象表明你的 DBA 该退休了. 作者是 Chris Muir. 这 10 条越看越好玩，翻译并注释一下。
1. Complains about these "new fangled stored procedures".
对"存储过程这新玩意儿"抱怨不停。 (暗示这个人还停留在 Oracle 古老版本的使用经验中。)
2. Rants about the good old days of Oracle PE (Punchcard Edition).
嚷嚷着 Oracle 卡片机版本(暗指非常古老的版本)美好时光.
3. Thinks Thomas Kyte is a whipper-snapper (even with the beard).
认为 Thomas Kyte 是个傲慢自大的年轻人(即使他有胡子). Kyte 现在已经是几个孩子的父亲了。而且，近年来 Kyte 在 Oracle 领域已经成为无可争议的大师级别的人物。 (暗示有这样想法的人可能 N 年前见过 Thomas Kyte, 近年来没关心 Oracle 社区的发展)
4. Still demands all Oracle manuals in hardcopy.
仍旧靠着所有打印的 Oracle 手册过日子. (现在的手册足有 几万页, 说明还是用的老手册, 而且守旧)
5. Has a service request with Oracle Support to forward port the RBO to 11g.
对 Oracle 支持人员提出一个 把 RBO 移植到 10g 的服务请求。(RBO--基于规则的优化器, 局限性非常大，已经不适合现现在复杂的数据环境了，如果还死抱着RBO大腿不放...)
6. Knows about Edgar's secret 13th rule.
知道 Edgar 的第十三条规则的秘密。(Edgar Codd，就是大名鼎鼎的关系数据库理论之父，他提出的基本准则只有 12 条。如果有 DBA 知道第十三条规则的秘密...)
7. Thinks Oracle Support went downhill when they moved the HQ to Redwood Shores in 1989.
认为 Oracle 支持自从1989年总部搬到 Redwood Shores 后每况愈下。(看看 Oracle 各个版本的 Bug 众多，以及 Oracle 服务费的昂贵，从哪个角度来看，Oracle 支持都是不差的，当然服务质量除外)
8. Has [email protected] in his address book.
邮件地址簿里有 [email protected] 。(RSI 是Oracle公司前身，[email protected] 是 Oracle CEO 拉里－艾里森的邮件地址。还有这个邮件地址，估计至少有 20 年没更新过地址簿了。这个人有些"火星")
9. Still replaces blank lines in PL/SQL with single line comments.
仍旧在 PL/SQL 用单行注释替换空行.(这个需要解释一下，用手册上的话就不用绕了: You cannot use single-line comments in a PL/SQL block that will be processed by an Oracle Precompiler program because end-of-line characters are ignored. As a result, single-line comments extend to the end of the block, not just to the end of a line. In this case, use the /* */ notation instead)
10. Has an open 10 year old Oracle Support "TAR" to fix a bug in version 7 which he/she wont close because of the "principal of the thing."
在 Oracle 支持上开了一个长达10年之久的 "TAR"，要修复某个 Oracle 7 的Bug，并且坚持认为此乃"首要之事"而不肯关闭该 Tar。(刻舟求剑)
等有时间再写写那些该下课的 IT 经理人
--EOF--
