大屏技术演进-拉模式

1、背景

产品经理：咱们要实现以下的一个形以下图的一个大屏需求，目前咱们全部的日志数据都在库里面，应该不是很难吧

图片来源与网络，若是侵权请及时联系删除

技术小哥哥：嗯，难道是不难，我要回去看看日志的数据量，而后再制定对应技术方案，而后在一块儿评审，接下来就是作需求分析和技术方案了。

这种技术需求应该在一些to b的公司业务是比较常见的，很荣幸本身参与系统的大屏从1.0到2.0的升级操做

2、需求分析

与前端定义格式

一期由于时间关系，就采用的是http+json定时拉取的方式获取，这个方式在不少场景下面是很是好的，由于http协议成熟与稳定，json格式比较大众，如今基本的语言都支持对应的编码操做。

后端技术方案

1. 每次请求直接从日志表来进行数据获取。
2. 使用脚本将日志数据生成一份基础数据，而后给前端直接调用。
3. 用消息队列进行订阅/推送模式，增长一个新的topic供大屏业务使用，后续与第二个方案差很少，也是生成一个基础数据存储在库里面。
4. 根据页面的条件，生成每一个组合条件的数据供前端调用，这里会借助redis来进行存储，至于为何使用redis，这里不进行介绍了，社区有不少关于redis介绍文章。

1-3其实均可以理解为一种拉模式，由于都是在请求时候进行前端数据的组合，至于2-3仅仅是将数据进行压缩减少，好比减少到分钟级别，毕竟通常日志数据都是秒级别的。

4实际上是一种推模式，若是直接使用http，在后台逻辑是拉，对于前端也是拉，这种方案通常会使用websocket进行推模式的获取，这个会在 下一篇 文章进行描述

3、技术方案制定

本篇文章不会有代码实现来作，由于讲原理方案，任何后端语言都是能够拿来实现的。

一、前端请求，后端直接拉日志数据统计

    优势：

• 简单方便，能够直接发起ajax请求就能够获取数据
• 后端也方便，而且不须要改动太多原来的表存储方法，不须要扩展表数据

    缺点：

• 数据量大，就会知道你是在考验数据库的承受能力了
• 条件太多状况下，及时你设置了每一个条件模块的缓存，可是大屏数据及时性比较高，缓存命中率低，因此这个方案下面缓存设置没有太多意义

    流程图：

    流程说明：

1. 终端进行日志请求上报，请求的日志通过赞成网关的认证以及基础的字段校验，校验经过后将数据写入到消息队列里面。
2. 开启一个消费者，持续消费消息队列里面数据，将消息队列的数据异步写入到数据库里面，这里使用异步消费其实就是将大量并发的终端请求作一个控制处理，防止大量请求直接穿透到数据库，数据库资源在整个系统架构中是比较宝贵的，最好不要由于请求的激增出现宕机状况。
3. 前端大屏发起数据请求，直接到咱们的web服务器，web服务器经过反向代理方式给到咱们服务端业务逻辑服务器，服务端业务逻辑服务器直接从数据库拉取数据分析聚合再返回

二、后端使用脚本生成每分钟数据，供前端接口调用

    优势：

• 简单方便，能够直接发起ajax请求就能够获取数据

• 会比上面的方案少不少数据，特别是在每分钟密集型日志上，由于原来一分钟估计会有1w条记录，而用异步脚本生成后就是一条了，在后续的前端请求逻辑上，作出的响应会更及时。

    缺点：

• 须要额定扩展一张统计表，有维护额外统计表的成本
• 这里只是减小了数据的一个条数，当业务需求须要到秒级别的时候，这个方案又是一个积累的存在了

   流程图：

流程说明（与第一个在收集过程一致，再也不赘述）：

• 当日志收集入库后，咱们会有定时脚本任务将日志的数据读取出来进行分析聚合存储到咱们的统计表里面。
• 前端的逻辑在请求过来后，就不会在日志库进行读取了，而是直接去了已经统计好的数据表，这个统计好区别后面文章说的按条件区分好的统计数据。

三、消息队列方式进行异步统计数据，供前端接口调用

    优势：

• 前端层面来说，调用仍是比较方便的
• 由于是异步进行数据统计，因此不会影响总体的前端请求的响应时间，对应cpu和内存占用暂时不在这考虑，这里主要是由于进程间已经隔离

    缺点：

• 与第二个同样，须要增长一个统计表，对于统计表的维护问题
• 这里也是减小了数据的个数条数的问题，对于产品来说，时间粒度更改成每秒，整个表的统计粒度就gg了
• 增长了消息队列组件，整个系统架构上会复杂一点，固然如今通常系统消息队列是标配了，因此这个缺点也是最不起眼的缺点了

    流程图

    流程说明：

1. 收集与第一个方案不同在于，咱们同时会入两个队列，固然在一些支持多播的消息队列彻底能够共用哈，固然若是是服务化架构的话，统计与收集应该不会同一个服务了
2. 统计队列的消费者获取到数据后，进行统计逻辑直接入了统计表，供前端接口来调用。

4、总结

• 咱们这里都没有使用缓存来作一些防止数据穿透问题，固然在现实方案部署确定有缓存来作，这里没作是由于对于总体方案架构来说没必要过于复杂了，固然在大屏的需求上，其实前端请求的缓存么有太大做用，咱们要的基本是实时数据，而缓存基本都是历史的数据
• 总体的三个方案，咱们第一期选择的是第二个方案，第一个太过于简单粗暴了，数据库扛不住；固然第三个其实与第二个也差很少，若是需求要求比较准确点的话，好比要精确到秒，第三个也是能够的，而咱们需求恰好是精确到分，这就不必每一个日志来都要进行数据统计操做
• 世界上没有最优的方案，只有最适合需求的技术方案，固然需求不合理，仍是能够好好反驳的。

5、思考

• 咱们这篇文章基本用的是拉数据方式，能够理解为，咱们的前端须要的数据逻辑都是在请求同步来获取的，若是这个大屏条件比较单一，其实这个方案是没有太大问题的，毕竟简单一点，因此咱们定义为1.0版本方案。
• 那么若是咱们有条件选择呢？若是咱们要看： 24小时数据 、1小时数据 、30分钟数据，这是咱们下一期须要讲的一个技术方案，期待咱们的新技术方案