顺序员快来学习缓存层场景实战数据采集—技术选型思绪及总体计划

shadow_hxx

技术选型思绪
按照以上业务场景，名目组提炼出了6点业务需要，并针对业务需要梳理了技术选型相干思绪。
1）原始数据海量：关于这一点，初步斟酌使用HBase进行耐久化。
2）关于埋点记载的申请响应要快：埋点记载办事会把原始埋点记载寄放在一个缓存层，以此包管响应疾速。对于这一点有多个缓存计划，稍后展开探讨。
3）可经过后盾查问原始数据：假如间接使用HBase作为查问引擎，查问速度太慢，所以还需求使用Elasticsearch来保留查问页面上作为查问前提的字段和流动ID。
4）各种统计报表的需要：数据可视化工具也有得多选择，好比Kibana、Grafana等，斟酌到使用进程的灵敏性，终究选择本人设计功用。
5）能按照埋点日志生成费用结算数据：将费用结算数据保留在MySQL中。
6）需求一个框架将缓存中的数据进行处置，并保留到Elasticsearch、HBase和MySQL中：由于业务有准实时查问的需要，所以需求使用实时处置工具。目前盛行的实时处置工具次要为Storm、Spark Streaming、Apache Flink这3种，稍后也会展开阐明。
初步架构图如图6-1所示。

? 图6-1 数据采集初步架构图
子细视察这张架构图，会发现图上还有两个中央打了问号，这是为何？这就波及接上去需求探讨的4个问题了。
使用甚么技术保留埋点数据的第一现场
目前对于疾速保留埋点数据的技术次要分为Redis、Kafka、当地日志这3种，针对这里的业务场景，名目组终究选择了当地日志。
那末，为何不使用Redis或Kafka呢？先来讲说Redis的AOF机制，这在写缓存那一章也有讲过。
Redis的AOF机制会耐久化保留Redis一切的操作记载，用于办事器宕机后的数据复原。那Redis何时将AOF落盘呢？
在Redis中存在一个AOF配置项appendfsync，假如appendfsync配置为everysec，则AOF每秒落盘一次，不外这类配置形式有可能会丧失一秒的数据；假如appendfsync配置成always，每次操作申请的记载都是落盘后再前往胜利信息给客户端，不外使用这类配置形式零碎运转会很慢。由于对埋点记载的申请要求响应快，所们该名目没有选择Redis。
接上去探讨一下Kafka的技术计划。
Kafka的冗余设计是每个分区都有多个正本，其中一个正本是Leader，其余正本都是Follower，Leader次要担任处置一切的读写申请，并同步数据给其余Follower。
那末Kafka何时将数据从Leader同步给Follower?Kafka的Producer配置中也有acks配置项，其值有3种。
1）acks=0：不等Leader将数据落到日志，Kafka间接前往实现信号给客户端。这类形式虽然响应快，但数据耐久化没有保障，数据假如没有落到当地日志，零碎就会泛起宕机，致使数据丧失。
2）acks=1：等Leader将数据落到当地日志，然而不等Follower同步数据，Kafka就间接前往实现信号给客户端。
3）acks=all：等Leader将数据落到日志，且等min.insync.replicas个Follower都同步数据后，Kafka再前往实现信号给客户端。这类配置形式下虽然数据有包管，但响应慢。
经过以上剖析能够发现，使用Redis与Kafka都会泛起问题。
假如想包管数据的牢靠性，必定需求就义零碎机能，那有无一个计划能够机能和牢靠性兼得呢？有。名目组终究抉择把埋点数据保留到当地日志中。
使用甚么技术采集日志数据到耐久化层
对于这个问题，最简略的形式是经过Logstash间接把日志文件中的数据迁徙到Elasticsearch，但会有一个问题：业务侧要求寄放Elasticsearch中的记载（包孕城市、性别、春秋等原始数据，这些字段需求调用业务零碎的数据进行抽取），而这些原始数据日志文件中并无，所以两头需求调用业务零碎来获得一些数据跟日志文件的数据合起来加工。基于这个缘故，名目组并无选择间接从Logstash到Elasticsearch。
假如坚持经过Logstash把日志文件的数据迁徙到Elasticsearch，这里分享3种完成形式。
1）自定义Filter：先在Logstash自定义的Filter（过滤器）里封装业务数据，再保留到Elasticsearch。由于Logstash自定义的Filter是使用Ruby言语编写的，也就是说需求使用其余言语编写业务逻辑，所以此次名目中Logstash自定义Filter的计划被排除了。
2）修正客户真个埋点逻辑：每次记载埋点的数据发送到办事端以前，先在客户端将业务的相干字段提掏出来再上传到办事端。这个办法也间接被业务端否决了，理由是前期业务侧每更新一次后盾查问前提，就需求从新发一次版，真实太费事了。
3）修正埋点办事真个逻辑：每次办事端在记载埋点的数据发送到日志文件以前，先从数据库获得业务字段组合埋点记载。这个办法也被办事端否决了，由于这类操作会间接影响每个申请的效力，直接影响用户体验。
此外，没有选择用Logstash间接保留到耐久化层还有两点缘故。
1）日志文件中的数据需求同时到Elasticsearch和HBase两个输入源，因Logstash的多输入源基于同一个Pipeline（管道），假如一个输入源犯错了，另外一个输入源也会犯错，即二者之间会相互影响。
2）MySQL中需求生成费用结算数据，而费用结算数据需求经过剖析埋点的数据来静态计算，显然Logstash其实不合用于这样的业务场景。
在此处的业务场景中，名目组终究抉择引入一个计算框架，此时全部解决计划的架构如图6-2所示。

