最近分布式系统开发小结
2013-12-27 22:19
295 查看
用最简单的语言梳理一下最近十天做的分布式系统模块的开发。这是一个还在开发中的项目,配图也是设计原图。希望能更多地从开源项目里汲取营养,一边实战,一边积累。
我们整个cluster的资源管理借助Mesos来完成,由自己定制的Mesos Scheduler向Mesos Master申请可用的资源,具体把数据搬运的任务分发到Mesos Slave的Executor上,而我主要负责的就是Slave模块,包括Slave上Executors的实现、不同Slave上Executor之间的通信、消息处理、每次Task的容错和可靠性等内容。
导出数据。
Executor具体涉及到下面一些问题:
1. Executor之间的网络通信
2. 数据流里每个Tuple在网络中的序列化、压缩等流通问题
3. 消息队列
4. 其他:多线程、双队列缓存设计、状态记录等
我们还具体考虑了Input、Cache、Output分别挂掉要怎样继续去执行整个数据流的搬运,这里涉及到了把一些描述和状态更新统一写到Zookeeper里,需要Cache模块做对消息的钝化/checkpoint/JournalLog。
整个模块的设计图如下:
我今天参考了Storm0.9.0里新增加的Netty模块,优化了下Slave模块里的Netty部分。其实Storm里的Netty部分蛮简单,比较我们想要做的实现更简单,主要体现在两处:
1. Cache作为Netty Server,既要接收InputClient的写,又要接受OutputClient的读请求。
2. Cache交互的Queue不是一个java concurrent包里的某个Queue容器,而是一个轻量级的workqueue:beanstalkd
数据压缩方面Snappy有很快的压缩速度。
在Storm的设计里,参考了它的Acker。Storm能保证消息不会丢失,并且每条消息都会被完整处理,即这个tuple以及由这个tuple所导致的所有的tuple都被成功处理。而一个tuple会被认为处理失败了如果这个消息在timeout所指定的时间内没有成功处理。能做到这点,他的Acker起到了很重要的作用。(Arker模块的设计和源码分析)
我们打算做一个Acker模块,但消息的执行状态和更新会写在znode上,让Arker模块与ZK打交道,然后去更新Beanstalkd里已经reserve了的job。有时间还要把Storm的源码和模块仔细读读,尽量能多参考一些设计思路。
(全文完)
系统概述
最近在设计和开发一个分布式系统的流式处理模块,整个系统用于跨集群、跨机房搬运不同数据源内的数据到另一份或多份数据源上,包括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的源码和模块仔细读读,尽量能多参考一些设计思路。
(全文完)
相关文章推荐
- 最近分布式系统开发小结: Slave模块Executors设计
- 最近要读NET Distributed Applications这本书,并做学习笔记.系统地学习一遍分布式应用程序开发和设计
- 最近开发的系统-BOSS宽带工单系统小结(1)-- 工单系统
- 勤哲excel服务器开发实施管理系统的一点小结
- 软件合作开发:2012年年底给苏州工业园区某家软件企业实施C#.NET软件开发系统框架的经验小结
- 分布式开发——JAVA自身系统通信方式
- 关于近期HBase系统设计开发和性能调优的一些小结
- 最近开发的基于Excel的考试系统---VBA
- 分布式系统开发调度技术
- Linux环境下段错误的产生原因及调试方法小结 最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是
- 最近有点忙,忙着自己的安卓系统官网的开发,后面在做总结这两个月的学习
- 面向对象的分布式开发系统 (一)
- 给分布式系统开发新人的建议
- mapreduce程序开发及伪分布式调试小结
- 大数据教程(3.9):zookeeper分布式应用系统服务器上下线动态感知程序开发_
- day26 分布式监控系统开发
- 最近开发一个SQL server大数据量统计系统的经验总结(转)
- 分布式系统的开发经验与心得
- 基于HLA/RTI的分布式作战仿真系统开发过程
- SpringBoot36-分布式系统开发-spring cloud2