《分布式》专题

在介绍GraphX之前，我们需要先了解分布式图计算框架。简言之，分布式图框架就是将大型图的各种操作封装成接口，让分布式存储、并行计算等复杂问题对上层透明，从而使工程师将焦点放在图相关的模型设计和使用上，而不用关心底层的实现细节。 分布式图框架的实现需要考虑两个问题，第一是怎样切分图以更好的计算和保存；第二是采用什么图计算模型。下面分别介绍这两个问题。 1 图切分方式 图的切分总体上说有点切分和边切

我正在使用ehcache（2.10.1）和terracotta（开源4.3.1）实现分布式缓存。我在单台机器上尝试了两个JVM实例和一个terracotta服务器，代码按预期工作，没有错误。 现在，我尝试运行相同的terracotta服务器，但在虚拟机上使用客户端。在虚拟机上运行客户端时，会收到以下消息和错误： 使用的 tc-config.xml 文件： 使用的 ehcache.xml 文件： 在

两阶段提交协议 通常在复杂场景下是不推荐使用的，除非是非常简单的场景，非常容易提供回滚，而且依赖的服务也非常少的情况。 这种实现方式会造成代码量庞大，耦合性高。而且非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。 本地消息表 这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一

链接 Web API Controllers 动态WebApi层 集成OData 集成Swagger UI ASPNET Core 集成OData

分布式事务基于 JTA/XA 规范实现 1。 两阶段提交： 1. 本功能暂未实现 ↩

集群聚合模块。聚合某集群下的所有机器的某个指标的值，提供一种集群视角的监控体验。 服务部署 服务部署，包括配置修改、启动服务、检验服务、停止服务等。这之前，需要将安装包解压到服务的部署目录下。 # 修改配置, 配置项含义见下文 mv cfg.example.json cfg.json vim cfg.json # 启动服务 ./open-falcon start aggregator # 检查lo

nodata用于检测监控数据的上报异常。nodata和实时报警judge模块协同工作，过程为: 配置了nodata的采集项超时未上报数据，nodata生成一条默认的模拟数据；用户配置相应的报警策略，收到mock数据就产生报警。采集项上报异常检测，作为judge模块的一个必要补充，能够使judge的实时报警功能更加可靠、完善。 服务部署 服务部署，包括配置修改、启动服务、检验服务、停止服务等。这之前

如果您没有遇到机房分区问题，请直接忽略此组件。 如果您已经遇到机房分区问题、并急需解决机房分区时监控数据回传的问题，请使用该组件。更多的资料在这里。

task是监控系统一个必要的辅助模块。定时任务，实现了如下几个功能： index更新。包括图表索引的全量更新 和 垃圾索引清理。 falcon服务组件的自身状态数据采集。定时任务了采集了transfer、graph、task这三个服务的内部状态数据。 falcon自检控任务。 源码编译 # update common lib cd $GOPATH/src/github.com/open-falco

alarm模块是处理报警event的，judge产生的报警event写入redis，alarm从redis读取处理，并进行不同渠道的发送。 设计初衷 报警event的处理逻辑并非仅仅是发邮件、发短信这么简单。为了能够自动化对event做处理，alarm需要支持在产生event的时候回调用户提供的接口；有的时候报警短信、邮件太多，对于优先级比较低的报警，希望做报警合并，这些逻辑都是在alarm中做的

Judge用于告警判断，agent将数据push给Transfer，Transfer不但会转发给Graph组件来绘图，还会转发给Judge用于判断是否触发告警。 设计初衷 因为监控系统数据量比较大，一台机器显然是搞不定的，所以必须要有个数据分片方案。Transfer通过一致性哈希来分片，每个Judge就只需要处理一小部分数据就可以了。所以判断告警的功能不能放在直接的数据接收端：Transfer，而

环境准备 请参考环境准备 创建工作目录 export HOME=/home/work export WORKSPACE=$HOME/open-falcon mkdir -p $WORKSPACE cd $WORKSPACE 克隆前端组件代码 cd $WORKSPACE git clone https://github.com/open-falcon/dashboard.git 安装依赖包 yum

api组件，提供统一的restAPI操作接口。比如：api组件接收查询请求，根据一致性哈希算法去相应的graph实例查询不同metric的数据，然后汇总拿到的数据，最后统一返回给用户。 服务部署 服务部署，包括配置修改、启动服务、检验服务、停止服务等。这之前，需要将安装包解压到服务的部署目录下。 # 修改配置, 配置项含义见下文, 注意graph集群的配置 mv cfg.example.json

graph是存储绘图数据的组件。graph组件 接收transfer组件推送上来的监控数据，同时处理api组件的查询请求、返回绘图数据。 服务部署 服务部署，包括配置修改、启动服务、检验服务、停止服务等。这之前，需要将安装包解压到服务的部署目录下。 # 修改配置, 配置项含义见下文 mv cfg.example.json cfg.json vim cfg.json # 启动服务 ./open-fa

transfer是数据转发服务。它接收agent上报的数据，然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件。 服务部署 服务部署，包括配置修改、启动服务、检验服务、停止服务等。这之前，需要将安装包解压到服务的部署目录下。 # 修改配置, 配置项含义见下文 mv cfg.example.json cfg.json vim cfg.json # 启动服务 ./