原文链接：http://glinden.blogspot.com/2006/01/early-amazon-inventory-cache.html
原文作者 Greg Linden 毕业于华盛顿大学计算机学院，1997 年加入 Amazon，开发了享誉业界的 Amazon 推荐引擎。
著名的 Item-based 推荐算法的提出者之一；Findory.com 创始人。
其 Blog – Geeking with Greg 是个性化推荐领域最有影响力的博客（没有之一）。
本文首发 http://www.resyschina.com/2012/03/early-amazon-inventory-cache.html，由 @raully7 翻译。
类似谷歌的20%时间，亚马逊的员工有时也会做一些不如日常事务那么紧要的额外工作。
我当时负责了好几个项目，但我想跳出来，以掌握更多部分的代码。只是读代码过于无聊了，我需要做一些特别的事情，让我更深的理解他们。
所以空闲时候，我开始试着做性能优化。主要关注于那些高流量的页面——首页、书籍详情页、搜索结果页。我问自己，obidos（注1：亚马逊的页面渲染引擎）把时间耗在什么鬼地方了？
很快我发现了些有趣的东西。第一个上手改造的是购物车。
当你走进一个超市，你做的第一件事很可能就是推一个购物车。同样当人们访问亚马逊时，系统做的第一件事情也是给他们分配一个购物车——在数据库里开辟部分空间以存储购买的商品。
然而，超市并不需要应付大量机器访问或多窗口购物的情况；如果需要，他们也得有更多的购物车，而且几乎每个都是空的。
考虑这些并不实际购买的情况，延后到第一次购买物品时再分配购物车就变得很有意义了。把所有购物车的花销加起来，这个小改动带来的帮助比想像的要大的多。
另一个更大的问题是实时库存检查。当你查找一本书时，亚马逊检查仓库货架内是否有存货。如果没找到，他会再查找过多久才能订购这本书。所有这些都是实时完成的。
这是书籍详情页中最耗时的操作。库存检查是个丑陋的业务逻辑。
但我们真的需要实时的信息吗？也许用几分钟前的结果就够了。恩，是的，可以缓存数据，稍有延迟并不是什么大问题。
因为是用业余时间做这件事情，我从一些并不太大的改动开始。我认为，有多大压力是由网站业务决定的，我要做的是把加锁减到最少。同时我认为能通过缓存预加载，使得用户在缓存刷新时也没有任何延迟。
我鼓捣出的东西似乎运作良好。在测试中，访问延迟从一个很大值降低到了接近零。我开始同其他人讨论这个原型，听取他们的改进意见。
正巧，他们正在对亚马逊进行重新设计，包括彻底的改造和增加新功能。有人找到我希望能在搜索结果页也显示书的库存情况，然而没有缓存这是完全不可能实现的。除非能很快把我的原型实现并弄上线。我们也确实这么做了。
当然，这些如今看来是过时的。当我实现这个库存缓存时，它被设计为一个西雅图的小仓库工作，运行在单台大铁壳（honkin’ iron）服务器上。如今海量的货物散步在若干个巨大的配送中心中——其中一些甚至大的能装下13个足球场——通过切换到一个商品服务器集群能在几秒内获得结果，这最终使得旧缓存不再适用。他运转良好到超出了他的时代，长到年轻时的功绩躺在自己的衰老下被遗忘。（It lasted well beyond its time, so long that the heroics of its youth lay forgotten under the problems of its senility.）
这里我将库存缓存作为个人自由时间带来收益的若干例子中的一个。 20％时间产生了远远超出其比例的价值。
注1：obidos是amazon早期的页面渲染引擎，一直被使用到06年8月底。因临近亚马逊河的小镇Óbidos而得名。http://en.wikipedia.org/wiki/Obidos_(software)
Greg的这系列文章，很多都是回忆他20%时间里鼓捣的事情。也侧面说明了真激情确实可以一辈子。
月初James Whittaker离开谷歌时，也专门写了一篇吐槽文。其中一段回忆到昔日公司的创新气氛：
In such an environment you don’t have to be part of some executive’s inner circle to succeed. You don’t have to get lucky and land on a sexy project to have a great career. Anyone with ideas or the skills to contribute could get involved.
20%时间，一直我们这些国内工程师艳羡和乐于谈论的，似乎总是可望不可及。环境不论，很多事情其实可以从自己做起。
