民工架构师 —— 网站收件箱架构设计

前言

一般来说,国内服务器空间都非常小,我租的一个400m的,一年就要500多元。对于我这种没收入无业游民,如果要租个大服务器,那么太奢侈了。。。就更不要说自己架设服务器了。

穷人穷办法,民工架构师就为您讲解一下我在实战中实用的廉价架构。

文章目的

采用最低廉的方式,实现最高性能的网站收信箱架构。

正文
一般来说,我的网站设计都是能够容纳最少1w人以上。

可以试想一下,每个人每天发1条信息、收1条信息、回1条信息,那么数据库每天就要增加3w的数据。加上一些提高性能的缓存设计,一个穷人租的服务器怎么受得了。。

再想下,一个用户想在自己收件箱搜索下某人的信件,等于数据库在百万数据中查找一条没啥用的数据。

最后再想下,一个用户发一条信息,内容却几乎有1M的废话,数据库读出来都费力了。

所以,用简单的建表+搜索不能够作为网站收件箱架构设计的。(有钱人不要看,您用Oracle+X核服务器的,我没钱只能感叹。。)

解决方法主要3点(先声明下,我先自己想出来了,后来才发现原来豆瓣也用了类似的思路)

1. 把文本放在单独的服务器,本服务器仅用索引去引用信件文本,这样能够最少提升90%的性能(我瞎掰的,希望有人能验证下)。这个所谓的单独服务器,实际上就是当今web2.0的一些网站提供的API,例如picasa/google spreadsheet/还有我曾经发表的Editgrid(有兴趣可以读读:http://www.cnblogs.com/zc22/archive/2009/08/03/1537224.html

2. 每个用户的信息列表用文本保存,当然这个文本有一定的命名规则。首先文件的名字是用户个人信息主键的映射,比如MD5,这样用户读取个人信息的时候仅仅需要做一次映射,就获取了文本。其次,文本内部使用了单链表结构(数据结构很重要哦),因为当用户的信息增加的时候,文本之间通过单链表能够实现无限扩展。

3. 数据库仅仅保存一些用户设置、时间戳等。

通过这3点,基本上网站的收件箱不会影响到服务器的性能。用户所有关于信息的操作全部在内存执行,然后通过缓存保存在了服务器的文本文件。
文本文件读写不用搜索,直接用MD5就可以一次映射找到。

后记
如有有哥们想喷下我,我先自我保护下。我后来偶然的机会读取了豆瓣的服务器架构设计,他们就是采用了一种Chord环设计(请参考麻省理工大学MIT的关于P2P论文),这种设计的精华就是我上面说的3点。他们把大文本、图片存储在单独服务器,然后核心服务器通过索引引用了外部大文本。而索引又使用了Chord设计,把搜索的复杂度降到了非常低。
原文地址:https://www.cnblogs.com/zc22/p/1541594.html