接着之前爬抖音的数据讲

参数破解后的持久化工作

在成功破译了抖音请求的加密参数（主要是 x-gorgon ）之后，首先是通过 go 编写程序不断的监控直播间，获取直播间信息、观众信息，差不多启了 100 多的 go 的监控程序，部署在 4 台服务器上（ go 程序开销是真滴小， java 哭晕在厕所）。

这是数据爬取方面的。

我编写的后端程序用来持久化 100 多个 go 监控程序发来的信息，我这边还要在 redis 里建个池子来保存正在监控的直播间 id ，供 go 程序获取，整体设计还是比较复杂的。

由于我们需要爬取的数据越多越好，那么当然希望持久化接口的 QPS 越大越好，但是后端持久化接口的处理速度会越来越慢（数据库里的数据越来越多，插入更新速度减慢），导致之后的 QPS 也随之降低。

但其实服务器的 cpu 利用率只有 10%~20% ，很显然服务器没使出来全部性能。之后这里我用了消息队列，创建了几十个消费者去做持久化工作（其实也就相当于多线程吧），接口的 QPS 也确实上来了，服务器 cpu 的利用率也上来了。

看着数据库表里的数据量每天增长几百万，一遍高兴，一遍也开始焦虑起来，那就是也查询越来越慢了。

binlog撑爆了服务器硬盘？

程序还没跑个几天，发现 redis 出问题了，接口报错，远程 redis 连接不上。

我登陆服务器查看了日志后发现程序一直在报 redis 无法持久化数据的错（我开启了 redis 的持久化，就是没空间了），我就纳闷了，我输入df -h一看磁盘容量，我去，Avail 没了？？

并且发现 mysql 占用了几乎 90% 的容量，我立马去 mysql 目录下查了一下发现了大批大批的 binlog 文件，一个就 1G ，原来是这玩意把服务器磁盘撑满了。

之后把老的 binlog 清除了之后程序算是恢复正常了。8.0的数据库是默认开启 binlog 的，而且为了之后配置主从我还是打开了 binlog ，只不过设置了一个过期时间是1天，这样应该就没有磁盘方面的问题了。

查询优化

虽然配置了主从复制和读写分离，但其实感觉还是有些治标不治本，查询速度仍然没有上来。

之后使用了EXPLAIN看了一下执行计划，发现 type 竟然是 ALL！哎呦，我真是老糊涂忘记加上索引了

但是 WHERE 中是一个 BETWEEN AND 范围查询，即使给字段加了索引，有时候走索引（type是range），有时候不是，这个调研了之后看有说是 mysql 会基于查询的条数来判断范围查询是否会走索引，看来这个还是个概率问题。

当我们的单表数据量快要达到两千万的时候我们的策略是直接水平分库，保证表结构不变，把新数据直接持久化到新的数据库中，然后保证每次单表达到一千万左右的时候就换新库。（因为我们每次需要的是近1天的数据，老数据几乎不用）

目前的一个查询速度还算乐观，导出10w条数据在几秒钟的时间。

后续策略——ClickHouse

当然虽说老库的数据不用了，但是万一使用了就麻烦了，我需要根据查询条件定位到特定的数据库，这块肯定还需要去配置 sharding-jdbc ，但是这块的查询时间还有待考量。

我的一个想法是使用ClickHouse，一个面向列的非关系型数据库，把原先mysql中的多个表冗余为一张宽表（避免 ck 的关联查询），然后把老数据转移到 ClickHouse 中进行查询分析，这样便不用担心数据量和查询时间的一个问题，绝对比 MySQL快，而且不是一丁点。

（当然这一块还需要去学习实践再落地。）