财神爱欢乐——高铁和它的站台（转载自网络）

大家在开发之余，看点小故事放松放松哈。

我居住的地方虽然是个小城市，但是城西和城北却神奇般的各有一座高铁站，这给我们 去往北京等地添加了不少便利。有一次去西站接朋友回家，一路上都很平坦，就是到了车站附近，突然人工堆砌了一个梯形的高地，车子入站需要上一个坡，然后进 入一个长长的平台，停在那里等人吧，我也没闲着，对着车站广场的数十个台阶想了很久！今天想和大家说说这个站台的故事。

首先是入站的这个上坡，在我的车子越过这个坡后，本来很快的车速一下子就降了 下来，到了上面的平台时，轻轻点了几下刹车就停住了！这个倒是很方便，能降低车速，提高安全性。其次就是出站的时候，从上面的这个平台下去，随后就是一个 长下坡，不用踩油门就能很快的提速，感觉很好很顺畅。

后来我一想，不止我的车是这样，跟我并行的火车也是这样，要进站时本来就要踩刹车，现在经过一个上坡可以更快的减速，同时，出站时经过一个下坡就可以更快的加速！我想火车起步时估计会更耗费能量，有个下坡的辅助能节约不少。

这样就清晰许多了！人工造的这个梯形高台，就是考虑到车辆进站时必然要刹车减速，上坡能减少必要的刹车，更快的让车辆停下来！而在车辆出站时，还能提供额外的动力！这可以说是最简单的动力回收系统！

说到动力回收系统，它的原理就是将已经输出的动力在刹车时回收回来，以达到更 好的节能效果！这个想法很是巧妙，它的思路是：“既然你要刹车，与其让能量浪费掉，不如我用一个装置来回收它，用来发电、增加压力或者什么其他的，反正都 比白白浪费掉要更合理！”把这个思路简化一下，就可以得到：“不能随意的丢弃任何一种资源，要想办法回收它们的价值！”

好吧，这听起来有点像垃圾回收或者是可再生资源的讨论了！但是我们今天要说 的，是软件设计中的一个超级常见的——缓存系统！对了，让我先强调一个概念，我们不要总说xxx系统，然后就去寻找有没有某个开源软件是干这个的，比如这 里提到缓存，然后就开始讨论memcache之类的东西，它们确实能帮助你完成任务，但不能激发更多的想象力，请允许我修正一下刚才的说法，我们今天要说 的是：缓存的思路。

把问题简化总能更方便的讨论，假设你在编写一个程序显示某个信号灯的状态（开 或者是关），这个程序以网页形式分发，有成百上千人在使用它查看这个信号灯的信息！网页上有个定时器，每隔3秒钟就发起一次ajax查询，服务器响应之， 返回数据供网页解析和显示，网页随之刷新状态信息。

嗯，逻辑就是这么简单！我们算一算，假设100人使用这个程序，那么每3秒就 有300次请求，它们达到服务器的时间是随机的，所以约等于每秒100次请求。这对服务器来说是个压力，不过不算很大，配置好一点的家伙总能杠着！但是灾 难性的事情是，100次请求对应的是100次查询信号灯状态，我们得通过串口给某个设备发消息，然后解析它的响应数据，这个过程可不是什么愉快的事儿！ 嗯，十有八九你的程序就挂了！

刚才已经提到了，缓存的思路就是：不要随意的丢弃任何一种资源，要想办法回收它们的价值！依着这个思路，我们可以看到每次请求信号灯状态，然后返回给客户端之后，这个状态就被丢弃了，然而它真的没有价值了么？这可得好好考虑一下！

像这样设计吧：

1、  服务器返回状态信息前，把状态连同获取时间一起存入一个对象，保存在内存里

2、  另一个客户端来查询时，先查询内存中的状态对象，看看它的获取时间是否在x秒之内（x默认可以是3）

3、  若在x秒之内，则直接返回这个状态，不与信号灯通信

4、  若不在x秒之内，则获取最新的状态，并把状态对象刷新

于是我们可以看到，无论是100人使用还是1000人使用，获取信号的频率只 和x有关，如果是3的话，也就是无论多少人使用程序，最多3秒刷新一次状态！这就是缓存的思路，在状态返回之后并不把它丢弃，而是认为它在较短时间内依然 有效，于是避免了密集型的信息查询和通信开销，达到了很好的加速的效果！

编写一个大型的缓存系统可能很难，这涉及很多的知识！但是这并不妨碍你拥有基于“资源回收”的缓存思路，可以让你轻松的做出以上的设计（不超过20行代码），在某些很常见场景下，加速你的系统，提高客户的满意度！

来吧，每天一个小想法，每天一个小思路，每天做个有心人！