欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

分布式系统开发小结

Java Web water 2768℃ 0评论

用最简单的语言梳理一下最近十天做的分布式系统模块的开发。这是一个还在开发中的项目,配图也是设计原图。希望能更多地从开源项目里汲取营养,一边实战,一边积累。

系统概述

最近在设计和开发一个分布式系统的流式处理模块,整个系统用于跨集群、跨机房搬运不同数据源内的数据到另一份或多份数据源上,包括HDFS、
MySQl、MongoDB、FTP等。功能比较像Hadoop的Sqoop,但是能扩展支持更多的数据源,且本身是个集群部署,不像Sqoop需要依赖
Hadoop的MR。

我们整个cluster的资源管理借助Mesos来完成,由自己定制的Mesos Scheduler向Mesos
Master申请可用的资源,具体把数据搬运的任务分发到Mesos
Slave的Executor上,而我主要负责的就是Slave模块,包括Slave上Executors的实现、不同Slave上Executor之间
的通信、消息处理、每次Task的容错和可靠性等内容。

Executor设计

一共有三种Executors,简单分为Input、Cache、Output,直观理解Input就是读取数据源,Cache用于从input到output的缓存,Output是获取cache里的数据,向目标数据源

导出数据。

Executor具体涉及到下面一些问题:

1.      Executor之间的网络通信

2.      数据流里每个Tuple在网络中的序列化、压缩等流通问题

3.      消息队列

4.      其他:多线程、双队列缓存设计、状态记录等

我们还具体考虑了Input、Cache、Output分别挂掉要怎样继续去执行整个数据流的搬运,这里涉及到了把一些描述和状态更新统一写到Zookeeper里,需要Cache模块做对消息的钝化/checkpoint/JournalLog。

整个模块的设计图如下:

网络通信

Netty有很优雅的设计,封装了Java的网络NIO接口,还重写了ChannelBuffer。利用Netty框架,Executors之间的通信简化为下面这样的模式:

我今天参考了Storm0.9.0里新增加的Netty模块,优化了下Slave模块里的Netty部分。其实Storm里的Netty部分蛮简单,比较我们想要做的实现更简单,主要体现在两处:

1.  Cache作为Netty Server,既要接收InputClient的写,又要接受OutputClient的读请求。

2.  Cache交互的Queue不是一个java concurrent包里的某个Queue容器,而是一个轻量级的workqueue:beanstalkd

消息队列

采用的是beanstalkd,每个tube对应一个output,之前的博文介绍了beanstalkd。

数据流通

数据的序列化和反序列化,本来想要使用kryo这样的在开源软件中经常见到的高效工具。后来参考了Storm里的TaskMessage结构,发现
不如直接把POJO设计成一个byte[],自己定义一下byte数组的结构来的更高效。毕竟一个java对象转bytes,再高效也不如直接拼
byte[]快。

数据压缩方面Snappy有很快的压缩速度。

Storm设计参考

其实我们的Input比较像Storm的spout,Cache和Output比较像bolt,但是又没有Storm里的shuffle
grouping等机制,Input与Cache是指定的一对一的,Cache与Output是一对多,而这些对应关系会在物理执行计划模块里生成。

在Storm的设计里,参考了它的Acker。Storm能保证消息不会丢失,并且每条消息都会被完整处理,即这个tuple以及由这个tuple所导致的所有的tuple都被成功处理。而一个tuple会被认为处理失败了如果这个消息在timeout所指定的时间内没有成功处理。能做到这点,他的Acker起到了很重要的作用。(Arker模块的设计和源码分析)

我们打算做一个Acker模块,但消息的执行状态和更新会写在znode上,让Arker模块与ZK打交道,然后去更新Beanstalkd里已经reserve了的job。有时间还要把Storm的源码和模块仔细读读,尽量能多参考一些设计思路。

转载请注明:学时网 » 分布式系统开发小结

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!