Monthly Archives: May 2008

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 .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

虾米音乐网

xiami_logo.jpg
由几位前同事秘密打造许久虾米音乐网明天正式上线测试了。虾米是干啥的? 比较官方的描述是 “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 开发过程上的一些经验。

SlideShare | View

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

2) LinkedIn Communication Architecture

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

SlideShare | View

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

–EOF–

Linux 的 Out-of-Memory (OOM) Killer

同事在 Linux 服务器上遇到点小问题，我也上去折腾半天。这还是第一次注意到 Linux 这个多年来就存在的特性：OOM Killer 。说白了 OOM Killer 就是一层保护机制，用于避免 Linux 在内存不足的时候不至于出太严重的问题，把无关紧要的进程杀掉，有些壮士断腕的意思。

先要学习点老知识，在 32 位CPU 架构下寻址是有限制的。Linux 内核定义了三个区域：

# DMA: 0x00000000 -  0x00999999 (0 - 16 MB) 
# LowMem: 0x01000000 - 0x037999999 (16 - 896 MB) - size: 880MB
# HighMem: 0x038000000 - <硬件特定>

LowMem 区 (也叫 NORMAL ZONE ) 一共 880 MB，而且不能改变(除非用 hugemem 内核)。对于高负载的系统，就可能因为 LowMem 利用不好而引发 OOM Killer 。一个可能原因是 LowFree 太少了，另外一个原因是 LowMem 里都是碎片，请求不到连续的内存区域【根据我遇到的一个案例，一个猜想是 有些应用一次性请求比较大的内存，恰恰又是 880M 之内的，空闲的(LowFree)不够大，就会触发 OOM Killer 出来干活】。检查当前 LowFree 的值：

# cat /proc/meminfo |grep LowFree

检查LowMem内存碎片：

# cat /proc/buddyinfo

上面这条命令要在 2.6 Kernel 环境下有效。据说使用 SysRq 的方式更好，不过 Hang 的时候再用吧。参见 Metalink Note:228203.1 。

根据一些文档描述，OOM Killer 在 2.4 与 2.6 上表现是不一样的。2.4 的版本中是把新进来(新申请内存)的进程杀掉。而 2.6 上是杀掉占用内存最厉害的进程(这是很危险的，很容易导致系统应用瘫痪)。

对于 RHEL 4 ，新增了一个参数： vm.lower_zone_protection 。这个参数默认的单位为 MB，默认 0 的时候，LowMem 为 16MB。建议设置 vm.lower_zone_protection = 200 甚至更大以避免 LowMem 区域的碎片，是绝对能解决这个问题的(这参数就是解决这个问题出来的)。

而对于 RHEL 3 (Kernel 2.4) 似乎没什么好办法，一个是用 Hugemem 内核(天知道会不会引入新的毛病)，一个是升级到 2.4.21-47 并且使用新的核心参数 vm.vm-defragment 控制碎片的数量。再就是使用 RHEL 4 (Kernel 2.6)，这又绕回去了。说白了，如果遇到 OOM Killer ，基本上是低版本 Kernel 设计上有点缺陷。

其它，如果去查询 RedHat 的 Bug 库，会发现不少 Kernel 版本也有 Bug 的。尤其在使用 NFS 的场景。

Tip: OOM Killer 的关闭与激活方式：

# echo "0" > /proc/sys/vm/oom-kill 
# echo "1" > /proc/sys/vm/oom-kill

更多参考信息:

–EOF–

头疼欲裂，零散记录点东西，备查。