上一页 1 2 3 4 5 6 7 下一页 (Page 2 of 7)
广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得
今天看到 Brad Fitzpatrick (就是大名鼎鼎的 Memcached 的作者，现在效力 Google) 在网志中说道，正在利用 Google 著名的 20% 的业余时间为 Google App Engine 增加对 Perl 的支持。
[来源]
还记得时不时的会从中文 Perl 邮件列表里看到有人散布 Perl 过时的言论，其实一个语言过时与否都不重要，关键的是是否有人依赖该语言打造出比较激动人心的应用。如果 GAE 能够支持 Perl ，或许就是 Perl 焕发第二春的时候。从这个角度来说， Erlang 不也是如此么?
提个意见，Google App Engine 啥时候能支持给中国移动发短信? 现在支持 China Unicom，周围没有朋友用联不通的，大家都用移不动的。
--EOF--
热热闹闹的 The 2008 MySQL Conference & Expo 还没落幕，一个不那么和谐的小道消息传了出来并被最终确定：Sun 计划对 MySQL 进行"选择性开源"，某些企业级的新特性源代码将不再开放。
谁知道 Sun 葫芦里卖的什么药，看家宝 Java 都开源了，在 MySQL 上还保留什么呢? 能否成为更受人尊敬的公司，还要看气度。这点上，Sun 始终扭扭捏捏。
一心要做 Web 2.0 中的这个 Dot 的 Sun，看来又要做活雷锋了，不过这次似乎是要帮助一下竞争对手 PostgreSQL。
--EOF--
Oracle 对 PHP 的支持一直是不错的(只是国内好像 PHP + Oracle 的开发并不多)。 Oracle 11g 中的新特性数据库驻留连接池(Database Resident Connection Pool，DRCP) 对 PHP 应用进一步扩展带来了一种可能。
这个特性应该重点针对 PHP 应用的。PHP 不支持真正的多线程，非持久连接非常消耗 CPU 资源，扩展性也差；持久连接扩展性好了一点，但是又额外占用更多的内存资源(PHP 之父在几年前的一个 Step-by-Step 优化演示的文章中很形象的说明了连接开销对应用的影响)。DRCP 的出现能更好的缓解上述两个问题，其共享连接能跨 Apache 与中间件节点，但共享的连接是基于数据库用户的，比如 Scott 用户登录到 DB 上的所有连接间共享。
Oracle 官方披露的测试数据是，在 4 CPU Intel Xeon MP 2.80GHz 机器上，2GB RAM, 32bit RHEL 4. 支撑到 14000 个链接的时候，CPU 使用率在 65% 左右。这个...还是太惊人了，根据我找到的另外一份测试结果，看来要大打折扣才能有参考性。
--EOF--
偶然发现了这个 NagiosChecker ，更方便的显示 Nagios 报警信息的 Firefox 插件。
这个插件几乎能搞定 Nagios Alert检查的方方面面，具备足够丰富的的过滤规则与显示条件；还能够定期调度；有趣的是，居然还提供声音报警。
一般人我不告诉他！
--EOF--
一直以为新浪是国内几家门户网站中技术比较糙的一家(也可能是太低调了)，这应该是我比较无知的偏见，无意冒犯。看到这位新浪技术人员介绍的开源软件项目: NCache 与 Memcachedb 。挺欣赏他们这种国内环境下比较少见的分享精神。为他们喝彩！
这两个软件，应该都是从实际应用需求上得来的，可以说是"设计以致用"，不是纯用于研究的，而设计思路很有些 "Mashup"。我没有实际使用经验，不知 Memcachedb 和 Tugela Cache 二者有何差别。我对 Memcachedb 这个项目倒是比较感兴趣的，把 Cache 和 DB 有效结合起来，消除 DB 单点 I/O 承受的应用压力...而且，实现方便且廉价...十分美好的前景。
期待能有更多类似的项目涌现出来。国内的 Web 2.0 站点软件设计人员也可以借鉴一下。
--EOF--
更新：【很多人估计从来不仔细看文章的具体内容。我这篇文章里可看不出来 "对Memcachedb的思想比较推崇"的, TBStore 也未必就有多超前，内存 + DB 八百年前就有人想到了。只是赞扬一下 Sina 团队的精神而已，如果只是攀比牛B，去和Google 、eBay 比比好了】
更新2： Memcachedb 现在在有了官方站点：http://memcachedb.org/
Yahoo! 和 Carnegie Mellon 大学合作的开源分布式计算项目代号为 M45，这个 超级计算集群 有 4000 个处理器，3T 内存，1.5 PB 存储空间，自称足以跻身世界超级计算机 50 强。这两天网络上搜索最火的一个词应该就是 Hadoop 了吧? 雅虎的这套集群就是跑在 Hadoop 上。
Hadoop 现在已经有很多不错的应用案例可以参考，比如这篇 Running Hadoop MapReduce on Amazon EC2 and Amazon S3
Yahoo! 或许早意识到自己的 Web 1.0 方式下的计算能力比 Google 差的太远，干脆放手一博，助力 Hadoop 项目，期望能借助开源的力量与 Google 掰一下手腕。从这里我们得知 Yahoo! Hadoop 团队早在 06 年就成立了，当然，这个团队成立的前提是 Doug Cutting 入职雅虎。
雅虎现在不应该担心追不上 Google ，应该担心 Doug Cutting 别被 Google 挖去，否则，可真的没机会了。
--EOF--
维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。
来点直接的数据：
架构示意图如下：
Copy @Mark Bergsma
在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? "A 40-line patch for BIND to add geographical filters support to the existent views in BIND", 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的--面向各个国家，各个地域。
WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.
Lighttpd 现在成了准标准图片服务器配置了。不多说。
维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。
MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。 复制、读写分离......应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。
运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。
参考文档：
Wikimedia architecture （PDF)
Todd Hoff 的文章
--EOF--
今天才注意到 Linux 上这个 Sysreport 工具。当需要 Linux 主机详细完整的描述给另一个人的时候，这个工具非常适合。用 root 用户之行，但要注意最好不要抓取 currently installed packages 信息，这一步非常慢。(用 -norpm 参数)
存储厂商 EMC 也有个 EMCgrab 工具，工作原理类似，额外抓取了存储相关的信息而已。估计各家存储厂商都有，要不远程支持也太费劲了。
--EOF--
在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。
Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)
简单的说 YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.
YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)
视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。
出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。
YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。
最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)
YouTube 也用 Memcached.
很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?
--EOF--
《程序员》杂志在做关于 Web 可扩展性的专题，编辑朱海燕联系上了 Flickr 的 Cal Henderson, Web 2.0 应用最出色的架构师之一, 准备对他进行 e-mail 采访，如果大家有什么关于 Web 扩展性的相关问题，可以在后面留言或者发邮件给 dbanotes@gmail.com , 我代为转交。
五月份阿里巴巴举办的侠客行网络大会 Cal Henderson 因为时间的关系而没能成行，希望这次的采访能弥补一下不少人的遗憾。
--EOF--
