对于时效性要求高的一类数据，缓存就完全不适用么?当然不是的，只不过整体的思路还得再变一变。一般所谓变化，可能主要是列表当中的数据有增、减或者改动，但是绝大多数的数据还是保持不变的。大多数情况下，前面讲的设定在一段时间范围内做缓存还是适用的。
如果有接近于要求实时更新数据的需求，大家可能很容易想到使用定时器的方法，比如每20秒执行一次getPage(pageIndex)方法并重绘列表。但大家只要联想到前面1000万次页面访问的假设，就会发现这无疑是一件超级恐怖的事情，按照这种访问量和重试的频率，服务器压力山大呀。关于这种情况怎么处理，我想请大家去看一看Gmail、163邮箱和新浪邮箱等对邮件列表页的处理方式。它们几乎同时满足了我们之前的假设：超级大的日访问量，对数据要求实时更新等。用网络抓包工具分析一下不难发现，它们在用户重复请求同一个页码的数据时，都不会向服务器发出请求。为了保证有消息更新时能够及时通知用户并且更新邮件列表，可以使用一个定时、重复进行的异步请求，但是这个请求只是做一个状态查询，而不是刷新列表。只有获取到有消息更新的状态时才会发起请求去获取更新的数据，或者状态查询的接口在发现有更新时会直接把更新的数据返回。事实上，163邮箱这个定时的状态查询，间隔时间都是设的比较长的，大概两分钟一次，新浪邮箱这个时间间隔更长一些，大概5分钟一次，可以了解它们都在尽力减少请求数量。但是这种处理方式，可能就不是仅前端单方面就能做的，实现方案需要和后台接口整体考虑才行。
现在我们再回过头来看一下代码片段2当中的数据缓存方法。现在不再讨论请求数量和流量的节约，我们来看一下前端的实现上还有没有什么值得深究一下的。按照代码片段2示意的处理方式，原始数据被储存起来，当再次被调用时，showPage(datalist)需要再次根据数据去重建html结构展现给用户，但是之前这个创建结构的过程我们是有做过的，是不是可以考虑在第一次创建结构的时候，直接把这个结构存起来呢?这样可以减少js重复的计算，特别当结构比较复杂时更值得考虑。再想一下，这个结构之前在页面上创建过了，翻页的时候销毁并再次创建新的结构，也是耗费资源的，能不能第一次创建好了之后，翻页的时候不销毁，只是通过控制CSS样式给它隐藏起来，重复翻页的时候也只是在这些创建好的结构之间控制彼此显示或者隐藏?
最后，这里讨论的方法，不一定适用所有情景，但或者会有些许启发，可以在适当的时候尝试其中一二。同时思想如果发散开来，或者还不仅仅可以运用在无刷新分页。这里抛砖引玉，大家一起探讨。
您可能感兴趣的文章: