0%

【监控】InfluxDB 的集群化方案调研

InfluxDB 本身其实是支持集群化的,但是开源的是不支持的。对于开源的 InfluxDB ,怎么去做到集群化?这里找了点相关的资料。

阿里巴巴

阿里的集群化方案就是改了源码。采用的是业内的 ETCD/Raft 方案。他们采用了ETCD/Raft作为核心组件,移除了原生的snapshot过程。同时放弃原生的日志文件部分WAL,而改用自研方案。也就是他们的HybridStorage 方案(Raft日志模块)。即:内存与文件混合存取,内存保留最新热数据,文件保证全部日志落盘,内存、文件追加操作高度一致。

具体的可参考:阿里云InfluxDB® Raft HybridStorage实现方案

参考

阿里云InfluxDB®高可用设计

阿里云InfluxDB® Raft HybridStorage实现方案

其他公司

携程的方式就比较通俗易懂,他并没有对 InfluxDB 去做源码上的修改,而是对 InfluxDB 进行了包装。在 InfluxDB 做了一层代理,通过这个代理将数据分发到各个 InfluxDB上去。

官方开源 InfluxDB-Relay

  1. 采用双写仅仅解决了数据备份的问题,并未解决 influxdb 读写性能的问题;
  2. 只是写入了数据,查询还是需要去读 influxdb。增加了配置文件的复杂度不易维护;
  3. 并未对写入失败的数据做任何重试机制的处理。

饿了么

优势:

  1. influx-proxy 是饿了么在 influxdb-relay 满足不了其性能要求、配置维护要求痛定思痛后重构的产物;
  2. influxdb 机器支持动态扩缩;
  3. 增加了强大的请求失败后的重试机制。

劣势:

  1. 架构中使用的组件较多,增加了使用者的学习成本,且不易于后期的维护;
  2. 请求失败重试本身是双刃剑,试想机器性能达到极限,重试无形中又增加了机器的负载;
  3. 与自身场景需求不相符,我们内部只是做监控数据的持久化存储,应该是最简单的接入和与 influxdb 最小的架构改造。

360的HA方案

参考

360 influxDB 集群模式实践

携程

携程新一代监控告警平台 Hickwall 架构演进

这是打赏的地方...

本文标题:【监控】InfluxDB 的集群化方案调研

文章作者:Mr.Sun

发布时间:2020年07月30日 - 09:40:36

最后更新:2020年08月03日 - 09:31:21

原始链接:http://www.blog.sun-iot.xyz/posts/97c09d65

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

---------Thanks for your attention---------