高并发（ 6M/s）日志数据如何准实时入库（ MySQL）
iyaozhen · iyaozhen · 2016-03-03 13:55:42 +08:00 · 18157 次点击这是一个创建于 3198 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前已经使用 filebeat+logstash 将线上的实时请求日志推送到了 Redis （ list 数据结构做队列） 中。但现在的处理瓶颈卡在了从 Redis 里面取数据做聚合然后入库这步了。
因为数据聚合处理使用的是 Redis 的 hash 数据结构做计数器，需要和 Redis 有几次交互，单个脚本的处理速度为 0.03M/s （已经优化过了），开 200+ 个进程数据聚合这块应该是抗的住的。
一开始使用的方案是每个脚本缓存数据然后达到一定数量（比如 10w 行）后批量解析然后 insert 入库，但因为用的是myisam存储结构（这里有两个原因： 1.机器磁盘不大节省空间 2.数据需要做统计 count(*)等操作用的比较多），写入数据时会锁表，后来又分库（ 4 个库）分表（ 100 个表）。这个解决方案抗了一段时间后数据量增长又不行了（ redis 队列里面的数据处理没有增加快）。
后来想想批量解析和入库这里比较耗时间会阻塞脚本继续读取 Redis 中的数据。就想把解析入库的操作异步出来，这时想了一个办法是把 10w 行日志写文件，然后把文件的路径放到另一个队列里面去，起一些脚本解析文件入库。但我还是想得太简单了，数据量太大了，写的文件太多直接把测试虚拟机的 inode 用完了，机器直接蒙逼了。当然可以 50w 、 100w 行写一次文件，但这感觉不是根本的解决之道，还会带来其它问题（比如单个脚内存消耗过大）。
我感觉我这些解决方法还是太落后了，不知道大神们有没有什么解决方案。
PS ：脚本是用的 PHP ， Python 、 Go 都可以，不过我感觉这个问题应该不是语言的问题。
为了防止我跑偏，说一下核心需求：准实时根据请求参数等聚合统计数据（用于了解线上实时情况做监控），较低延迟（ 30min 内）将这些数据入库（每个日志都带有 logid ，用于定位问题）。
 |
1
fds 2016-03-03 14:14:17 +08:00
有必要写入数据库么？ logstash 做些统计，把结果数据发送到 influxdb 什么的记录下来，显示在监控里就好了吧？非得存原始数据入库？
|
 |
2
jimrok 2016-03-03 14:22:04 +08:00
让数据库直接 load 数据会快很多，没有事务的保护。
|
 |
4
swolf119 2016-03-03 14:25:11 +08:00
同感觉没必要入库，从上文来看，感觉入库的需求就是为了数据统计
那么数据统计是直接读的 mysql 分析的吗 |
 |
5
iyaozhen OP @jimrok 这个我也想过。但是还是数据量太大暂存的文件太多（应为分库分表了， load 的时候需要按库和表把文件生成好），会把磁盘的 inode 用完。
|
 |
6
kier 2016-03-03 14:29:16 +08:00
对 elk 不了解，我们是吧数据存入 mongodb 的，然后脚本定时统计结果，将结果数据入 mysql, 然后定期将 mongo 中的老的日志数据导出备份；
|
 |
8
lxf1992521 2016-03-03 14:30:09 +08:00
根据我的经验，可以使用 graylog+elasticsearch 试试；
性能数据可以直接通过 graylog 的 RestAPI 获取，对应日志可以直接从 ES 文档数据库中获取； |
 |
9
yahoo21cn 2016-03-03 14:30:30 +08:00
数据库改成事务，弄一个 redis 队列存插入数据，单独一个进程每秒读取该进程一次写入数据库。
|
|
11
iyaozhen OP @lxf1992521 非常感谢，已经在看 elasticsearch 了，其实我也是用的 ELK 这一套，只是因为一些历史原因，只用了一部分。 graylog 这还没接触过，我看看。
|
|
12
iyaozhen OP @yahoo21cn 用 myisam 存储的原因我已经说了， innodb 也试过，主要还是数据占用磁盘空间大，统计慢。「单独一个进程每秒读取该进程一次写入数据库。」我现在就是这样，已经 300+的进程在跑， redis 还是爆了。我不光是要入库，还要做一些实时聚合。
|
 |
13
lynnworld 2016-03-03 14:38:38 +08:00
你的 insert 是批量 insert 的么，现在是解析耗时还是存入耗时多？
|
|
14
kier 2016-03-03 14:41:00 +08:00
对了，你们的日志是 nginx 或者 webapp 的请求处理日志，还是业务的埋点数据？
|
 |
