坚信科学,分享技术

2018全新版本,未来在blog.54chen.com更新博客!

>>>尝试更加利于阅读的2014版科学院,以后都在新版上写。

Category Archives: 架构研究

大负载网站架构相关的研究记录。

类似google big table的tokyo cabinet研究记录

Tokyo Cabinet是日本人开发的一款数据库,它的功能比较简单,只能键值保存,没有检索功能,以hash table、b+tree、fixed-length array保存。功能类似google的Bigtable的东东。 这套Tokyo系列有三个产品,Cabinet是数据库,Tyrant提供管理Cabinet的接口,Dystopia提供全文索引。我把Cabinet理解为存储引擎,Tyrant类似mysql的管理器,Dystopia则是插件。 Tokyo Cabinet有如下特点: 键值保存数据库 数据文件小 高性能,插入1百万记录只需0.4秒(250万 rps),查询1百万记录只需0.3秒(300万 rps) 高并发,支持多线程,读写支持锁记录 使用简单,通过memcached客户端直接使用(需Tyrant) 支持64位架构,容量大 支持事务 Tokyo Tyrant提供管理Cabinet的接口,支持memcached协议,所以,可以通过memcached客户端连接Cabinet。 Tokyo Tyrant有如下特点: 提供使用Cabinet的接口 支持通过memcached和http协议连接 高并发,查询100万记录17.2秒(5.8万 rps) 支持热备份,复制功能,主持主主(可读写)和主从(分写和读)方式 Tokyo Dystopia是一个全文检索系统,你可以搜索包含某短语的一系列记录,它的特性如下: 搜索的高性能。 目标文标的高可靠性 N-gram模型的高召回率 短语匹配,前缀匹配,后缀匹配搜索.

Continue reading

Posted in 架构研究 | Leave a comment

[原创]使用postgreSQL+bamboo搭建比lucene方便N倍的全文搜索 第二部分

