如果你一直在用一款软件,却没发现任何非预期的状况,那只能说明你对这款软件的使用还不够深入
小鶸·仁波切

自封「Grav 大中华区首席布道师」的我,用 Grav 搭建博客将近一年,却一直没碰到什么奇怪的问题,对此我深感惭愧,用得还不够深入啊!就在今天,事情出现了转机,我似乎把 Grav 用出 bug 来了。

事情是这样的,晚上跑去电影院看了个电影「大护法」,看完之后例行公事更新 Pastime 页面,然后页面就出乎意料地给了个报错信息,Invalid Security Token。按理说登陆之后就不会报这个错,这是为啥?

虽然没有仔细排查,但是我看了看 POST 请求的报文,感觉知道了大概原因。现在 Pastime 页面的主体,我是利用 Grav 的配置页面来维护的,这个在之前的博文中有过介绍。然后随着时间的推移,配置中的条目越来越多,每次 POST 的时候都要把几百条记录一并提交,直到今天我给这只不堪重负的骆驼加上了最后一根稻草,新增加的这一个条目使得 POST 报文中本应传递到后端的 token 不知何故丢失或者截断,导致身份验证失败,Invalid Security Token。

按理说正常的修复方案应该是去修改后端代码,把这个非预期的截断去掉,但是我懒,不想查 bug 懒得改代码,我只是想简单地记录一下大护法,于是我绕道解决了这个问题,用的是一个听起来很高大上的技术方案,冷热数据分离。

在大型复杂 Web 系统中,冷热数据分离是一种常见的架构模式,在应用层用于解决 OLTP 存储无法支撑全量数据的问题,在存储层则是为了大幅提升存储器的性能。

所谓模式,其实就是套路,是前人在特定技术条件下对特定类型问题的最佳解决方案的总结和提炼。举个例子,淘宝或者亚马逊这种大型电商平台网站,通常我们能够很直接地查询到 6 个月之内的订单,而 6 个月之前的订单则需要多点几次鼠标才能查到,这其实就是把 6 个月内的订单当作热数据,放在 OLTP 存储器中,而 6 个月之前的订单当作冷数据,放在 OLAP 或者列式存储器中,由两套系统分别提供查询服务。

回到我的照片流配置,热数据差不多可以认为是最近一个月新增的记录,冷数据是一个月前录入的记录,这样子就能够将在配置的条目数量控制在一个较小的范围,无论如何都不会触发之前遇到的问题。实际上直接把之前的配置全部作为冷数据归档即可,新增的记录自然就是热数据。

渲染页面的时候,把冷热数据合并,就是完整的数据。

架构套路深似海。

License: CC BY-SA 4.0

Next Post Previous Post