规则三，缓存更新要保证原子性或称作线程安全，特别是采用被动缓存的方式时，很可能两个用户访问时导致同一个缓存被更新，
通常情况这不是大问 题，可缓存失效后重建时很可能是引发连锁反应的原因之一。规则四：缓存也是有成本的。
不只是技术成本，还有人工时间成本。如果一个功能使用缓存和不使用， 在可预见的访问量情况下区别微小，
但使用缓存会使复杂度增加，那就不用，我们可以加个TODO标注，在下次迭代的时候加上缓存处理。
前 面讲到，文件存储是独立的，那么所有的文件操作就都是远程调用。可以在文件服务器上提供一个很简单的RESTful接口，
也可以提供xmlrpc 或json serveice，WEB服务器端所生成和处理的文件，全部通过接口通知文件服务器去处理，WEB服务器本身不要提供任何文件存储。
你会发现很多大网站的 上传图片跟保存文章是分两步完成的，就是基于这个原因。
以上几条“前面讲到”，其实无数人都讲过，我也只是结合前几篇文章用自己的话重 复了一遍，真正分析起来精髓很简单——除了良好的功能逻辑分层，
我们 还要为数据库存储、缓存、队列、文件服务等程序外层资源调用单独设计接口，你可以把你的程序想象成是运行在 Amazon EC2 上并用他的所有web service服务，
你的数据库就是它的SimpleDB，你的队列就是他的SQS，你的存储就是他的S3，唯一不同是amazon的接口是远程调用，你的是内部调用。
将支撑服务接口化，意味着将MySQL更换到PostgreSQL不需要更改业务处理程序，移植团队甚至不需要跟业务开发团队过多沟通；
意味着业务开发团队是对接口编程而不是对数据库编程；意味着不会因为某个业务开发人员的失误而拖垮性能。
产 品设计完了，程序框架搭完了，可能有矛盾在这个节骨眼儿产生了。不断有产品设计抱怨说他的创意没实现到预期效果，有程序员抱怨说产品设计不切实 际。
这种抱怨多缘于产品人员不懂技术，技术人员不理解产品。从广义上来讲，产品包含市场策略、营销手段、功能设计，产品和技术在争论时往往把焦点放在功能 上，
而实际重点是，实现这个功能所消耗的成本跟能这个功能带来的利益能否换算，能否取其轻重。若可以，争议解决。若不能，则抛硬币看运气。
因为一个功能的 加强而引发指标井喷，或因项目拖延而导致贻误战机的例子比比皆是。激进的决策者注重利益，保守的决策者注重损失，
聪明的决策者会考虑这个问题是否真的那么 严重。
关系到未来的事情谁都说不准，要不怎么说创业一半靠运气呢。不过总有能说的准的事情，那就得靠数据说话。
没有100%也有99.9%的网站安装了访问统计代码，连我的 也不例外，新闻联播也总说科学决策科学发展的。有了统计，能确定的事情就很多了。
例如，可以根据来源-目标转化率来分析哪类渠道的人均获取成本低，根据来 源-内容访问猜测用户跳出率原因，根据用户点击行为判断链接位置是否合理等。
将数据以不同方式组合起来，找到内在联系，分析内因外因，制定对应策略，减少 拍脑门决策。靠数据支撑运营是个非常专业的事情，
虽然不懂深奥的数学模型不会复杂的公式计算，渐渐学会因为A所以B，因为A和B所以C还是相对简单的。