Tag Archives: Arch

InfoQ 对我做的视频访谈: 数据库架构

前段时间 阿里巴巴网络侠客行大会上,我提到 InfoQ 对我做了个视频采访,现在这个采访已经可以访问了。

这是个人第一个成功发布的视频访谈。去年 Oracle Open World 的时候, IT168 非要作采访,结果牺牲了两个会议时间,折腾完后再也没看到关于那个视频的消息。

说实话,采访之前自己还是比较担心效果的。这次 InfoQ 的采访效果比我的预期要好多了,因为现场发挥的地方比较多,有口不择言的时候,还望读者朋友海涵。

赞一下 Infoq 的几位朋友(泰稳、Jason、X5)! 和他们合作很愉快。我身边的很多同事都认为 Infoq(中文站) 是国内最好的技术信息站点。接下来,还有对我另外一位同事的采访(比我更为重量级)即将发布,我在采访现场听了都很过瘾。敬请期待,绝对不忽悠 :)

EOF

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