15
tabris17 2016-03-03 14:41:12 +08:00
看来你需要的是 spark
|
|
16
fds 2016-03-03 14:42:14 +08:00
定位问题的话直接用 lnav 扫 log 不就行了？真的有必要数据库查询吗？
elasticsearch 比较吃配置哦。 有钱的话，直接上 http://www.splunk.com/ 其实你想用到数据库的什么功能呢？一些查询除非预先 index ，否则和直接遍历文本相比没有特别的优势呀。 |
|
17
iyaozhen OP @lynnworld 是批量的。两者都比较多。抱歉，这里没做具体的统计。
因为是批量解析 10w 条日志，还要分库分表。其实单次 insert 还比较快，但并发高，数据库会锁表，有些请求就等待了。 |
|
20
iyaozhen OP @fds 线上几十上百台机器，还在不同机房，每个机器还有 10+的模块，还是比较蛋疼，而且还要其它一些需求，比如定位查询结果可视化等。
|
 |
21
zhicheng 2016-03-03 14:54:30 +08:00
1. 优化写入，优化一下 MySQL 的参数，甚至极端一些关掉日志等。
2. 优化计算，聚合计算和数据存储分开，保存聚合计算的结果，在这个结果之后做增量计算。 3. 精度换速度，自己实现聚合函数，提供几个关键词， bloomfilter, hyperhyperlog 。 |
|
22
lynnworld 2016-03-03 15:17:59 +08:00
话说 6m 是 6 百万条日志嘛？那一天不都有上千亿日志了。平均日志大小是多少啊？
|
|
23
kier 2016-03-03 15:36:14 +08:00
6 兆吧，一条日志就算有 200 字节，那么大概 3W 条每秒？
|
 |
24
solupro 2016-03-03 15:39:29 +08:00
/dev/shm ， load data infile 不知道能扛多少
|
 |
26
zeeler 2016-03-03 16:00:43 +08:00
日志建议用 mongodb 之类的 nosql 数据库
|
 |
28
wweir 2016-03-03 16:13:56 +08:00 via Android
MySQL 有一个存储引擎是专门干日志这些个破事的。叫 Archive ，可以尝试一下。
话说存这些个死的数据，直接压缩一下放那多好。非要存数据库，还非要要关系型数据库。 |
 |
29
vus520 2016-03-03 16:19:56 +08:00
elk ，生产中 10 台服务器，两个 logstash 可以做到 4k 左右的写入速度
|
 |
30
ango 2016-03-03 16:26:53 +08:00
多级（如： IP/date/module/……）划分目录，直接同步到一台日志文件服务器（硬盘大、内存大），不管你是要定位或者清洗什么数据，直接 python 或者 shell 脚本定制，这样的处理挺快的，后期将定制基本集中起来做个管理化系统。
目前对于上百台服务器程序输出的日志，这样使用还没发现什么不方便或者大问题。 |
 |
33
xgdyhaiyang 2016-03-03 16:27:59 +08:00
之前用 C 写过一个专门往 MYSQL 写日志的系统，支持自定义配置字段，支持自动分表和按自然时间切换表，支持缓存批量入库，支持队列抵御高峰。，支持删除过期数据。
https://github.com/haipome/logdb 之前测试过 MYSQL 用 myisam 存储引擎，每秒中写几万条没有问题的，一天 10 亿应该也扛得住。 |
 |
34
yuankui 2016-03-03 16:28:56 +08:00
我们的日志规模,现在是每秒 4 万条
用的 ELK 消息队列用的是 kafka,redis 不靠谱! 后来 logstash 出现了严重的性能问题,cpu 占用超过应用本身,我们又用 Java 语言重写了 logstash(没用实现 DSL),性能提高了 10 倍. 现在系统没啥压力. 不够话说性能指标相关的,完全可以 metrics+influxdata+grafana 来做,可以大大减少数据量的存储 |
 |
36
realpg 2016-03-03 16:31:56 +08:00
|
|
39
realpg 2016-03-03 16:43:41 +08:00
|
|
40
lynnworld 2016-03-03 16:55:27 +08:00
"
因为数据聚合处理使用的是 Redis 的 hash 数据结构做计数器，需要和 Redis 有几次交互，单个脚本的处理速度为 0.03M/s （已经优化过了），开 200+ 个进程数据聚合这块应该是抗的住的 " 假设 3w 记录 /s ， redis 估计也要 10w+的 qps 了。看能不能优化计算流程。 |
 |
41
hanwujibaby 2016-03-03 17:44:34 +08:00
redis 在内存占用率比较高的情况下不太稳定，切到 kafka 之类的，数据的聚合可以在内存中算，不用放到数据库中再聚合。看下 spark 或者 storm 吧。
|
 |
