京东App秒级百G日志传输存储架构设计与实战( 四 ) _架构

1）集群高可用架构
EasyOLAP部署CH集群是三层结构：域名 + CHProxy + CH节点，域名转发请求到CHProxy ，再由CHProxy根据集群节点状态来转发。CHProxy的引入是为了让Query均匀分布在每个节点上，，并对CHProxy做了一定的改进，自动感知集群节点的状态变化。

文章插图

多条件查询控制台控制台比较简单，主要就是做一些sql语句查询，做好clickhouse的高效查询，这里简单提一些知识点。
做好数据的分片，如按天分片。用好prewhere查询功能，可以带来性能的提升。做好索引字段的设计，譬如检索常用的时间、pin 。
细节难以尽述，要从百亿千亿数据中，做好极速的查询，还需要对clickhouse的一些查询特性有所了解。
下图界面展示的即为一些索引项，点击查看详情，则从数据库捞出压缩过的数据，此时才解压并展示给前端。查看链路，则是该次请求中，整个链路用户打印的log（包括线程池内的）。

文章插图

文章插图

总结与对比我们可以简单的做一些对比，主要在于硬件成本和软件性能的对比。

文章插图

从上文可知，磁盘的占用原始方案占用了磁盘（1份）， MQ（2份），数据库（1份）。而在新的方案中，磁盘的占用仅剩下clickhouse的（0.8份）， clickhouse自身又对数据做了压缩，实际占用空间不到入库容量的80% 。
那么仅磁盘即可节省75%以上的存储成本。
大家都知道，秒级的吞吐量，是伴随着服务器Cpu的耗费的，并不是说只给个大硬盘，即可一台服务器每秒吞吐1个G的。每台服务器秒级的吞吐量是有上限的，秒级占用磁盘的上升，即对应Cpu数量的上升，要支撑一秒1G的磁盘写入，需要5台或以上的服务器。

文章插图

那么在磁盘的大幅节约下，线性地节省了大量的中间过程Cpu服务器。实际粗略统计效果，流程中服务器可节约70%以上。
在软件性能上，过程很好理解。对Client端的消耗主要就是序列化、写磁盘、读磁盘、反序列化这几步的消耗， Udp则仅有一步序列化。我们假设MQ集群是有无限的写入能力，可以吞下所有的发过去的日志，那么就是worker端的消费性能对比。
从MQ拉取并消费，这个过程如果MQ没有积压，则有零拷贝在支撑高速的拉取，如果积压了，则可能产生大量的MQ磁盘IO ，拉取速度会大幅下降。这个过程效率会明显低于Udp发送到worker的处理效率，而且占用双份的网络带宽。实际表现上， worker表现出的强劲性能，较之前单条拉取MQ集群时，消费性能提升在10倍以上。
本文到此就结束了，主要简略介绍了一个新的日志搜集系统（用户跟踪框架）的设计方案，以及该方案能带来的巨大的成本节省。相关代码日后会开源于"gitee.com"的京东零售账号下，届时有相关需求的同学可以加以关注。

【京东App秒级百G日志传输存储架构设计与实战】