如果要继续深究的话，代码片段2当中数据缓存方法还值得讨论一下。我们前面假定可以忽略分页数据的时效性，但实际应用里面时效性却是个不能回避的问题。缓存毫无疑问会导致时效性的降低，真正的缓存方案应该还要依赖对应用时效性要求的分析和取舍。
对于一般不是特别强调时效性的内容，页面上的缓存应该还是可以接受的，一来用户不会一直停留在一个页面上，页面之间有跳转造成重新加载时，可以获得更新后的数据。另外如果用户有刷新页面的习惯的话，当他特别想看列表是否有数据更新的时候，可以选择刷新页面。如果追求完美的话，还可以考虑设定一个时间范围，比如5分钟。如果用户一直停留在当前页面超过5分钟，那么5分钟内他的翻页都是先读取页面上的缓存，5分钟以后的翻页才再次请求服务器的数据。
有些情况，如果我们可以预知数据的更新频率，比如多少天才可能会有一次数据更新，甚至可以考虑使用本地存储，隔一定时间才触发一次对服务器数据的请求，这样对请求数和流量的节约就更加彻底了。当然最终什么样的缓存方法适用，归根结底还取决于产品对时效性的要求，但原则还是能节约的请求和流量，尽量节约，对于访问量超大的页面尤其如此。
对于时效性要求高的一类数据，缓存就完全不适用么?当然不是的，只不过整体的思路还得再变一变。一般所谓变化，可能主要是列表当中的数据有增、减或者改动，但是绝大多数的数据还是保持不变的。大多数情况下，前面讲的设定在一段时间范围内做缓存还是适用的。
如果有接近于要求实时更新数据的需求，大家可能很容易想到使用定时器的方法，比如每20秒执行一次getPage(pageIndex)方法并重绘列表。但大家只要联想到前面1000万次页面访问的假设，就会发现这无疑是一件超级恐怖的事情，按照这种访问量和重试的频率，服务器压力山大呀。关于这种情况怎么处理，我想请大家去看一看Gmail、163邮箱和新浪邮箱等对邮件列表页的处理方式。它们几乎同时满足了我们之前的假设：超级大的日访问量，对数据要求实时更新等。用网络抓包工具分析一下不难发现，它们在用户重复请求同一个页码的数据时，都不会向服务器发出请求。为了保证有消息更新时能够及时通知用户并且更新邮件列表，可以使用一个定时、重复进行的异步请求，但是这个请求只是做一个状态查询，而不是刷新列表。只有获取到有消息更新的状态时才会发起请求去获取更新的数据，或者状态查询的接口在发现有更新时会直接把更新的数据返回。事实上，163邮箱这个定时的状态查询，间隔时间都是设的比较长的，大概两分钟一次，新浪邮箱这个时间间隔更长一些，大概5分钟一次，可以了解它们都在尽力减少请求数量。但是这种处理方式，可能就不是仅前端单方面就能做的，实现方案需要和后台接口整体考虑才行。