? 图6-2 基于Logstash的数据采集架构
这个计划就是先经过Logstash把日志文件迁徙到MQ中，再经过实时计算框架处置MQ中的数据，最初保留处置转换失掉的数据到耐久层中。
实际上，引入实时计算框架是为了在原始的埋点数据中填充业务数据，并统计埋点数据生成费用结算数据，最初分别保留到耐久层中。
最初，对于Logstash还需求强调几点。
Logstash零碎是经过Ruby言语编写的，资源损耗大，所以民间又推出了一个轻量化的Filebeat。零碎能够使用Filebeat采集数据，再经过Logstash进行数据过滤。假如不想使用Logstash的弱小过滤功用，能够间接使用Filebeat来采集日志数据发送给Kafka。
但问题又来了，Filebeat是使用轮询形式收集文件变化信息的，存在一定延时（有时分很大），不像Logstash那样可间接监听文件变化，所以该名目终究选择持续使用Logstash（资源损耗在可承受规模内）。
接上去分别探讨Kafka和散布式实时计算框架。
为何使用Kafka
Kafka是LinkedIn推出的开源动静两头件，它天生是为采集日志而设计的，并且具备超高的吞吐量和数据量扩展性，被称作有限沉积。、
按照LinkedIn的民间引见，他们使用3台廉价的机器部署Kafka，就可以每秒写入两百万笔记录，如图6-3所示。

图6-3 民间引见
为何它的吞吐量这么高？这里引见一下Kafka的存储构造。先看一张民间文档给出的示用意，如图6-4所示。
Kafka的存储构造中每个Topic分区至关于一个巨型文件，而每个巨型文件又是由多个Segment小文件组成的。其中，Producer担任对该巨型文件进行“程序写”，Consumer担任对该文件进行“程序读”。
这里能够把Kafka的存储架构简略了解为，Kafka写数据时经过追加数据到文件末尾来完成程序写，读取数据时间接从文件中读，这样做的益处是读操作不会梗阻写操作，这也是其吞吐量大的缘故。

? 图6-4 Kafka的存储构造
此外，实践上只有磁盘空间足够，Kafka就能完成动静有限沉积，因此它特别合适处置日志采集这类场景。
使用甚么技术把Kafka的数据迁徙到耐久化层
为了把Kafka的数据迁徙到耐久层，需求使用一个散布式实时计算框架，缘故有两点。
1）数据量特别大，为此需求使用一个处置框架来将上亿的埋点数据天天进行疾速剖析和处置（且必需使用多个节点并发处置才来得及），再寄放到Elasticsearch、HBase和MySQL中，即大数据计算，因此它有散布式计算的诉求。
2）业务要求实时查问统计报表数据，因此需求一个实时计算框架来处置埋点数据。
目前盛行的散布式实时计算框架有3种：Storm、Spark Stream、ApacheFlink。那末使用哪一个更好呢？
这3种均可以选用，就看公司的详细状况了。好比公司曾经使用了实时计算框架，就再也不需求斟酌这个问题；假如公司尚无使用，那就看集体爱好了。
笔者更喜爱用Apache Flink，不只由于它机能强（阿里采取这项技术后，流动期间一秒内可以处置17亿条数据），还由于它的容错机制能包管每条数据仅仅处置一次，并且它有时间窗口处置功用。
对于流处置的容错机制、时间窗口这两个概念，详细展开阐明一下。
在流处置这个过程当中，往往会诱发一系列的问题，好比一条动静的处置过程当中，假如零碎泛起毛病该怎么办？会重试吗？假如重试会不会泛起反复处置？假如不重试，动静是不是会丧失？能包管每条动静至多或至少处置几回？
在不同流处置框架中采用不同的容错机制，可以包管纷歧样的统一性。
1）At-Most-Once:最多一次，表现一条动静不论后续处置胜利与否只会被消费处置一次，存在数据丧失的可能。
2）Exactly-Once:准确一次，表现一条动静从其消费到后续的处置胜利只会产生一次。
3）At-Least-Once：最少一次，表现一条动静从消费到后续的处置胜利可能会产生屡次，存在反复消费的可能。
以上3种形式中，Exactly-Once无疑是最优的选择，由于在正常的业务场景中，个别只有求动静处置一次，而Apache Flink的容错机制就能包管一切动静只处置一次（Exactly-Once）的统一性，还能包管零碎的平安性，所以得多人终究都会使用它。
接上去说说Apache Flink的时间窗口计算功用。下列是Apache Flink的一个代码示例，它把每个小时里产生事情的用户聚合在一个列表中。

