They don’t teach you this in college, but the fundamental theorem of the software industry is the idea that everything needs to be rewritten all the time. As a corollary, web startup engineers believe that there is no problem but scalability, and architecture is its solution. And thus, the NoSQL movement was born.

The idea is that object relational databases like MySQL and PostgreSQL have lapsed their useful lifetimes, and that document-based or schemaless databases are the wave of the future. Never mind of course that MySQL was the perfect solution to everything a few years ago when Ruby on Rails was flashing in the pan. Never mind that real businesses track all of their data in SQL databases that scale just fine. (For Silicon Valley readers, Walmart is a real business, Twitter is not.)

Invariably, all web projects start off with something like Rails or Django, most likely backed by MySQL. The data relationships are easy to model, and the application works well. If you are lucky enough that people actually use your application, eventually you will start to see some performance issues. At this point, a developer who values technological purity over gettin’ shit done will advocate “rewriting the whole thing in a weekend using Cassandra”. And if he’s smart enough, he might just pull it off. (Of course, said developer has only migrated the app to use a different data store – all of the ancillary support code was conveniently ignored) (更多…)

不知道怎么回事儿，今天一查，发现我已经被百度杀掉了，收录为零，虽然我并不在乎这个东西，但是感觉，一句话

这个世界上，怎么有那么多不知道原因的事儿

http://www.baidu.com/s?wd=site:heyues.com

就算我的博客里面有什么异常关键字，拜托你也告诉我一下

如果说我转载别人的文章，拜托也用你的机器智慧计算一下

不说了，生活在中国的互联网，就是这么悲剧，我很高兴，看见团购、京东等正在推翻着互联网的三甲七雄

由于在项目后期会引入缓存策略对角色的数据进行缓存，而现在我们大部分缓存都使用文件缓存，开发过网页游戏的朋友们大都知道，语言包和游戏相关的数 据大部分不经常改动，有时候几个星期不需要更新，只是在进行版本更新的时候才重新生成一次数据缓存，而角色的数据和数值时刻在变化着，会频繁的更新和操 作，采用文件缓存会频繁地进行I/O操作，在这个功能上文件缓存就不太适合了，所以对于角色的数据采取内存缓存策略在这里就比较合适。

对于内存缓存，比较常用的有两种memcache和memcached扩展。而memcached和memcache的守护进程memcached同名， 比较容易引起混淆，甚至提到memcached，有些人第一想到的是后台的守护进程，这里还是有必要分析一下两者之间的区别，以下观点仅是个人观点，希望 朋友进行补充和更正。
首先我们可以从php官方手册上可以清晰的看到两者的区别：
memcache:http://cn2.php.net/manual/en/book.memcache.php
memcached:http://cn2.php.net/manual/en/book.memcached.php

memcache是完全在PHP框架内开发的，memecached是使用libmemcached的。从手册上看，memcached 会比 memcache 多几个方法，使用方式上都差不多。 (更多…)

MySQL单机多实例方案，是指在一台物理的PC服务器上运行多个MySQL数据库实例，为什么要这样做？这样做的好 [...]

http://www.php-oa.com/2008/05/13/iframezhongkuayuchuandicookie.html

晕掉,IE真是超级破,还好我二年没用它了(用了二年linux做桌面).这次一个大问题，客户的一台主页使用了frame的方法来固定自己的域名指向一个二级,为了让用户看起来更加好.

但发现很多用户不能登陆，但有的用户也能登陆(现在才清楚能上的都是firefox)。查了好久,后来发现原来是IE有个叫P3P(The Platform for Privacy Preferences)隐私参数选择平台，这样的一个超强的功能.

在frameset里面，也就是里面的frame是来自第三方站点(不同IP或不同域名)，那么默认情况下IE会自动禁用这些站点的cookie，也就是在请求某url时在HTTP header里不发送它们的cookie，包括session的cookie。注意，这些站点在response里面设置的cookie还是会被发送到浏览器的。

但象IE 6.0和IE 7.0有个自己的标准.要支持P3P,IE 6的缺省隐私等级设置为”中”——即”阻止没有合同隐私策略的第三方cookie”。而在用户浏览a.php时 A.com写入的为第一方Cookie,其嵌入的iframe指向b.php.这时B.com写入的就为第三方Cookie了，所以它是被IE当在了大门外。

