一次 MySQL 调优经历

最近有一个朋友遇到一个问题,就是突然之间网站的响应时间变成了秒级,而且 MySQL 占用了大量的 CPU 资源。具体如下图: CPU 资源占用: 响应时间: 可以看到这一个很明显的异常值。所以,我就开始排查。一切都是常规的思路,连上服务器,然后看看当前都是些什么任务。 当前任务: 可以看到,基本上所有的 query 都是在等待表锁。然后查了下这张表的表结构,还有 select 和 update 的执行情况。 表结构: SELECT 语句执行情况: 以 SELECT x FROM xx WHERE ( vote_id = xx ) AND ( token = ‘xx’ ) AND ( wecha_id = ‘x’ ) LIMIT 1 为例 可以看到虽然是走了索引,但是依旧是扫描了 3w 多行数据。加上之前等待锁的时间。最后造成的问题就是,这个简单的 select 就已经花了3秒时间。 仔细研究了这几个出现最多的语句,发现这个和他们最近上线的一个投票业务相关。所以这个,可以断定就是有人在刷票。当然,最佳的方案就是,在前端代码加上防刷机制,比如 ip 校验什么的。 但是考虑到当时的情况。改代码这个基本就是不现实的处理方法。因为时间来不及。而且代码是第三方的,修改起来难保全无错误。…

Hexo 博客加密插件简述

众所周知,Hexo 是一个很赞的静态博客系统。但是,他有一个很大的缺陷,就是无法对文章进行加密处理。比如,我想对一篇文章做权限控制,例如提问回答可见等等。所以,这就产生了一个这样的需求。 虽然我不是一个 Hexo 用户,但是,看到这样的知乎问答: 我只想说,不想一想实现就直接说不可以的,都不是程序员,一点创造性都没有。顺便吐槽下知乎这个社交平台。 说正事。这个插件的主要用途就是为博客加密,使用方法很简单,这边就不详细描述,因为还有一些没有完善的地方,先期的文档在这:GITHUB 原理 其实说穿了,也很简单。因为 Hexo 是纯静态博客系统,所以不可能采用后台密码校验的方式进行处理。所以这个校验就落到了前端上。但是,如果直接 js 进行密码校验,这就好像,我把钥匙放在钥匙孔里,然后对小偷说,你看,我锁好了。 所以这边只可能采用密文的方式,这边感谢开源,这边我使用的是 brix / crypto-js 项目,进行博客加密。加密方式选用的 AES,这个基本可以确保拦截住 99% 的用户了。 有个小细节,就是考虑到中文,我这边是先进行 Base64 编码,然后再 AES,防止出现中文的坑。 遇到的坑和 TODO 就是 Hexo 在执行 generate 的时候,并不一定会触发 “after_post_render” 事件。只有当文章内容改动和新建文件的时候,才会触发。这个被坑了一下。 现在,模板是直接写在代码里的,当时并没有考虑自定义,这个之后会写成 template 方式。 先凑个数,等刷完了 TODO,再来发布 1.0.0 版本