GoAgent(Google App Engine) + 火狐 + Autoproxy 翻墙自由上网

Google App Engine 是一种让您可以在 Google 的基础架构上运行您的网络应用程序。Google App Engine 应用程序易于构建和维护,并可根据您的访问量和数据存储需要的增长轻松扩展。使用 Google App Engine,将不再需要维护服务器:您只需上传您的应用程序,它便可立即为您的用户提供服务。 GoAgent就是一个能运行在Google App Engine上的代理程序。 创建Google App Engine的app后,上传GoAgent服务端到Google App Engine上,即可实现用Google的服务器为自己开代理。 配合火狐 + Autoproxy来翻墙,灰常爽。 1 . 注册Google账号(已经有的跳过) http://accounts.google.com

memcached 使用(perl)

这大体上可以看出,服务器端口缓存技术。 memcached 官方:http://www.danga.com/memcached/ 安装前,先安装 libevent 其上为 linux 软件一般安装,看他们readme文档 $>memcached -d -u nobody -m 512 127.0.0.1 -p 11211 如果有异常, ln -s /usr/local/lib/libevent-1.4.so.2 /lib/libevent-1.4.so.2 参考 http://blog.chinaunix.net/u2/70049/showart_1665279.html 我这就使用 perl 语言了, 其他语言参考 http://code.google.com/p/memcached/wiki/Clients perl 使用 cpan> install Cache::Memcached ;#会使用 perl 我就不说了 代码说明:不停对 key 为test 的值进行递增 #!/bin/perl -w use Cache::Memcached;  my $memd = new Cache::Memcached{servers => [‘127.0.0.1:11211’] }; my $key = ‘test’; $memd->add($key => 1,3600) or warn ‘Alread added’; while(1){ print $memd->get($key),”n”; $memd->incr($key) or warn ‘FAIL!’; }

LINUX下查看CPU负载的vmstat命令

$ vmstat procs ———–memory———- —swap– —–io—- –system– —–cpu——page——-disk——-faults rbw                       avm-fre                        … procs r 列表示运行和等待cpu时间片的进程数,如果长期大于1,说明cpu不足,需要增加cpu。 b 列表示在等待资源的进程数,比如正在等待I/O、或者内存交换等。 cpu 表示cpu的使用状态 us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期大于50%,需要考虑优化用户的程序。 sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%,如果us+sy 大于 80%说明可能存在CPU不足。 wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%,如果wa超过30%,说明IO等待严重,这可能是磁盘大量随机访问造成的,也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。 id 列显示了cpu处在空闲状态的时间百分比 system 显示采集间隔内发生的中断数 in 列表示在某一时间间隔中观测到的每秒设备中断数。 cs列表示每秒产生的上下文切换次数,如当 cs 比磁盘 I/O 和网络信息包速率高得多,都应进行进一步调查。 memory swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0,或者比较大,比如超过了100m,只要si、so的值长期为0,系统性能还是正常 free 当前的空闲页面列表中内存数量(k表示) buff 作为buffer cache的内存数量,一般对块设备的读写才需要缓冲。 cache: 作为page cache的内存数量,一般作为文件系统的cache,如果cache较大,说明用到cache的文件较多,如果此时IO中bi比较小,说明文件系统效率比较好。 swap si 由内存进入内存交换区数量。 […]