日志中事情产生的时间有可能与计算框架处置动静的时间纷歧致。
假设实时计算框架收到动静的时间是2秒后，有一条动静中的事情产生时间是6:30，因接纳到动静后处置的时间延后了2秒，即变为了6:32，所以当计算6:01~6:30的数据和时，这条动静其实不会计算在内，这就不合乎实际的业务需要了。
在实际业务场景中，假如需求根据时间窗口统计数据，往往是按照动静的事情时间来计算。Apache Flink的特性偏偏是使用了基于动静的事情时间，而不是基于计算框架的处置时间，这也是它的另外一个撒手锏。总体计划此时全部架构设计计划如图6-5所示。
这个架构的流程如下。
1）后盾办事端会记载一切的申请数据，寄放到当地的日志文件。
2）使用数据采集框架Logstash，从日志文件抽取原始的日志数据，不加
工间接寄放到Kafka傍边。3）经过Apache Flink从Kafka中拉取原始的日志数据，而且通过业务加工，分别寄放到Elasticsearch、HBase和MySQL中。
4）Elasticsearch用来处置用户针对申请日志的查问申请，它将查问症结字段的值和申请ID寄放到索引中，跟进查问症结字获取后果ID的列表，再经过后果ID去HBase中获得具体的申请数据。

? 图6-5 数据采集总体计划
5）MySQL寄放一些组合加工后的数据，用来做结算，结算的数据查问和处置申请量不大。
小结
本篇并无讲授特别深化的架构设计方面的留意事项，而是次要论述技术选型面前的思考进程，但愿对架构思惟的晋升有所帮忙。
后面几篇已有相似的场景，所以本篇没有具体讲授技术运用面前的场景。
学架构的进程就是阅历一些根底的场景，而那些繁杂的场景实际上是简略场景的叠加复用。因此，之后关于对比简略或后面曾经讲过的场景仅会简略引见，以留出更多的篇幅来说解其余首要常识。这样做可能会让前面的内容有些干燥，但置信看到这里的读者曾经能够带着对场景的了解和思考去排汇相干的常识了。
回到这个架构自身。计划落地当前，丢数据的状况其实不多，并且其架构的扩展性也很好，之后日活达到了几千万，零碎依然能够使用，固然，仍是要多加机器，而且按时清算一些旧的原始数据。写缓存引见过，写缓存不克不及解决两个问题，一个就是长时间高并发写数据，这在本章失掉理解决。此外一个就是高并发且这些并发申请需求抢资源的状况，这就是下篇波及的内容了。
接上去开始讲授秒杀架构。秒杀架构是一个综合性十分强的问题，而且在面试时常常被问到，所以是很首要的场景。
本文给大家讲授的内容是缓存层场景实战，技术选型思绪及总体计划
下篇文章给大家讲授的内容是缓存层场景实战，秒杀架构，业务场景：设计秒杀架构必知必会的那些事以及总体的思绪感觉文章不错的敌人能够转发此文关注小编；感激大家的反对！

华人澳洲中文论坛

热图推荐

顺序员快来学习缓存层场景实战数据采集—技术选型思绪及总体计划

发表回复

shadow_hxx
关注TA

图文推荐

华人澳洲中文论坛

热图推荐

顺序员快来学习缓存层场景实战数据采集—技术选型思绪及总体计划

发表回复

shadow_hxx 关注TA

图文推荐

shadow_hxx
关注TA