秒级百G日志架构
日志架构分为几个部分：
采集日志–》传输日志–》存储日志–》查询/展示日志
下面是一些日志架构。
文件日志存储
在小规模（个位数机器）、低并发的应用下，直接使用log4j/logback将日志输出到本地文件即可。
ELK三剑客
稍微常见的日志接收、存储和查询架构就是ELK（ElasticSearch、Logstash/Filebeat、Kibana）。
对于现成的开源框架，用得也挺广泛。
不过，当日志量很大时，硬件开销不容小觑。
基于MQ
比如使用Kafka，单台几十万的并发可以达到，压力在传输和存储上。
传输需要经过3次序列化和反序列化（采集时写入本地硬盘，进出MQ，入库）；存储一般用ES或HBase。
对于每秒上百G的日志，需要的机器至少上千台（根据硬盘写入速度200MB来算，几百G/s的日志量），这个开销也是很大的。
更精简的架构
- 减少传输量：压缩日志，一般能高达80%以上的压缩率
- 减少序列化次数：需要减少中转流程，采集完不用落盘，直接发送给日志处理服务
- 更强的存储数据库：列式存储的ClickHouse
下面可以实现一个简单的客户端和日志处理端：
- 日志发送客户端：基于UDP传输（节省传输量），需要考虑UDP最大传输量64KB，换HTTP传输。
- 日志处理服务：接收日志，写入ClickHouse
这是某东的日志处理架构，也算是与时俱进了。