Node.js 究竟是什么?(what's that mean?)

简介: Node 是一个服务器端 JavaScript 解释器,它将改变服务器应该如何工作的概念。它的目标是帮助程序员构建高度可伸缩的应用程序,编写能够处理数万条同时连接到一个(只有一个)物理机的连接代码。 如果您听说过 Node,或者阅读过一些文章,宣称 Node 是多么多么的棒,那么您可能会想:“Node 究竟是什么东西?” 即便是在参阅 Node 的主页之后,您甚至可能还是 不明白 Node 为何物?Node 肯定不适合每个程序员,但它可能是某些程序员一直苦苦追寻的东西。 为试图解释什么是 Node.js,本文将简要介绍一些背景信息:它要解决的问题,它如何工作,如何运行一个简单应用程序,最后,Node 在什么情况下是一个好的解决方案。本文不涉及如何编写一个复杂的 Node 应用程序,也不是一份全面的 Node 教程。阅读本文应该有助于您决定是否应该继续学习 Node,以便将其用于您的业务。

在MongoDB中实现乐观并发控制

说起来,自从接触了MongoDB以后,我在大小项目中就再也没有 接触过关系型数据库了。性能倒不是什么主要问题,主要是方便,例如我可以在MongoDB中直接保存数组,然后把其中的元素当作查询条件,而在关系型数据 库中,则需要使用额外的表格,然后再JOIN等等。当然,在MongoDB中很难进行JOIN,于是对于某些场景下会略显麻烦,但在记忆中我似乎真没什么 束手束脚的情况。这方面我还没有仔细分析,可能MongoDB支持保存复杂对象会有所帮助吧。以上都是废话,这里我简单谈一下如何在MongoDB中实现乐观并发控制。当然加入您对MongoDB的功能都有所了解,那么这种做法也是十分显而易见的。 简单地说,“并发控制”便是避免在并发环境下某条记录被错误地覆盖。例如在一次“读取”、“修改”、“提交”的事务中,除非进行合理控制,否则可能 其中某次提交的数据就遗失了。所谓“悲观”并发控制,则意味着在某次事务的“开始”和“提交”之间不会出现任何“读取”操作(即这条记录被锁定了),这自 然不会有问题。而乐观并发控制,则保证的是在某次“读取”和“提交”之间没有进行任何“提交”操作,否则便会提交失败,于是当前事务便会重新从“读取”这 个最早的步骤开始。此类概念(或者说并发处理方式)在许多地方都有体现,例如在普通的并发编程中,lock就近似于“悲观”并发控制,而“软件事务内存”则类似于“乐观”并发控制。 如果要在普通的关系型数据库里实现乐观并发控制,我们一般需要为其加上一个额外的Version字段,它是整型,也可能是个时间戳。在更新某条记录 时,我们将这个字段的“旧值”作为UPDATE语句的条件之一,同时这个字段也会写入新的值。如果这次更新影响了某条记录,那么表示更新成功,反之则表示 这条记录已经被删除,或是在“读取”和“提交”之间遇到了其他提交操作。在SQL Server中存在一个Timestamp类型,这个类型的字段会在记录修改时自动更新。 在MongoDB中的做法也没有太大区别,只是它的update语句并不会返回它所影响的记录数,于是我们必须额外进行一次查询,例如文档上所记载: > t.update({_id: 1, version: 3}}, {$set: {Content: “New Content”, version: 4}}); > db.$cmd.findOne({getlasterror: 1}); {“err”:, “updatedExisting”: true, “n”: 1 , “ok”: 1} // it worked > t.update({_id: 1, version: 3}}, {$set: {Content: “New Content”, version: 4}}); > db.$cmd.findOne({getlasterror: 1}); {“err”:, “updatedExisting”: false, […]

CTO谈豆瓣网和校内网技术架构变迁

罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。洪强宁,2002年毕业于清华大学,现任北京豆瓣互动科技有限公司首 席架构师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活品质,在网站架构、性能、可伸缩性上进行深入研究。豆瓣网曾获软件中国2006年度 最佳技术应用网站。

参考的文章–又拍云实战