[文章作者:陈臻 本文版本:v1.0 最后修改:2009.7.17 转载请注明原文链接:http://www.54chen.com/_linux_/postgresql-bamboo-lucene-part2.html ] 书接上回。上回说到建立好一整套的中文分词和pgsql的环境,这回来说如何搜。 一、基础篇 本回从一条sql开始: select * from dbname where field_name @@ 'aa|bb' order by rank(field_name, 'aa|bb'); 从这个sql字面意思讲解:从 dbname这个表中查field_name匹配aa或者是bb的词,并且按照他们的匹配的RANK排序。 基本上明白上面这段话后,来学习四个概念:tsvector、tsquery、@@ 、gin。 1.tsvector: 在postgreSQL 8.3自带支持全文检索功能,在之前的版本中需要安装配置tsearch2才能使用。它提供两个数据类型(tsvector,tsquery),并且通过 动态检索自然语言文档的集合,定位到最匹配的查询结果,tsvector正是其中之一。 一个tsvector的值是唯一分词的分类列表,把一话一句词格式化为不同的词条,在进行分词处理的时候,tsvector会自动去掉分词中重复的词条,按照一定的顺序装入。例如 SELECT 'a fat cat sat on a mat and ate a …

Continue reading

Posted in linux, 架构研究 | Tagged , , , | 6 Comments

一个把TortoiseSVN转成命令行的svn的bat脚本

TortoiseSVN是windows里常用的svn客户端了,有些IDE(比如说Zend Studio)要设置svn.exe的地址才能绑上svn来用,一般情况下,他附带的都是很古老的版本。 把下面的脚本保存为svn.bat,再在ide里设置svn客户端为这个bat文件,很好用 @ECHO OFF rem This is a svn for IDE rem from http://www.54chen.com start "TortoiseSVN" "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /notempfile /command:%1 /path:%2

Continue reading

Posted in 架构研究 | Tagged , | 2 Comments

[原创]使用postgreSQL+bamboo搭建比lucene方便N倍的全文搜索 第一部分

[文章作者:陈臻 本文版本:v1.2 最后修改:2009.7.7 转载请注明原文链接:http://www.54chen.com/_linux_/postgresql-bamboo-lucene-fulltextindex.html ] 修正:一些“--”(连续的两个杠)被转成了全角的“-”(一个杠)了,运行不过的试试-变成-- 所有用到到包有: cmake-2.6.4.tar.gz (编nlpbamboo用) CRF++-0.53.tar.gz(同上) nlpbamboo-1.1.1.tar.bz2(分词用) postgreSQL-8.3.3.tar.gz(索引用) 安装pgsql tar -zxvf postgreSQL-8.3.3.tar.gz cd postgre-8.3.3 ./configure --prefix=/opt/pgsql make make install useradd postgre chown -R postgre.postgre /opt/pgsql su - postgre vi ~postgre/.bash_profile 添加 export PATH PGLIB=/opt/pgsql/lib PGDATA=/data/PGSearch PATH=$PATH:/opt/pgsql/bin …

Continue reading

Posted in java, linux, 架构研究 | Tagged , , | 12 Comments

[原创]Discuz! BBS缓存整体方案

[ 文章作者:陈臻 本文版本:v1.0 最后修改:2009.6.22 转载请注明原文链接:http://www.54chen.com/c/611 ] DZ的缓存方案是经典之作,不论是系统的主动缓存还是帖子内容的被动缓存。在我前面的博文【[原创]Discuz! BBS的主动缓存和被动缓存】里所讲述的是DZ的缓存常用的一种方法,下面再说在DZ系统里如何决定一个内容是不是要缓存。 所有的数据全都缓存,不失为一个好办法。但是,在数据更新要求及时的环境下,例如帖子回复的内容要求立即显示等地,又不得不对其缓存进行更新。所以,基本上每一个成熟的系统,都不会去把所有的东西缓存起来。这时是不是让各位很困惑,缓存就是一把双刃剑,用好了系统效率事半功倍,用得不好,产品功能将受到严重影响。DZ就是一个缓存与不缓存选取得当的系统。 我们一起进入DZ的viewthread.php,也就是负责显示帖子内容的一个文件。代码一开始有这样一个判断: $page = max($page, 1); if($cachethreadlife && $forum['threadcaches'] && !$discuz_uid && $page == 1 && !$forum['special']) {        viewthread_loadcache(); } 这是什么意思呢?基本上就是在说,当一些系统的设置都满足的时候,只要是第一页就去执行viewthread_loadcache(),各位已经等不及看这个函数的意思了吧,且慢,先说说为什么选中了第一页

Continue reading

Posted in php, 架构研究 | Tagged , , | 5 Comments

twitter api 中文文档 [前言][515更新]

[ 翻译:陈臻 本文版本:v1.1 最后修改:2009.5.15 转载请注明原文链接:http://www.54chen.com/c/591 原稿:twitter wiki 完成2%] 前言 (每个开发者在开始使用api前都必须知道的概念) 开始使用api前必读 (细读这一节,你将掌握大多数经验丰富的开发者知识) 【不知道为什么,这一节的内容在wiki里被人删除了】 每一个开发者都必须知道的事情 (每个twitter api开发者都必须知道的基础知识) 0)FAQ的内容 当你开始开发的时候,熟悉FAQ的内容并且知道问题所在。 1)twitter其实有两份api 目前twitter api存在两个分立的版本。大部分的开发者都混用这两份api来完成开发。将REST和Search的api分离是不理想的,完全是由于历史原因。如果开发周期允许的话,我们打算合并REST和Search的api完善之。api预览里的前言部分说明了这段历史。 2)你不能无限次地调用 api的使用频率是有限制的。你可以阅读《我们有个雷管》(这个名字好雷哦)来学习下。 3)此api是完全基于HTTP的 从twitter api检索数据的方法需要发送GET请求。提交、修改或者删除数据使用POST请求。DELETE请求也是可用来删除数据。如果你没有使用正确的方法请求数据,使用特殊HTTP方法的api就返回一个错误。HTTP的返回(有链接)是丰富多彩的。 4)此api是RESTful的源 twitter api企图确保按照REST的原则来设计。只需要简单修改你请求的扩展上的格式就可以取到你所指定的格式。本文档指明了对每

Continue reading

Posted in 架构研究, 资料文档 | Tagged , , | 10 Comments

[原创][整理]校内网CTO黄晶讲述网站架构变迁-54chen回忆版

[文章作者:陈臻 本文版本:v1.1 最后修改:2009.4.13 转载请注明原文链接:http://www.54chen.com/c/539 ] 这是一次公司内部的交流会,主题是校内的发展史和构架讲解,主讲人是校内网CTO黄晶,其中关于架构变迁的一段个人觉得是很具有代表性的过程,特在会上作了大概的笔记,现在是凌晨一点不到,正好清醒头脑进行回忆总结。 每个网站的发展都会按照一个大致相同的路线去完成,当然这里说的是每个相对成功的网站。 第一阶段: 这一阶段没有太大的访问量,甚至只有一台服务器就搞定了所有的访问。DB和前端的代码全都在一起,压力不高。忆者注:我觉得在alexa没进五万的时候,只要不是特殊的应用,基本都在此列吧。 第二阶段: 网站初具规模,DB压力大增,单独的一台DB已经满足不了现在的访问量,开始考虑读写分离的Master-slave库,使用三个及以上的服务器。忆者注:这时网站的alexa基本上会在1-3万的位置,每天的ip在5-10w的样子,当然,DB我们都认为是MySql。 第三阶段: 访问量继续增加,增加到了DB的压力在Master的机器上非常的明显了,Master开始出现吃不消的情况,出现写耗尽。主从也已经不能满足要求,需要进一步解决负载问题,此时要引入Mysql Proxy程序,进行中间层代理,实现负载均衡,易于扩展。忆者注:这时网站已经不可限量了,先恭喜下你的网站能用到这段。 第四阶段: 网站继续发展,进而出现了数据量的成倍增长,原来的N台DB都出现了一个问题,数据量巨大,无法完成正常速度的读写。此时,需要对网站按功能进行垂直划分,比如用户注册登录是

Continue reading

Posted in 架构研究 | Tagged , | 10 Comments

手机之家新系统介绍及架构分享

上周听小兄弟blankyao介绍说手机之家有个技术交流会,忙着搞校内的群组,一时没在意,这周看了dbanotes冯老大的文章才知道爆了不少料,挺不错的交流会,没去后悔了。附会议ppt,转自 http://dbanotes.net 手机之家新系统介绍及架构分享 View more presentations from Fenng Feng. 很遗憾没能在现场提问,细细看完整个ppt,基本上了解了整个DAL的想法,一直都在思考去弄一个这样的东西,始终都有瓶颈,对于DAL的构思没有什么想法,总结一下,没有看出我遇到的问题的解决方案,列出一下: 1.DAL能解决多维度的数据在高负载下的瓶颈吗?有什么方案?多维度:比如说豆瓣的群组,假设一个人有10W个组,每个组里有100w个人,如果应用要求列出每个组的人和每个人的组,只用一份数据,DAL+缓存能搞定吗? 2.如果只是靠硬件来撑DB的访问量,那DAL和DBproxy或主从DB的优势在哪里?

Continue reading

Posted in 架构研究 | Tagged , | 13 Comments

[原创]Discuz! BBS的主动缓存和被动缓存

[文章作者:陈臻 本文版本:v1.1 最后修改:2009.3.16 转载请注明原文链接:http://www.54chen.com/c/505] DZ的缓存同样分了主动缓存和被动缓存。从功能上来说,主动缓存一般用到管理员对全站的设置,等等需要手动更新的地方,这些地方的数据都有一个特点,那就是它们的更新可能性很小,平时不需要自动更新;DZ的被动缓存,一般分布在诸如帖子内容显示,用户信息更新这些地方,这些地方的更新基本上都是因为用户使用了某一特定的功能时所激发的。 在正常运行的DZ系统文件夹里面会有一个forumdata文件夹,这个是论坛记录和缓存文件的存放目录,一般这些文件都是自动生成的,在forumdata/cache/里面存储的都是一些DZ的基本设置和一些常使用的值,这些值一般在系统初始化的时候就保存在$_DCACHE全局变量中,在后面的操作中将可以简单地使用它们进行功能上的判断。 (1)主动缓存,也就是只在用户操作后台时,由DZ系统去删除原有缓存进行更新的缓存。它们普遍存在于forumdata/cache/目录中,比如说/forumdata/cache/cache_settings.php保存了整个系统的核心设置,一般情况是不会更新的,只有后台修改了比如站点名称等关键信息的时候才会去主动更新这个缓存文件。还有用于保存用户组和管理员组相关信息的两类缓存文件: /forumdata/cache/usergroup_'.intval($groupid).'.php /forumdata/cache/admingroup_'.intval($adminid).'.php 另外还有

Continue reading

Posted in php, 架构研究 | Tagged , , | 6 Comments
Page 7 of 7« First...34567