分类归档: Arch

Twitter 的性能问题

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

down_time.gif

现在技术问题成了 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–

延伸阅读：Twitter 在自救

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

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
ACID_BASE.png
–EOF–

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

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 开发过程上的一些经验。

SlideShare | View

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

2) LinkedIn Communication Architecture

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

SlideShare | View

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

–EOF–

Linux 服务器可用性技巧关注与积累

好多 Windows 平台的 DBA 一定比较烦操作系统升级时 “重启动才能生效” 这个问题，可能就是因为这个原因，可能没多少人愿意管理 Windows 平台的数据库。其实 Linux 有的时候也有类似的毛病，对 Kernel 打 Patch 基本也要重启动操作系统，除非你不去理它。而最近 Slashdot 一则关于 Linux 的新闻值得关注， Ksplice: Rebootless Linux kernel security updates，对于非常关注系统可用性的 DBA 来说，这是个很关键的技术改进。

提高可用性技术，前期细致周密的规划是重要一环。比如大文件系统的 fsck 问题，默认情况下达到一定 mount 次数或者超过一定时间，系统会自动启动 fsck 检验操作。而一个运行一段时间的 Linux Server 如果崩溃 reboot 后，文件系统校验时间漫长的叫人绝望。如果最初对这个问题进行预处理，即可避免不必要的停机时间。

另外维护中能尽量积累那些”可用性高”的技术或技巧也是必不可少的。比如 Kernel 重新读取分区表的问题，Fdisk 命令是搞不定的，而这里提到的 partprobe 命令 刚好派上用场。

以前我也记录过类似 Linux 如何不重启而识别新增的 LUN 的话题，积少成多，也就有用了。

–EOF–
Updated: