系统架构简述

写在最前

此处省略许多字......

Paste_Image.png

重要说明

1. 由于模块较多，其中除了hive模块没有使用Redis，其它模块都使用了Redis，但是只画出了重要的连线。
2. 除Hive模块之外，其它所有模块都使用了数据库，也只画出了重要部分连线。
3. Web、Storm、Parse、Thrift都使用了Zookeeper，也只画出了重要部分连线。
4. 数据库集群也有另外几种数据库，这里统称为DDB Cluster。
5. 图中的协议Flume代表使用Flume作为收集源文件内容的工具。
6. API针对APP使用SDK的手机用户，WEB模块针对接入SDK的开发者用户，图中没有做详细区分。

数据流

1. 手机客户端请求API，经过负载均衡器到达API。为了尽可能降低API的响应时间，API直接使用异步IO的方式，把请求中的消息批量的发给Kafka集群。
2. JMS批量的从Kafka取消息进行消费，并进行相应的处理；处理完成后，把处理结果采用固定格式的方式打到日志文件中。然后，Flume Agent增量的收集日志文件内容，并发给Kafka集群的另一个Topic，同时在Hadoop集群中也存放一份作为备份。在打日志的过程中，同时会把数据插入到HBase一份，目的是：作为出问题时的数据恢复。
3. Storm集群从Kafka的Topic中取消息进行消费，经过Spout和Bolt的处理后，把统计结果存放到Redis中； Web模块查询Redis中数据展示给用户。
4. Schedule定时任务定时的从Redis中同步数据到数据库中或者从数据库中缓存数据到Redis中。
5. Web模块调用Parse（解析模块）、NCS（搜索模块）、Thrift（某服务远程调用）展示界面给浏览器用户。
6. KPI模块每天定时统计系统数据，汇总展示给KPI系统使用者。
7. Hive模块使用hive脚本，利用HBase中的数据进行故障时的数据恢复。
8. Zookeeper集群作为服务协调和某些服务的负载均衡器。
9. 数据库使用M-S模式。

写在最后

该吃饭了...... 88