去哪儿网MySQL日志分析实践，80%数据丢失都给你救回来( 二 ) _MySQL日志

文章插图

如果采用方案一，会增加 Sniffer 端的不可控性，这与我们之前设计的尽可能减少 Sniffer 端资源消耗的初衷相违背，所以我们选择方案二。

七、设计

1、整体流程

整体流程设计如下所示：

文章插图

2、模块划分

文章插图

所有模块的目标：高性能、高可用、高扩展。

3、dubaiMeta

1）说明

由于基础服务不能提供高性能的 IP-AppCode 映射信息的接口，需要自行实现这一功能。对接基础服务的 IP-AppCode 映射信息提供的接口，实时从 Kafka-OPS 队列中获取 IP-AppCode 映射变更的信息流，Merge 到当前数据，并提供 IP-AppCode 信息的接口；

2）设计

由于 dubaiMeta 是提供基础信息的接口，访问量比较大，需要提供高性能、高可用、高扩展性，故 dubaiMeta 需要尽可能设计成为无状态的服务。

将所有的 IP-AppCode 映射数据存储在 MySQL，映射为最新版本。所有的 IP-AppCode 变更历史也都会存储在 MySQL 。通过版本信息持续将 IP-AppCode 变更信息 Merge 到最新版本。目前 IP-AppCode 数据整体体量不大，可以在服务内部缓存，不使用其他缓存。这样既可以减少网络和缓存的请求，降低请求耗时，也会避免因对缓存的依赖而导致的性能和可用性问题。这样 dubaiMeta 就可能成为一个接近无状态的服务。

单个请求如果不能命中缓存则会请求基础服务的 IP-AppCode 接口，并将变更数据 Merge 到缓存。但是单个 dubaiMeta 节点数据变更之后如何与其他 dubaiMeta 节点通讯最后达到所有节点数据一致？

有两种方案：

文章插图

尽可能保证单个节点的高性能的，并检测单个节点的数据一致性延迟，将有问题的服务及时下掉，通过这个方法可以尽可能减低数据不一致带来的问题。故选择【变更通知】的方式；

3）启动流程

文章插图

服务启动时首先从 Kafka-OPS 持续订阅信息流，所有变更信息 Merge 到内部缓存，然后再从 Self-Kafka-OPS 中持续订阅变更信息流，所有变更信息 Merge 到内部缓存，最后从 MySQL 中获取全量的数据信息，将所有数据 Merge 到缓存，组合成全量的数据。等到所有数据 Merge 完成，并且两个 Kafka 队列无堆积时，再提供服务。

4）性能分析

目前基础信息的数据量不大，可以在服务内部缓存，不使用其他缓存。既可以减少网络和访问缓存的耗时，大幅度降低请求的耗时，又可以避免因对缓存的依赖而导致的性能和可用性问题。

单节点 IP-AppCode 映射变更会发起变更通知，异步通知其他节点，无需感知其他节点存在，故性能可以得到保证。

5）可用性分析

dubaiMeta 目前所有数据存储在本地缓存，在 MySQL 中存储一份副本和变更信息流。

由于 dubaiMeta 是接近无状态的，部署多个节点，通过负载均衡服务下发到不同的节点就可以保证整体服务的可用性。

MySQL 通过平台已有的 HA，保证可用性；

6）扩展性分析

由于 dubaiMeta 是接近无状态的，故可以横向扩展，不对其他节点产生影响，只需要在负载均衡器上添加节点即可。

4、SnifferServer

1）说明

从 Kafka-Sniffer 队列获取日志数据，在日志中补充各种业务信息，并聚合数据。最后将聚合之后的结果批量写入到 Clickhouse 中。

由于队列中的数据量比较大，无法全量存储所有数据，需要按照一定的维度聚合数据。通过降低聚合比(聚合之后的数据条数/聚合之前的数据条数)可以降低总体数据量，在保证性能的前提下尽可能缩短入库的时间。

由于 Clickhouse 是 OLAP 分析类型的列式数据库，更推荐批量写入的方式提高数据库的写入性能(每次不少于 1000 条) 。

2）设计

针对单个队列，可以使用多个 SnifferServer 使用同一个 consumerGroup 消费数据，保证消费者的性能、可用性，同时 SnifferServer 也具备了一定的扩展性。