岭南六少 – 一朵在LAMP架构下挣扎的云

原文：http://robbinfan.com/blog/43/rid-off-dotnet-experience 在互联网行业，基于Unix/Linux的网站系统架构毫无疑问是当今主流的架构解决方案，这不仅仅是因为Linux本身足够的开放性，更因为围绕传统Unix/Linux社区有大量的成熟开源解决方案，覆盖了网站应用扩展的方方面面。 我记得十几年前第一波互联网浪潮的时代，

原文：http://qing.blog.sina.com.cn/2244218960/85c41050330031zq.html 系统架构是一个工程和研究相结合的领域，既注重实践又依赖理论指导，入门容易但精通很难，有时候还要讲点悟性，很具有“伪科学”的特征。要在此领域进阶，除了要不断设计并搭建实际系统，也要注意方法论和设计理念的学习和提炼。 经常有同学询问如

原文链接： http://cdc.tencent.com/?p=7162 UIDesigner是腾讯用户研究与体验设计部（CDC）设计研发的一款设计类软件，打造一款可以让设计师统一平台和团队协作的平台型设计工具，经过1.0和2.0版本的经验沉淀，我们决定对3.0版本进行全新的架构设计。 开发一个软件系统，前期的架构设计承载着整个软件的设计思想和关

The C10K problem 编写连接数巨大的高负载服务器程序时，经典的多线程模式和select模式都不再适用。应当抛弃它们，采用epoll/kqueue/dev_poll来捕获I/O事件。最后简要介绍了AIO。 网络服务在处理数以万计的客户端连接时，往往出现效率低下甚至完全瘫痪，这被称为 C10K问题。随着互联网的迅速发展，越来越多的网络服务开始

从Linkedin和Iron.io抛弃ruby说起 最近半年关于Ruby编程语言最负面的两条新闻莫过于2012年10月的报导：Linkedin从ruby迁移到node.js，30台服务器减到3台，以及2013年3月的报导：Iron.io从ruby迁移到Go，30台服务器减到2台 node.js和Go都是最近两年服务器端高并发编程的热门语言，Linkedin和Iron.io抛弃Ruby迁移之后，都获

原文链接： http://www.aqee.net/how-we-went-from-30-servers-to-2-go/ 我们开发第一版的IronWorker已经是3年前的事了，是用Ruby写的，API基于Rails开发。我们没用多久就发展成了相当大的规模，很快我们就触及到了 Ruby 程序的承载上限。长话短说，我们切换到了 Go 语言，请接着读下去，下面是事情如何一步步发

好几个地方看到这个 Facebook – Needle in a Haystack: Efficient Storage of Billions of Photos，是 Facebook 的 Jason Sobel 做的一个 PPT，揭示了不少比较有参考价值的信息。【也别错过我过去的这篇Facebook 的PHP性能与扩展性】 图片规模 作为世界上最大的 SNS 站点之一，Facebook 图片有多少? 65 亿张原始

由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署（即lvs+keepalived的方式），但仍然有用户反馈访问慢的问题。通过排查个服务器的情况，发现问题的根源在于共享存储服务器NFS。在我这个网络环境里，N个服务器通过nfs方式共享一个服务器的存储空间，使得NFS服务器不堪重负。察看系统日志，全是

原文：http://www.searchtb.com/2010/11/etao-tech-overview.html 一淘网（ www.etao.com ）于2010年10月9日10:39正式上线，很多同学和同行对一淘的系统架构和面临的关键技术问题都很感兴趣，这篇短文希望能给予简要的介绍。 系统架构 一淘的系统架构如上图所示。可以看到，一淘有三个数据来源：互联网、外部合作方和

故事背景：Alice和Joe将共同读取Couchbase Server中的同一个数据，然后都将对数据做出修改；接着将新的版本写入数据库。那么谁的修改将被保存？Alice还是Jone？又或是都不？还是结合了两者的。 开发者对有连续访问的共享数据使用锁。那么究竟该选择什么样的锁方案 —— 乐观或者悲观？ 在看Don Pinto带来的乐观锁与悲观锁

