用最简单的语言梳理一下最近十天做的分布式系统模块的开发。这是一个还在开发中的项目，配图也是设计原图。希望能更多地从开源项目里汲取营养，一边实战，一边积累。
系统概述
最近在设计和开发一个分布式系统的流式处理模块，整个系统用于跨集群、跨机房搬运不同数据源内的数据到另一份或多份数据源上，包括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的源码和模块仔细读读，尽量能多参考一些设计思路。
(全文完)