所以,每次当用户提交的cookie提交时,就挂掉了.因为传不到真实的服务器.

好了，不多讲了，直接讲解决方案. (更多…)

PHP5.4改变的特性

20 Jun 2011, PHP 5.4.0 Alpha 1
- autoconf 2.59+ is now supported (and required) for generating the
configure script with ./buildconf. Autoconf 2.60+ is desirable
otherwise the configure help order may be incorrect. (Rasmus, Chris Jones)

删除的特性：
. break/continue $var syntax. (Dmitry)
. Safe mode and all related ini options. (Kalle) //删除安全模式相关的所有函数和配置
. register_globals and register_long_arrays ini options. (Kalle) //删除这两个函数配置文件中的内容
. import_request_variables(). (Kalle) //
. allow_call_time_pass_reference. (Pierrick)
. define_syslog_variables ini option and its associated function. (Kalle)
. highlight.bg ini option. (Kalle)
. Session bug compatibility mode (session.bug_compat42 and
session.bug_compat_warn ini options). (Kalle)
. session_is_registered(), session_register() and session_unregister()
functions. (Kalle)
. y2k_compliance ini option. (Kalle)

- Moved extensions to PECL: (Johannes) //sqlite 被移动到PECL中
. ext/sqlite. (更多…)

from http://www.infoq.com/cn/news/2010/08/bigpipe-facebook-optimize

近日，Facebook的研究科学家Changhao Jiang介绍了一个名为BigPipe的技术，这项技术可使Facebook站点的访问速度提升一倍。BigPipe是Facebook的创新研究之一，同时也是Facebook的“秘密武器”，它能够极大提升站点的性能：在大多数浏览器中，BigPipe都能将用户感受到的延迟时间降低一半，除了Firefox 3.6，BigPipe可以将Firefox 3.6的延迟时间降低50ms左右，大约降低了22%左右。

BigPipe及相关创新的驱动力是：

相比于10年前，现代Web站点的动态性与交互性都迈上了一个新台阶，传统的页面处理模型已经无法满足当今Internet速度上的需求了。 (更多…)

摘编自：http://www.javaeye.com/topic/314651 原作者：mfcai 1.为什么 [...]

Google recently released its Protocol Buffers as open source. About a year ago, Facebook released a similar product called Thrift. I’ve been comparing them; here’s what I’ve found:

Overall, I think Thrift wins on features and Protocol Buffers win on documentation. Implementation-wise, they’re quite similar. Both use integer tags to identify fields, so you can add and remove fields without breaking existing code. Protocol Buffers support variable-width encoding of integers, which saves a few bytes. (Thrift has an experimental output format with variable-width ints.)

The major difference is that Thrift provides a full client/server RPC implementation, whereas Protocol Buffers only generate stubs to use in your own RPC system.

Update July 12, 2008: I haven’t tested for speed, but from a cursory examination it seems that, at the binary level, Thrift and Protocol Buffers are very similar. I think Thrift will develop a more coherent community now that it’s under Apache incubation. It just moved to a new web site and mailing list, and the issue trackeris active.

如果你知道 Tokyo Cabinet ，那么就应该知道 Kyoto Cabinet，因为他们都是同一个作者（平林幹雄）开发出来的 Key-Value 数据库。

Kyoto Cabinet：a straightforward implementation of DBM，主页：http://fallabs.com/kyotocabinet/ ，演示文稿：http://www.slideshare.net/estraier/kyotoproducts-5886452 。

Tokyo Cabinet：a modern implementation of DBM，主页： http://fallabs.com/tokyocabinet/

以下Tokyo Cabinet简称为TC， Kyoto Cabinet简称为KC，本文主要对KC做介绍。
KC是TC的后继者或兄弟项目，因为KC在各方面都超过了，所以作者在TC的首页上的开头向所有人推荐使用KC（我也是这个推荐才开始关注KC的）。TC为C实现，为了更好的可维护性，KC采用C++实现。

以下内容的英文原文来自：http://fallabs.com/kyotocabinet/spex.html (更多…)