“及早发布。频繁发布。听取客户的意见”(Eric S. Raymond, The Cathedral and the Bazaar)是我们Pikacode公司的主导方针。开发中的技术选型必须认真的遵循这个指导原则。 Python 快速且整洁的开发。大部分我们的关键组件，如为git提供服务的http或ssh server以及mercurial远程操作，都只有不到几百行代码。更少的代码意

上回说到了用经纬度范围实现附近地点搜索。 一些小型应用中这样做没问题，但在大型应用中它有个显著的缺点：速度慢。慢的原因有两个， 第一是范围比较的索引利用率并不高，第二是SQL语句极其不稳定(不同的当前位置会产生完全不同的SQL查询)，很难缓存。 可以考虑使用geohash算法。 geohash是一种地址编码，它能把二维的经

负载均衡   LVS 工作在四层，内核态，性能极高，有VIP功能，配合 keepalived 做有效的 心跳检查和负载均衡安装配置麻烦， HAProxy 工作在四层到七层，功能强大，有VIP功能，配置简单，CPU占用高 Nginx 工作在七层，应用层功能多，配置简单，无法支持VIP功能 负载均衡器测试数据 软件  每秒并发量  CPU占

当下移动互联网照片分享及轻博客类服务极度红火。类Instagram的照片分享服务，国外的服务包括Instagram、Color、Path、Picplz、Foodspotting等；国内的类Instagram包括推图、图钉、随拍、丁仔、乐么乐么、冒泡拍拍等。而国外的轻博客类服务包括Tumblr、Zpad、Posterous等，国内的轻薄博客服务包括点点、推他等。 除了对这

当今从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜，所以很多人都把创业方向定位在互联网应用。这些人里大多数不是 很懂技术，或者不是那么精通，而网站开发维护方面的知识又很分散，学习成本太高，所以这篇文章将这些知识点结合起来，系统的来说，一个从日几千访问的小小 网站，到日访问

ITeye这两年来做的不太好，这是有目共睹的事实，作为网站的创始人，我确实有不可推卸的责任。有些会员也私下和我提出一些建议，期待网站未来发展的更好。其实我也一直对ITeye网站的发展不断的思考，希望找出一条更好的发展道路。ITeye网站这两年来暴露的问题很多，也一直有很多会员投诉和抱怨，从我的角度来看，主要有两

我已经在很多演讲里说过，改进你的系统的最好的方法是先避免做“蠢事”。我并不是说你或你开发的东西“蠢”，只是有些决定很容易被人们忽略掉其暗含的牵连，认识不到这样做对系统维护尤其是系统升级带来多大的麻烦。作为一个顾问，像这样的事情我到处都能见到，我还从来没有见过做出这样的决定的人有过好的结果的。 图片

LAMP 关键数据集锦技术选项参考 源自日积月累自己的其他人的经验总结 负载均衡   LVS 工作在四层，内核态，性能极高，有VIP功能，配合 keepalived 做有效的 心跳检查和负载均衡安装配置麻烦， HAProxy 工作在四层到七层，功能强大，有VIP功能，配置简单，CPU占用高 Nginx 工作在七层，应用层功能多，配置

[看到此文，感觉蛮不错的，所以转来了，因为我看到的文章也是转载的，所有欢迎原创作者认领此文] LAMP（Linux+Apache+Mysql+Perl/PHP/Python）常用来搭建动态网站或者服务器的开源软件，本身都是各自独立的程序，但是因为常被放在一起使用，拥有了越来越高的兼容度，共同组成了一个强大的Web应用程序平台。每个LAMP系统都

如果你想构建一个可以承载日访问量40亿次的网站，YouTube有许多值得借鉴的地方。本文是YouTube的工程师Mike Solomon在PyCon（PyCon是Python开源社区的开发者年度盛会）上关于YouTube扩展性演讲的摘要，相信会对大家有所启发。 许多团队都使得他们的基础架构越来越复杂，YouTube团队却尽量保持简单的风格。他们使用Pytho