技术选型是什么(程序员快来学习缓存层场景实战数据收集—技术选型思路及整体方案)
Posted
篇首语:学向勤中得,萤窗万卷书。本文由小常识网(cha138.com)小编为大家整理,主要介绍了技术选型是什么(程序员快来学习缓存层场景实战数据收集—技术选型思路及整体方案)相关的知识,希望对你有一定的参考价值。
技术选型是什么(程序员快来学习缓存层场景实战数据收集—技术选型思路及整体方案)
技术选型思路
根据以上业务场景,项目组提炼出了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所示。
仔细观察这张架构图,会发现图上还有两个地方打了问号,这是为什么?这就涉及接下来需要讨论的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所示。
这个方案就是先通过Logstash把日志文件迁移到MQ中,再通过实时计算框架处理MQ中的数据,最后保存处理转换得到的数据到持久层中。
实际上,引入实时计算框架是为了在原始的埋点数据中填充业务数据,并统计埋点数据生成费用结算数据,最后分别保存到持久层中。
最后,关于Logstash还需要强调几点。
Logstash系统是通过Ruby语言编写的,资源消耗大,所以官方又推出了一个轻量化的Filebeat。系统可以使用Filebeat收集数据,再通过Logstash进行数据过滤。如果不想使用Logstash的强大过滤功能,可以直接使用Filebeat来收集日志数据发送给Kafka。
但问题又来了,Filebeat是使用轮询方式采集文件变动信息的,存在一定延时(有时候很大),不像Logstash那样可直接监听文件变动,所以该项目最终选择继续使用Logstash(资源消耗在可接受范围内)。
接下来分别讨论Kafka和分布式实时计算框架。
为什么使用Kafka
Kafka是LinkedIn推出的开源消息中间件,它天生是为收集日志而设计的,而且具备超高的吞吐量和数据量扩展性,被称作无限堆积。、
根据LinkedIn的官方介绍,他们使用3台便宜的机器部署Kafka,就能每秒写入两百万条记录,如图6-3所示。
为什么它的吞吐量这么高?这里介绍一下Kafka的存储结构。先看一张官方文档给出的示意图,如图6-4所示。
Kafka的存储结构中每个Topic分区相当于一个巨型文件,而每个巨型文件又是由多个Segment小文件组成的。其中,Producer负责对该巨型文件进行“顺序写”,Consumer负责对该文件进行“顺序读”。
这里可以把Kafka的存储架构简单理解为,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中获取详细的请求数据。
5)MySQL存放一些组合加工后的数据,用来做结算,结算的数据查询和处理请求量不大。
小结
本篇并没有讲解特别深入的架构设计方面的注意事项,而是主要阐述技术选型背后的思考过程,希望对架构思维的提升有所帮助。
前面几篇已有类似的场景,所以本篇没有详细讲解技术应用背后的场景。
学架构的过程就是经历一些基础的场景,而那些复杂的场景其实是简单场景的叠加复用。因此,之后对于比较简单或前面已经讲过的场景仅会简单介绍,以留出更多的篇幅来讲解其他重要知识。这样做可能会让后面的内容有些枯燥,但相信看到这里的读者已经可以带着对场景的理解和思考去吸收相关的知识了。
回到这个架构本身。方案落地以后,丢数据的情况并不多,而且其架构的扩展性也很好,之后日活达到了几千万,系统仍然可以使用,当然,还是要多加机器,并且定时清理一些旧的原始数据。写缓存介绍过,写缓存不能解决两个问题,一个就是长期高并发写数据,这在本章得到了解决。另外一个就是高并发且这些并发请求需要抢资源的情况,这就是下篇涉及的内容了。
接下来开始讲解秒杀架构。秒杀架构是一个综合性非常强的问题,并且在面试时经常被问到,所以是很重要的场景。
本文给大家讲解的内容是缓存层场景实战,技术选型思路及整体方案
- 下篇文章给大家讲解的内容是缓存层场景实战,秒杀架构,业务场景:设计秒杀架构必知必会的那些事以及整体的思路
- 觉得文章不错的朋友可以转发此文关注小编;
- 感谢大家的支持!
相关参考
数控车床切槽程序(零基础学习UG编程,数控编程与操作,车削技术实例)
今天小编一刀流为大家整理出了一个编程与操作的实战案列,供大家在学习中参考学习毛坯为ф22×80一、教学目的1、能根据零件图确定切槽程序编制的方法。2、合理选择切槽的方法。3、能应用合理的方法保证槽的精度。4、遵守...
正在打游戏,突然提示内存不足。这满满的伤害值,分分钟心碎成渣好嘛,而且有时候会造成APP不能使用。这个时候,我们需要清理手机内存空间,以达到能够使用。那么有哪些小技巧能帮助我们清理手机里的垃圾释放空间呢?...
数据透视表缓存是数据透视表的内存缓冲区,每个数据透视表在后台都有一个内存缓冲区,一个内存缓冲区支持多个数据透视表共享。Excel基于同一个数据源创建的多个数据透视表,默认情况下都是共享缓存的,共享缓存有如下...
我的兄弟姐妹们(八一校的兄弟姐妹们,我收集了你们这么多的照片快来认领——)
八一校的兄弟姐妹们扶庆浪我们是一群50年代、60年代,雪域高原西藏军人的子女。我们曾经是新中国的第一批留守儿童。我们从小就生活在一起。从部队的婴儿室、保育院到八一校,我们都吃、住、学习、成长在一起。我们喝...
搅拌机由什么组成(简单易懂:反应釜搅拌器的分类与选型,还有特点)
...处理的非常到位,143各化工标准全面的讲述了化工领域的技术规范,资料收集不易,大家可以下载学习。化工标准规范部分内容截图化工标准规范部分内容截图部分资料下载完整版涵盖焦化、化工领域的学习资料包步骤1、评论/...
楼房移动(“随申办”移动端最新推出“我要租房”服务专题,需要租房的市民朋友快来体验)
...办理流程,在市住建委、市房管局牵头下,市大数据中心技术和平台支撑下,“随申办”微信小程序、“随申办”APP和支付宝小程序三端同步上线“我要租房”服务专题,全市房源“一键查询”,市场化租房、保障性租赁住房“...
旅游景区评定标准最新(快来领取5A旅游景区数据及A级景区创建、评级相关资料)
海鳗云分享社基于互联网公开内容,已收集若干文旅行业资料,近期新增乡村振兴、体育、酒店、露营等资料,将持续更新~国家5A级旅游景区国家5A级旅游景区是中国旅游景区的最高等级,是代表中国世界级精品的旅游风景区...
西装三件套,顾名思义,是指由西装外套、马甲和西裤三者组成的三件套服装。那么,穿着西装三件套都有哪些学问和讲究呢?今天就让我们一起来看看吧~西装三件套代表的不仅是穿搭时尚,更是一种对服装文化的认同,一种...
西装三件套,顾名思义,是指由西装外套、马甲和西裤三者组成的三件套服装。那么,穿着西装三件套都有哪些学问和讲究呢?今天就让我们一起来看看吧~西装三件套代表的不仅是穿搭时尚,更是一种对服装文化的认同,一种...
汽包差压水位计工作原理(锅炉汽包水位测量系统,你不知道的21条冷知识,快来一起学习)
...动,且应防止拒动优先的原则。锅炉汽包水位测量系统的选型,应能确保从锅炉投入主燃料起就能投入工作(包括保护)。锅炉汽包水位测量系统的配置,应采用两种或两种以上工作原理共存的配置方式。锅炉汽包水位测量系统...