Twitter 的性能问题

尽管最近又拿到了一笔风险投资，但 Twitter 似乎遇到了中年问题，前几天居然因为一台 DB Crash(原因是居然是连接数过多!）而导致禁止了很多关键功能。接连几天，服务都是及其不稳定。或许是 DB 崩溃问题带来的雪球效应吧。因为这一系列问题的困扰，用户怨声载道，Twitter 倒是做了”改进”: 开辟了一个子站点用于即时报告各项服务的状态问题。值得称道的是，Twitter 开发 Blog 上回答用户的技术询问倒是很端正的态度。

现在技术问题成了 Twitter 进一步发展的极其严重的制约了，在所有的 Web 2.0 站点里这倒是比较少见的。尽管 Twitter 过去号称把性能提升了 100 多倍，看来还不够哇。前一段时间，有小道消息说 Twitter 准备放弃 RoR ，倒是 Twitter 忙不迭的辟谣。

面对很恼火的用户，Twitter 也承认架构上的一些问题，”Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system” ，而最初的架构也是面向内容管理系统而不是消息系统的，这需要一个转变过程。一直让我比较奇怪的是 Twitter 似乎没有专门的 DBA ，而是开发工程师兼任，如果 MySQL 不是瓶颈倒没问题的(有很多 Web 2.0 大站就不用专门 DBA 的)，可如果 DB 是瓶颈，那就比较麻烦了。DB 如此，其它环节也是如此。

有意思的是，随着互联网应用的飞速发展，Performance Engineer / Scaling Engineer 这样的新职位需求都出来了。这是个有挑战的活儿，值得尝试一下。

实在无聊，这只是一篇随笔罢了。

–EOF–

eBay 的Scalability最佳实践

用什么来衡量一天没有白过? 可能看到一篇好文章能算做一个条件。infoQ 上的这篇 Scalability Best Practices: Lessons from eBay 会让每个架构师都比较激动的。

过几天估计 infoQ 中文站就翻译这篇文章了，所以只记录一点自己的想法好了。在其中的 7 个实战经验中，每一条都值得写篇学习笔记，我比较关注面向 DB 的几条。

水平切分

对于 eBay 这样个头的大 Web 应用，如果数据不能分片，就无从谈及扩展。这个话题我之前描述过一点，文章中提及数据库层的切片要比应用层复杂许多，我想其中最大的一个难点就是不同用户之间的关联数据问题吧，否则就完全可以根据用户范围或者群体划分到不同的 DB 上。现实的应用总是如此复杂，让每个架构师都早生华发啊。

避免分布式事务

其中提到的前 Inktomi 工程师 Eric Brewer 提出的 CAP 定理： Consistency (C), Availability (A), Partition-tolerance (P) ，最多能同时选择两个。三个不能同时实现。对于 eBay ，选择的是 A 和 P，牺牲了一致性，而通过系统的其它手段(比如事件系统)来追回事务的完整程度。BTW: 这次倒是没有提及 BASE :)

虚拟化所有层次

这样做的目的是为了达到编程上的方便以及运营操作的灵活性。通过 eBay 的 O/R 层实现了对数据库的虚拟化。这样应用程序开发者无需关注数据存在哪里的。

Cache

其中提到了 Cache 的应用场景：针对缓慢改变的数据、只读为主的数据、元数据、配置信息和静态数据等。把握这个原则是很关键的。我个人就看到有病急乱投医的设计者把数据一股脑的扔进 Cache，潜在的麻烦很难消除。

强烈推荐大家直接点过去看一下该文。

补充：关于 BASE。
Basically Availble
Soft-state
Eventual Consistency

–EOF–

虾米音乐网

由几位前同事秘密打造许久虾米音乐网明天正式上线测试了。虾米是干啥的? 比较官方的描述是 “P2P音乐分享平台” ，站内有篇360度全面了解虾米(登录才可以访问)，我个人的看法是 “Last.FM + P2P”。对于音乐源，永远有”种子”。这一点能弥补当前很多音乐站点的缺陷，至于版权问题如何解决，你登陆后就知道了。

去过虾米的办公室，这帮家伙本身就是铁杆乐迷，对于互联网存在的各种模式也研究比较透了，所以，虾米的玩法总有些与众不同之处，当然这也要看网站的发展和用户的接受程度了。祝他们好运!

虾米的主要技术包括：基于 P2P 技术的娱乐媒体传输和提供用户良好的娱乐享受，及从分享中的获利。采用跨平台的 C++ 技术进行 Linux（服务器）和 Windows（客户端）的技术开发，服务器侧重于高性能和并发性，客户端侧重良好的用户体验和用户媒体习惯数据的采集。

小道消息: 他们在招聘(简历发给我即可)
Windows程序员

1. 精通或熟悉C++，能熟练使用VC，熟悉网络编程(Socket，完成端口)和UI界面(SDK，GDI，GDIPLUS)编程，了解P2P技术尤佳；
2. 熟悉面向对象，STL，ATL等C++语言层面的技术；
3. 熟悉多线程编程；
4. 熟悉SQL编程；
5. 能熟练查阅英文编程资料(如MSDN) ；
6. 对互联网行业充满热情和兴趣，具有优秀的学习能力，喜欢音乐者尤佳。

高级Windows程序员

1. 精通C++，能熟练使用VC，精通网络编程(Socket，完成端口)和大并发的服务器架构设计。对P2P技术有深入研究者尤佳；
2. 精通面向对象，STL，ATL等C++语言层面的技术。熟悉boost，loki等模板库者尤佳；
3. 精通多线程编程；
4. 精通或熟悉SQL编程，熟悉MySQL，SQLite者尤佳；
5. 能熟练查阅英文编程资料(如MSDN)，具有良好的编程规范并能指导他人；
6. 对互联网行业充满热情和兴趣，乐于助人，喜欢音乐者尤佳。

PHP 工程师

1.两年以上互联网应用开发经验；
2.熟悉PHP.MYSQL.LINUX.Apache.Janascript.AJAX；
3.有大型网站架构、系统优化，SEO工作经验优先；
4.熟悉各种PHP框架优先。
5.喜欢音乐优先。

目前虾米音乐网还要邀请才能注册，我有几个注册名额，基本用没了。还记得我说过的 Paypal 黑帮的故事么? 新的黑帮已经形成规模…

–EOF–

LinkedIn 架构与开发过程

关心 Web 2.0 的朋友对于 LinkedIn 应该都不陌生。我这个 Blog 上以前也介绍过 LinkedIn 的架构信息。最近, LinkedIn 公司的两位工程师在 JavaOne 上做了两个分享。揭示了更多 LinkedIn 架构方面的技术信息。

1) LinkedIn – A Professional Network built with Java Technologies and Agile Practices

这是我看到的 Web 2.0 公司中第一个完全拥抱 SOA 的。这个文档中大致描述了 LinkedIn 开发过程上的一些经验。

| View

News Service Architecture 对于国内鲜果这样的 RSS 工具网站或许能有点参考价值。另外一个值得注意的地方是架构的变迁，随着业务的增长，后端 DB 的变化非常明显。

2) LinkedIn Communication Architecture

这一篇中描述了几次迭代经验，其思路值得借鉴。

| View

其中提到了对 CLOB 字段的更新认识。我个人的建议是：不到万不得已，还是别在 Web 应用中用 CLOB 了。

–EOF–