谈到流式计算，目前业内提到最多的应用应该就是Storm和Spark Streaming, 诚然二者都比较容易上手，很快帮你解决一些实际问题，但伴随着应用的深入，就会暴漏越来越多问题，比如Storm往往会将错误放大——集群节点中一个挂掉，会影响整个集群运行，SparkStreaming内存占用过大，内存泄漏，且依附于hadoop而不能独立部署应用等。遇到类似问题，对于初学者往往一筹莫展，因为面对的是一个黑盒。虽然可以看源代码，但代码冗长，不是短期内可以融会贯通。
我们使用Storm和SparkStreaming的初心是为了更好解决自己的流式计算需要，对于中小企业而言，往往业务需求很简单，因为解决一个简单的实际业务问题而搭建一套复杂的运行环境，给人一种“杀鸡用牛刀”之感。往往就解决问题而言，我们只需要按照原本朴实想法，简单解决问题即可。为此，这里借鉴作者曾开源的轻量级分布式实时计算框架light_drtc，给大家提供一个零基础构建轻量级高可用流式计算系统的方案。
这里我们定义：从信息流发源收集开始，到完成业务需求所需要近实时计算过程，至最终结果入库为一个完整的链条，以信息瀑布流模式，为大家介绍，整个系统可以分为三部分：数据收集、任务协调管理和任务计算，下面分别介绍下三部分所用相关技术。
- 数据收集CN：
信息流实时获取，可以考虑使用当下广为使用的MQ：Kafka或RabbitMQ，借助二者收集数据可以自动实现MQ数据收集的负载均衡。
每个数据收集节点都在借助Zookeeper监听任务管理节点的动态变化，以方便数据收集节点近实时将mini-batch数据流分发到有效任务管理节点，为保证数据计算方便，这里根据每条信息流的唯一标识ID哈希到指定任务管理节点。
数据收集部分可以借助当下广为使用的高效RPC服务：Thrift/Avro等将数据发送给任务协调管理节点；
- 任务协调管理AN（多主模式）：
任务协调管理节点在启动之初，就借助zookeeper完成对于数据收集部分的服务注册，并同时监听来自其所独立管辖的任务计算节点的动态变化，以方便实时调整计算任务分配。
每个任务协调管理模块在接受来自数据收集部分的实时信息流后，根据mini-batch思想，将数据简单加工后就分发给其管辖的任务计算集群，并根据任务计算返回结果控制是否重新计算等。
在流量高峰期，计算任务比较重，这时需要考虑借助内存和硬盘相结合方式，避免内存中信息流过大，按任务队列顺序执行相关任务。
任务协调管理部分同样借助当下广为使用的高效RPC服务：Thrift/Avro等将数据发送给任务计算节点；
- 任务计算：
任务计算部分在在启动之初，借助zookeeper完成服务注册，以方便任务协调管理部分动态监控和任务分发；单个任务计算节点对所收到的加工好的数据集，使用类似hadoop的map/reduce思想的fork/join完成相关计算，并将计算成功失败结果反馈给上游。
至于任务计算结果存储，可以根据实际需要，选择当下广为使用的Mongo3.x、Redis3.x、AeroSpike3.7.x或ElasticSearch5.x(可以当作一种支持多维度查询的NoSQL)。
以上部分为个人浅知拙见，更多详细信息可以参考作者出版的《分布式实时计算框架原理及实践案例》，希望本文对感兴趣的朋友有帮助，欢迎大家拍砖，多交流，谢谢！
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/255183.html