今年秋天,加入猛买之后,遇到的第一个挑战就是图片托管。当时,网站流量快速增长,原有服务器几次增加带宽依然无法满足需求,流量常常跑满。现在回头总结一下,像我们这样的小公司,自己维护静态资源服务器大致有这些不爽: 峰值带宽决定大部分成本 如果峰值带宽在20Mb,那就得买20Mb,哪怕在凌晨只有几百Kb。 运维的成本不可忽视 除了买带宽,还得时时处处留意服务器运行情况、网卡流量、安全状况等,也需要持续投入。 单机达不到CDN的功效 虽然我们用的机房速度和稳定性都不错,但毕竟是单机,无法保证全国各地的访问速度。 后来,我通过@Fenng联络到了@gofeeling和又拍,正赶上又拍云处在最后测试阶段,我们成了又拍云第一批用户。又拍云(以下简称为UpYun)恰好为我们解决了上面的问题。 按需付费,带宽需求再高,也只需要按流量付费,据粗略计算成本低至原先三成; 抛开运维负担,如不放心,配置几个URL监控即可; CDN不再是问题,不同地区的用户都能享受到最好的访问速度。 在两个月的使用过程中,UpYun确实出现过2次不稳定的状况,但又拍同学们都很及时地解决了。正式上线后,稳定性极佳,到目前为止可用率高达100%。 这篇文章主要是从用户的角度谈谈UpYun的特点和使用技巧,让对UpYun感兴趣的朋友们更好地了解这个平台,可以加深了解,更好地使用它。UpYun目前提供的是文件存储+CDN的服务,可以认为是AWS的S3+CloudFront,但实际用起来,有些细节上的不同。 0、与众不同的Bucket 和一般云存储服务提供的Bucket不同,UpYun中的Bucket分为文件类和图片类。文件类Bucket可以存放任何文件;图片类Bucket仅能存放图片文件,妄图上传其他类型会被拒绝。每个Bucket都可以绑定多个域名。 1、文件增量同步 使用第三方服务托管静态资源,都会有文件同步的需求。那么,放在主服务器的文件,如何同步到UpYun呢?又拍官方提供了两种方式:FTP和API。API功能强大,但是需要做开发,目前还没人开发出类似s3cmd这样的工具;FTP命令功能有限,想用原生的几个命令辗转腾挪实现sync很费劲(不切实际地想,如果支持rsync就好了)。 我们在实际使用时,利用了lftp的mirror命令,通过FTP协议实现了文件增量同步。再配合crontab,就能做到定时增量同步了。这样既避免了投入精力围绕API做开发,又能达到rsync的效果。下面是一个脚本示例供参考: #!/bin/bash HOST=”v0.ftp.upyun.com” USER=”username” PASS=”password” LCD=”localpath” RCD=”remotepath” lftp -c “open ftp://$HOST; user $USER $PASS; lcd $LCD; cd $RCD; mirror –reverse –delete –dereference –verbose –exclude-glob=*.php”

Buddy框架图片文件云存储模块实现

去试试又拍云存储的服务http://www.upyun.com/,就去注册然后申请试用了。 本次upyun.com的认证方式很让我意外,竟然是客服打电话过来确认,这点服务感觉还是挺好的,从这里感觉还是蛮重视用户的。特别要说的是,今天是星期天我又在这里宣传upyun.com的服务,就和同事说了下,结果他去注册了,竟然在半小时后就接到了客服人员的电话了,感觉这个确认还是很及时的,体验很好,这点感觉还是很不错的。 试用就开始吧,为什么要试用又拍云存储服务呢?这里我做归纳补充下: 1,图片服务器的托管及运维费用挺高的,而且峰值带宽觉得了大部分成本,且运维的软硬成本增大 2,单机达不到CDN功效,需要CDN支持的话,花费就更大了 3,图片的处理及图片的缓存,需要配置nginx的静态缓存图片,需要做系统设计扩展图片类的保存图片及缩略图功能 4,图片的备份,对于图片的备份是个问题需要用rsync同步到备份机器,添加了运维成本和开发成本  基于以上原因,自己开发及部署图片服务的代价还是很大的,所以这个也是极力推荐使用又拍云存储www.upyun.com的原因了,至于大家说的upyun.com是否稳定,磊哥提到的猛买网用了2个月还是没问题的,我也相信@gofeeling和又拍的技术实力的。 如何申请及开通就请详细参看磊哥的博文吧,本篇主要更细致化的讲解技术实现。 首先,设计表结构 id,filename,desc,createtime,status,remoteurl,url,model,user_id 本次主要用到的字段有 filename 及 model 构造图片的访问地址 $staticUrl / $model / $filename 例如: http://img001.img.woshimaijia.com/user/testuser.jpg 考虑到图片表可能进行分表,这里的id使用了 17位的bigint 时间递增