用Redis来搞网页浏览量记录，效率还挺不错的感觉

根据网络技术社区分享、个人项目实践经验以及Redis官方文档的应用案例综合整理）

前段时间想给自己弄的那个小博客加点人气指标，最简单的就是显示每篇文章的浏览量，一开始图省事，直接用的数据库，每次有人点开文章，就在后端给那个文章的view_count字段加一，博客刚弄起来，也没几个人看，所以没啥感觉，后来不知道哪篇文章被一个稍微大点的平台转了下，访问量噌一下就上来了，然后我就发现网站打开变慢了,有时候甚至会卡一下。

我琢磨着，问题八成出在这个频繁更新数据库的操作上，每次有人阅读，哪怕只是让数据库里的一个数字加一，也要进行一次写操作，人一多，这数据库就有点扛不住了，尤其是像MySQL这种关系型数据库，它更擅长处理复杂查询，对这种超级简单但频率极高的“点一下加一”的操作，有点大材小用,而且效率不高。

后来就听人提到了Redis，说这玩意儿处理这种计数场景特别拿手，我就去了解了一下，发现它确实挺适合的，Redis是把数据都放在内存里的，所以读写速度飞快，比去硬盘里读写的数据库快太多了，它里面有一种数据类型叫string，可以用来存数字，而且它有一个命令叫INCR，专门就是用来给一个键的值加一的，这个操作是原子性的，就是说哪怕一万个人同时点，它也能保证每个点击都准确地被记录一次,不会出现少计或者多计的情况。

我当时就想，这不正好就是我需要的吗？然后我就把统计逻辑改了，现在流程是这样的：当用户打开一篇文章的时候，我后端程序不再直接去折腾数据库了，而是直接向Redis发一个命令，比如INCR article:123:views，这里的article:123:views就像是给ID为123的文章的浏览量专门设的一个钥匙串，Redis接到这个命令，几乎是在一瞬间就把对应的值加了一，然后把结果返回给我，这个过程非常快,对网站的整体性能几乎没影响。

但是光把数记在Redis里还不行，因为Redis的数据是存在内存里的，万一服务器重启了，数据就全没了，那浏览量不就清零了吗？所以还得想办法把数据持久化，存到数据库里做长期保存，我又不能每次更新都去写数据库,那又回到老路了。

我想了个折中的办法，用定时任务来处理，我设置一个定时任务，每隔一段时间，比如半小时或者一小时，跑一次，这个任务干的事儿就是把Redis里所有文章的浏览量数据一次性读出来，然后批量更新到数据库里对应的文章记录上，这样，写数据库的操作就从原来高并发的“每次点击都写”，变成了低频率的“批量一起写”，数据库的压力就小太多了，虽然这会导致浏览量显示有半小时左右的延迟，但对我这个小博客来说，完全能接受,毕竟不需要实时精确到秒级。

还有一种情况是文章可能被缓存了，连后端程序都触发不了，这时候可以在前端页面加载时，用一小段JavaScript代码，发一个非常轻量级的请求（比如用图片像素信标或者一个简单的API请求）来触发这个INCR操作,这样也能把浏览量统计上。

用了Redis之后，感觉确实不一样了，最直观的就是网站再也不因为计数这个事卡顿了，变得很流畅，Redis本身也特别简单，安装配置不复杂，这几个命令一看就懂，没什么学习成本，内存消耗也很小，就是存一些键值对，一个浏览量数字占不了多少空间，这就相当于用了一个特别顺手的小工具,把一个烦人的性能问题轻松解决了。

我也知道这可能不是最完美无缺的方案，比如如果Redis服务器本身出问题了，那期间的计数可能会丢，但对于我这种个人项目，追求的就是一个简单高效，这个方案已经让我非常满意了，感觉用Redis来搞浏览量记录，确实是选对了路子,效率提升非常明显。