设计的一个考虑点：区分数据的常变部分和不常变部分

做系统时，开始阶段设计领域类时，除了从数据结构、对象模拟的角度出发，特别是访问量大的时，还应该考虑数据的实际应用场景，区分数据的常变部分(或称瞬时状态)和不常变部分。将常变部分和不常变部分剥离，能更好为其制定适当、高效的访问策略。

我以陶宝商品为例子。陶宝商品的不常变部分是：商品的基本信息、状态；常变部分是：商品浏览次数。
一般的设计：
用户每次浏览某个商品时，服务器总是准备好上面的所有数据，一次向浏览器flush显示出来。

可是，陶宝不是这样做：陶宝的一个商品页面并不是一次由服务器准备好，统一向浏览器flush完成的。
它把页面分为若干块，不同块的数据从不同的服务器请求：
图片有图片服务器(这没什么特别的，不是本贴的主要说明点)
样式有样式服务器(这没什么特别的，不是本贴的主要说明点)
基本信息有基本信息服务器(Web服务器)
商品浏览次数有“次数服务器”(可能是另外的Web服务器)
商店店主有店主在线状态服务器
。。。

这里作为常变数据的商品浏览数据并不是随商品数据合为一块发送到浏览器的。
OK。这样做到：各部分可以很好利用各部分的特性，做扩展、做缓存、做即时性的不同承诺。

不常变数据可以充分利用缓存(考虑本地缓存) + 即时持久化，常变数据可以使用集中数据缓存器 + 隔时段持久化。特别是一些瞬时状态，如在线状态的，基本上就不需要持久化。
像商品浏览次数这种每次只要用户浏览就需要变更的，只需要update常变数据服务器，而不用立即持久化。
这样，那些不常变数据的缓存的作用和效果将极其明显。

页面在达到用户浏览器时，再通过ajax技术，从常变数据服务器获取那些常变数据。
(这个时间段，该数据将显示空白，不过这一点也不影响用户体验):

在设计表时，不必一定要把“浏览次数”列设计在基本信息表里。“浏览次数”之类的数据可以是单独的服务器，以商品Id作为其身份证异步地从浏览器发起向那个单独服务器去取。
同样，店主表基本上也可以不需要在线状态的字段。

--------------------
只要把缓存作为一项高级决策来做，不要因为缓存中间件提供简单的API，就想用就用，不想用就不用，一般就不会太失望。

对于海量数据的应用确实是一个不错的解决办法 但是成本将会很高 能这样做的公司都是些门户网站之类的

所有的设计模式要达到的目的，就是为了解决你那个变与不变的问题。

不错的设计，耦合度明显比将两者设计在一起要来得低

taobao是用什么东西去映射这些在不同的服务器上面的数据的呢?

把不变的信息放到缓存里那要多大得内存才够啊，分布式缓存。。
确实成本比较高，那你说本论坛得“性别”“积分”“来自”不怎么变，文章数经常变，那么分别存储么，分别存储可能带来多表查询啊，如果是小并发量，还真看不出区别