42
9 2016-03-03 19:13:36 +08:00
数据入 es ，用 es 的 api 做统计，统计后的数据入回 mysql ，不要直接入库到 mysql ，这是坑啊
|
 |
43
publicAdmin 2016-03-03 19:20:48 +08:00
对的。楼上 @9 的方案和我们之前处理方式一样。 用户打点数据，个人觉得你直接丢 mysql 无形中在给你自己增加压力，入库读库都存在风险，何不如丢类似于 es / hdfs/ influxdb 之类的天生自带索引查询的。
|
 |
44
wusuopuBUPT 2016-03-03 19:38:15 +08:00
这种场景已经不适合 mysql 了，我们的数据处理流程是：
flume 采集->kafka 队列->ETL 清洗->HDFS 存储->Hive 查询->BI 系统 |
|
45
wusuopuBUPT 2016-03-03 19:39:57 +08:00
上面是离线(非实时)的方案， 实时系统也在调研，一般会在 kafka 后面接入 storm/spark 做流式实时计算
|
 |
46
a591826944 2016-03-03 19:47:07 +08:00
之前做过类似的。不过不是日志。。就是用户的点击数据。
因为是 http 请求。 php 接收 -> rabbitMQ -> storm -> mysql 每天 3 亿左右 。。没达到你那么高。。。 |
 |
47
RangerWolf 2016-03-03 21:09:52 +08:00  1
我这边的解决方案是 Cassandra 集群~ 一开始不熟悉的话在设计表结构上是个大坑
熟悉之后，还需要配上 Spark 集群来进行计算。 当然两边的配合又是一个大坑 在搜索的时候，还需要让 Cassandra 加上 lucene 插件，不是官方推荐的 Solr 想简单可以试试 Cassandra 官网推广的 DSE 。 初创企业（年利润 300M 美刀以内）没有 license 的问题~ 最高试过 3.9W 写请求 /s 不知道你说的 6M/s 是大小 6MB 还是 600W 的写请求~ 如果是后者，爱莫能助啦~ |
 |
48
chendahui007 2016-03-03 21:31:30 +08:00
以前搞过 ELK ， 之前用 mongo ，也用过 mysql ，都不合适，建议 E 。 E 够强大，适合存储日志，如果用上 kafka ，还可以订阅日志
|
|
49
tabris17 2016-03-03 21:36:03 +08:00
其实我在想，用 zmq 自己写一个分布式日志处理程序也不是太复杂
|
 |
50
lujiajing1126 2016-03-03 21:51:18 +08:00 via iPhone
elk 。。队列可以选 kafka 。事实查询用 e 。同步写到 hbase 也可以做离线分析。。似乎用 storm 的也有
|
 |
51
xhat 2016-03-03 23:32:07 +08:00
为什么没人提到 leveldb ？
|
 |
52
msg7086 2016-03-04 02:00:14 +08:00
|
 |
53
zuo 2016-03-04 02:59:14 +08:00
既然用上了 logstash 为什么不一步到位 输出到 Elasticsearch ，可以满足你后期的日志查询。做分析可以顺便把日志输出到 hdfs ，然后在结合 spark 或者 hadoop
|
 |
54
cobopanda 2016-03-04 09:27:29 +08:00
用 ES 试试吧
|
 |
55
firefox12 2016-03-04 11:15:51 +08:00
如果数据库本身不是问题的话， 插入是美问题的。
但是你 6M/s 按照你的量 6*3600*24 /1024 每天 500G, 数据库会迅速垮掉 ，完全是个错误的设计。 如果是在线查 log 的话， es 会好一点。 这种应用用 mysql 去做 并不好，统计应该靠应用去做。 |
 |
56
gushan 2016-03-08 14:39:47 +08:00
日志数据直接存储 MySQL 在后期扩展还是有问题的，可以考虑下阿里云日志服务。
1 ）提供了简单接入客户端（ https://yq.aliyun.com/articles/3228?spm=5176.team4.teamshow1.37.faH93Z ） 2 ）日志收集到服务端后提供多种消费方式：数据通道（类 Kafka ）/数据投递（ ODPS 、 OSS-组合 E-MapReduce Spark ）/实时搜索（ https://help.aliyun.com/document_detail/sls/user-guide/overview.html ） |
 |
57
wujunze 2016-06-09 21:06:01 +08:00
Spark 你值得拥有!
|
 |
58
sumonian 2017-12-01 14:09:40 +08:00
elk 值得你拥有
|
 |
59
jemygraw 2018-07-11 18:51:39 +08:00
你前端不应该用 redis，应该用 kafka。或者直接用七牛日志平台吧。
|
 |
60
PoetAndPoem 2019-02-20 15:51:07 +08:00
@xgdyhaiyang 你好，那轮子中文介绍打不开，不知道怎么使用
|
Select Language