现在的位置: 首页 > 综合 > 正文

关于短网址系统的一点看法

2013年10月27日 ⁄ 综合 ⁄ 共 2264字 ⁄ 字号 评论关闭

声明:该文属于自己的一点点看法而已,仅供娱乐参考,勿喷。转载请标明:http://blog.csdn.net/lywybo

 

微博的短网址系统大家应该都不陌生吧。具体短网址是干嘛的,为什么要有短网址,我就不罗嗦了,不知道的直接google就成。

sina短网址域名是http://t.cn 腾讯短网址域名是http://url.cn

 

短网址的组成:

不说废话,只看sina和qq的,其他的忽略,毕竟实现起来有N种方法。sina和qq的都是域名+key的形式

key值目前由六位组成。每位62个字符(0-9,a-z,A-Z)。

 

 

很多人分析短网址系统就会说,先MD5或者其他的hash,然后各种与、各种或得出几组值,选其中一组即可。

 

我觉得有这种思路的人一般都是看到4gBOjY 、39qdlG 这种类型,就会联想到md5的结果的一部分,所以就用尽各种方法给扯到了md5的结果上,不是说这样做不妥,只是觉得可以有更好的方案。

 

 

6位62个字符,那么总量是固定的600多亿,也就是说短网址,不管你用啥子hash生成,只能生成600多亿个,只能存600多亿条网址。既然总数都是固定的,那么干嘛每次存一个新网址的时候要先生成MD5然后在把MD5包装过来包装过去得到一个6位的key呢,本身MD5就会碰撞,你缩到6位碰撞不就更厉害了么,重复了咋办呢?

直接来个62进制每次加一不就行了么,反正容量是固定的,hash过来hash过去有意思么?

 

短网址的特点:

1.短。key值仅6位、域名也很短

2.对于已经缩略的网址,直接返回已有的key

3.没有收录过的网址,会生成一个唯一的key表示

 

 

第一组测试

16:35  http://weibo.short.url.test.com/lywybo              http://t.cn/aN6Go5

16:38  http://weibo.short.url.test.com/blog/lywybo      http://t.cn/aN6Gry       与上个相比,表明是有序的

16:39  http://www.sina.com.cn/lywybo/csnd/blog        http://t.cn/aN65Y4       与上两个相比,表明有序不是因为同个域

16:39  http://www.baidu.com                                       http://t.cn/h5mwx        与上三个相比,表明已有的,直接返回key值

 

 

第二组测试

 

http://t.cn/aN65Y4 (我发的)   ---------->    http://www.sina.com.cn/lywybo/csnd/blog

http://t.cn/aN65Y3 (应该是别人新建的微群,才1个人。。。。截图时间和上面那个接近)

截图时间:16:41

说明不只你有序,别人和你一样,有序。

 

结论:综上所述,新浪的短网址是有序的。

 

 

废话说了那么多,终于进入正题了,说下我认为短网址的实现方式

我认为。。。。短网址系统,直接用(0-9,a-z,A-Z)组成的62进制数,不停累加就行了,新浪目前应该就是这么的实现方式。

存储格式:key--url--MD5

aaaaaa--http://www.baidu.com/1---MD5

aaaaab--http://www.baidu.com/2---MD5

aaaaac--http://www.baidu.com/2---MD5

aaaaad--http://www.baidu.com/2---MD5

 

key可以存一组索引,用于通过key访问转换url

MD5(hash)可以做一组索引,用来检测url是否已经被缩略过.

上文提到MD5会碰撞,重复的时候直接将碰撞的url读出直接比对即可。。。(这个时候不要忘记做记录log啊,因为你发现了新大陆了。。。)

 

数据的存储方式:

不推荐数据库存储,量大了之后不分库、分表,效率太低。分库、分表成本都太高了。还是直接像搜索引擎一样文件存储比较自由

 

比搜索引擎索引更简单的一点是:这个索引建立了之后不用更新的,一直往下存就是了,假设一条记录1K,都可以计算出需要使用多大的容量(还是很小的几块硬盘的事),索引的存储,类似搜索引擎切词后索引的分割做法,对索引在做索引。

其实可以将这种存储定性为双索引的小文件存储系统(key值顺序索引、MD5索引)

对于热门的url,直接LRU缓存起

 

扩展性:

当626满了怎么办呢?

1.key扩充到7位。。。

2.其他程序什么都不用变继续62进制,只是key值长度变长了。。。。

 

疑问:

可能有同学会问了,为嘛就一定会key变到7位啊?

那我就想反问一个,谁规定微博的key值一定是6位的?其实http://t.cn 本身就比 http://url.cn 少一位呢。也就是在新浪微博同样发带url的微博时候,你比qq微博可以多发一个字。

新浪微博

腾讯微博

 

回归到为嘛选6,因为6位的话就是600多亿,它足够大,短时间内用不完。。。貌似google索引网页的量也就一两千亿吧(查不到准确数据)。

所以用6够了。

为嘛不用5,因为用5的话就是10亿,小了点不是很靠谱。。。

为嘛不用7,用7就少一个字(新浪就是比腾讯多了一个字,所以现在比腾讯火。。。哈哈,开玩笑),等6满了在用7也不晚。

 

最后的期待:

1.期待http://t.cn/iloveu 的产生

2.期待6位key值耗尽的那天。。。。

抱歉!评论已关闭.