摘要

本博文将详细的介绍本人在实现过程中的所经历的项目，同时对象将进行的详细的说明。将对项目的背景，项目的技术，项目的架构设计，项目的难点，项目的开发周期，项目中详细的功能的开发，项目中本人的主要工作，本人的工作价值，以及项目未来的规划与设计。当然，本博文中的对实习的项目都是经过脱敏处理和相关的删减设计，不涉及公司版权等相关信息。

项目的背景

项目技术

项目系统架构设计

项目主要功能的设计

项目的难点

项目开发周期

项目个人主要工作

项目未来的规划与设计

博文参考

项目背景：

该项目中小企业的提供虚拟桌面架构，远程办公，私有云相关服务。与VBlock和VxRack一起搭建一套完整的企业级别的解决方案，通过VMware Vcent实现统一的管理同时还提供企业的复制和保护能力。Vxrail是以集群节点的形式组成。整个系统中我们负责的是集群节点的管理系统和集群以及集群节点的监控系统的后台的开发。我们团队负责是的负责负责是Vxrail系统中的后台系统业务的开发，我们团队负责的项目是集群节点的管理系统和监控系统的业务的开发。数据的采集使用的是Flume海量日志采集系统，消息队列采用的是kafka集群。数据存储采用的是的Hbase数据库。关系型数据库mysql集群。系统业务开发采用的Springboot+springcloud的微服务开发。

我的工作：

1利用Flume系统采用日志数据，并将日志数据存储到kafka中。

2日志数据的分析，提取相关的业务的数据。存储到Hbase数据库中。

3 将Hbse的数据提取系统业务所需要的数据表，存储在Mysql集群中。

4 利用基于springboot+Springcloud的微服务做相关业务的开发。

5 Dokcker的构建和服务的相关的部署。

项目背景：

由于Vxrail系统是以集群的形式存在的，系统每一天都会集群节点都会产生很多数据，利用产生的海量数据实现对集群节点的管理和监控。集群系统中需要定时定期的对已有数据进行离线的分析处理，例如节点状态，磁盘容量，……等，将这些数据采集好，存储在数据库中，并为系统微服务提供数据支持。让用户能够更好的对集群节点的进行管理。

项目的架构：

项目亮点：

1数据的采集:数据采集面的的问题：1数据源多种多样。2数据量大。3变化快。4如何保证数据采集的可靠性的性能。5如何避免重复数据。6如何保证数据的质量。

2 Kafka的消息集群：消息的不丢失消息的不重复消费。

3 数据清洗的部分：相关的数据处理的算法。针对系统所需要的数据进行相关的ETL的处理

4 hadoop的数据处理的部分：数据的倾斜，hadoop的业务分析。

5 Springboot的微服务的构建：服务的高可用，服务的问题，系统的优化。

1数据的采集的过程

数据采集是的：服务集群节点的相关参数：节点的主板参数CPU的参数，内存参数，网络参数磁盘容量参数，进程数线程，I/O参数网络安全相关参数……通过这些参数来实时对戴尔用户的所购买的私有云服务提供实时的管理和监控，并采用的机器学习系统来根据节点历史运行数据来预测未来一段时间的集群节点的转态，保证集群及节点的稳定的运行并提供一整套解决方法的系统。

数据的采集利用的是是专业永久大数的采集的工具：Flume

针对业务数据进行埋点，将配置flume的采集的路径，将采集的数据的存储到相关的kafka消息集群中，提供给整个系统的数据消费。

Flume能够实时采集数据就是的利用了异步的多线程的来感知是否有数据的变化。

2Flume 的 Source， Sink， Channel 的作用？

1、Source 组件是专门用来收集数据的，可以处理各种类型、各种格式的日志数据，包括 avro、 thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、 legacy。

2、Channel 组件对采集到的数据进行缓存，可以存放在 Memory 或 File 中。

3、Sink 组件是用于把数据发送到目的地的组件，目的地包括 HDFS、 Logger、 avro、thrift、 ipc、 file、 Hbase、 solr、自定义。

我公司采用的 Source 类型为（1）监控后台日志： exec（2）监控后台产生日志的端口： netcat Exec spooldir

3Flume数据的采集的问题

Flume 的事务机制（类似数据库的事务机制）： Flume 使用两个独立的事务分别负责从

Soucrce到Channel，以及从 Channel 到 Sink 的事件传递。比如 spooling directory source为文件的每一行创建一个事件，一旦事务中所有的事件全部传递到 Channel 且提交成功，那么 Soucrce 就将该文件标记为完成。同理，事务以类似的方式处理从 Channel 到 Sink 的传递过程，如果因为某种原因使得事件无法记录，那么事务将会回滚。且所有的事件都会保持到 Channel 中，等待重新传递。

4Flume 采集数据会丢失吗?

根据 Flume 的架构原理，Flume 是不可能丢失数据的，其内部有完善的事务机制，Source 到 Channel 是事务性的， Channel 到 Sink 是事务性的，因此这两个环节不会出现数据的丢失，唯一可能丢失数据的情况是 Channel采用 memoryChannel， agent 宕机导致数据丢失，或者 Channel 存储数据已满，导致 Source 不再写入，未写入的数据丢失。Flume 不会丢失数据，

但是有可能造成数据的重复，例如数据已经成功由 Sink发出，但是没有接收到响应， Sink 会再次发送数据，此时可能会导致数据的重复发出去到kafka中。在kafka中的解决消息重复的方式是：消息使用的唯一的Id 来标识。消息可以使用唯一id标识，生产者（ack=all 代表至少成功发送一次) ，消费者（offset手动提交，业务逻辑成功处理后，提交offset）

落表（主键或者唯一索引的方式，避免重复数据），业务逻辑处理（选择唯一主键存储到Redis或者mongdb中，先查询是否存在，若存在则不处理；若不存在，先插入Redis或Mongdb,再进行业务逻辑处理）。

5为啥Flume和kafka的连接来采集日志呢？

1 kafka的对日志的采集不便于操作sources源种类不多。但是Flume可以有很多sources

2有多个业务线，增加业务的时候，不支持动态添加。但是Flume可以支持动态数据的添加，kafka但是能让消息保存7天。而且在不修改的时候可以不修改数据的副本数据，减少内存。

3 Flume提供了kafka的相关组件，能够很方便的实现日日志的数据的采集提供给多个业务数据做处理。

6Flume 参数调优

1. Source

增加 Source 个（使用 Tair Dir Source 时可增加 FileGroups 个数）可以增大 Source 的读取数据的能力。例如：当某一个目录产生的文件过多时需要将这个文件目录拆分成多个文件

目录，同时配置好多个 Source 以保证 Source 有足够的能力获取到新产生的数据。

batchSize 参数决定 Source 一次批量运输到 Channel 的 event 条数，适当调大这个参数

可以提高 Source 搬运 Event 到 Channel 时的性能。

2. Channel

type 选择 memory 时 Channel 的性能最好，但是如果 Flume 进程意外挂掉可能会丢失

数据。 type 选择 file 时 Channel 的容错性更好，但是性能上会比 memory channel 差。

使用 file Channel 时 dataDirs 配置多个不同盘下的目录可以提高性能。

Capacity 参数决定 Channel 可容纳最大的 event 条数。 transactionCapacity 参数决定每次 Source 往 channel 里面写的最大 event 条数和每次 Sink 从 channel 里面读的最大 event条数。 transactionCapacity 需要大于 Source 和 Sink 的 batchSize 参数。

3. Sink

增加 Sink 的个数可以增加 Sink 消费 event 的能力。 Sink 也不是越多越好够用就行，过

多的 Sink 会占用系统资源，造成系统资源不必要的浪费。

batchSize 参数决定 Sink 一次批量从 Channel 读取的 event 条数，适当调大这个参数可

以提高 Sink 从 Channel 搬出 event 的性能

7MQ中的数据的消费是怎么实现的？

使用的线程池来实现创建多线程来消费MQ 中的消息。并且使用线程池管线程，能提高相应的速度，提高线程的管理。

8如果在线程消费消息的时候出现被挂起或者是线程被阻塞的时候MQ的消息会丢失吗？

如果是线程被一个线程获取后应该是不需要加锁的。如果有线程完成了消息的消费将会返回这个消息的唯一的ID，Kafka中共收到消息后将将消息删除，如果在这个线程被挂起或者是被阻塞的时候其他线程也是有可能消费的。但是当消息删除后还有消息在消费，当然后返回值不存子的时候将这个消息的结果直接实现处理。

9线程池的线程如果同时获取到一个消息，怎么防止一个数据被多个消息者消费。

消息被重复消费的原因：造成消费被重复消费的原因来源于我们之前为了防止消息在消费者端丢失，采用的手动回复MQ的解决方案。如果消费者处理消息成功，手动向MQ回复消息时，网络不稳定，无法回复MQ消费完毕。此时MQ因为收不到消费者的回复而仍然把这条消息保存到MQ中，并重发这条消息到消费者处，此时消费者就收到了2条一样的消息了。

解决这个重复消费的解决方案：

1.借助Redis存储消息id，因为redis是单线程缓存数据库，并且提供了很多原子性的操作。我们就可以使用redis中的setnx命令存储消息id。当消费者收到MQ发过的消息并检测到有重复的消息id时，不对重复的消息id进行处理，就直接返回给消费者本条消息已消费。

2.可自定义处理方法。比如每次消费者消费成功后都将该消息id保存到数据库中，每次消费前查询该消息id，如果消息id存在不再进行消费，如果消息id不存在才会进行消费

10Kafka的基础原理

Kafka的基础架构图

Kafka中message to A-0 /meesage to A-1的消息分区的作用是：提高某一个topic的负载均衡的能力和提高并发度。

在0.9版本中Kafka集群中也会在信息中的存储在zookeeper中，消费者也会将一部分消息放置在Zookeeper 消费者保存的消费的位置的信息中。但是在0.9以后就采用的是本地的中。

1）Producer ：消息生产者，就是向 kafka broker 发消息的客户端；

2）Consumer ：消息消费者，向 kafka broker 取消息的客户端；

3）Consumer Group（CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4）Broker：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个 broker可以容纳多个topic。

5）Topic：可以理解为一个队列，生产者和消费者面向的都是一个 topic；

6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker即服务器上，

一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；

7） Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作， kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8） leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9） follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。 leader 发生故障时，某个 follower 会成为新的 follower。

11Kafka工作流程及文件存储机制

Kafka 中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向 topic

的。topic 是逻辑上的概念，而 partition 是物理上的概念，每个partition 对应于一个 log文件，该log文件中存储的就是producer生产的数据。 Producer生产的数据会被不断追加到该log 文件末端，且每条数据都有自己的 offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。

11Kafka的生产者：

分区策略

1）分区的原因：（1）方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 topic又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据了；（2）可以提高并发，因为可以以 Partition 为单位读写了。

2）分区的原则

我们需要将 producer 发送的数据封装成一个 ProducerRecord 对象。

（1）指明 partition 的情况下，直接将指明的值直接作为 partiton 值；

（2）没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition

数进行取余得到 partition 值；

（3）既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后

面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition值，也就是常说的 round-robin 算法

12kafka生产数据的可靠性：

为保证 producer 发送的数据，能可靠的发送到指定的 topic， topic 的每个 partition 收到producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement 确认收到），如果producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。

13kafka数据的重复的问题：

acks：

0：producer 不等待 broker 的 ack，这一操作提供了一个最低的延迟， broker 一接收到还

没有写入磁盘就已经返回，当 broker 故障时有可能丢失数据；

1： producer 等待 broker 的 ack， partition 的 leader 落盘成功后返回 ack，如果在 follower同步成功之前 leader 故障，那么将会丢失数据；

-1（all）： producer 等待 broker 的 ack， partition 的 leader 和 follower 全部落盘成功后才返回 ack。但是如果在 follower 同步完成后， broker 发送 ack 之前， leader 发生故障，那么会造成数据重复

14kafka数据的一致性问题：

LEO：指的是每个副本最大的 offset；

HW：指的是消费者能见到的最大的 offset， ISR 队列中最小的 LEO。

1、follower 故障

follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后follower 会读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。

2、leader 故障

leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

15Kafka的消费者

consumer 采用 pull（拉）模式从 broker 中读取数据。push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。pull 模式不足之处是，如果 kafka 没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka 的消费者在消费数据时会传入一个时长参数 timeout，如果当前没有数据可供消费，consumer 会等待一段时间之后再返回，这段时长即为 timeout。

16Kafka 高效读写数据原理

0）分布式的有分区的操作。

1）顺序写磁盘

Kafka的producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

2）零复制技术：不要将数据用内核态到用户态度的转变，可以是实现将内核态度到内核态数据传输。

17kafka分区分配策略：

一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，所以必然会涉及到 partition 的分配问题，即确定那个 partition 由哪个 consumer 来消费。Kafka 有两种分配策略，一是 RoundRobin，一是 Range。

18Kafka的事务：Producer 事务使用的是PID

为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer获得的PID 和Transaction ID 绑定。这样当Producer 重启后就可以通过正在进行的 TransactionID 获得原来的 PID。

为了管理Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。 Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。 TransactionCoordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

19Kafka的事务：Consumer事务就是维护一个offerset

上述事务机制主要是从 Producer 方面考虑，对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访问任意信息，而且不同的 Segment File 生命周期不同，同一事务的消息可能会出现重启后被删除的情况。

Kafka 中的 ISR(InSyncRepli)、 OSR(OutSyncRepli)、 AR(AllRepli)代表什么？

Kafka 中的 HW、 LEO 等分别代表什么？

Kafka 中是怎么体现消息顺序性的？

Kafka 中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？

Kafka 生产者客户端的整体结构是什么样子的？使用了几个线程来处理？分别是什么？

“消费组中的消费者个数如果超过 topic 的分区，那么就会有消费者消费不到数据”这句话是否正确？

消费者提交消费位移时提交的是当前消费到的最新消息的 offset 还是 offset+1？

有哪些情形会造成重复消费？

那些情景会造成消息漏消费？

当你使用 kafka-topics.sh 创建（删除）了一个 topic 之后Kafka背后会执行什么逻辑？

1）会在 zookeeper 中的/brokers/topics 节点下创建一个新的 topic 节点，如：

/brokers/topics/first

2）触发 Controller 的监听程序

3） kafka Controller 负责 topic 的创建工作，并更新 metadata cache

topic 的分区数可不可以增加？如果可以怎么增加？如果不可以，那又是为什么？

topic 的分区数可不可以减少？如果可以怎么减少？如果不可以，那又是为什么？

Kafka 有内部的 topic 吗？如果有是什么？有什么所用？

Kafka 分区分配的概念？

简述 Kafka 的日志目录结构？

如果我指定了一个 offset， Kafka Controller 怎么查找到对应的消息？

聊一聊 Kafka Controller 的作用？

Kafka 中有那些地方需要选举？这些地方的选举策略又有哪些？

失效副本是指什么？有那些应对措施？

Kafka 的哪些设计让它有如此高的性能？

20Hadoop的读写流程

1HDFS的数据的写数据流程

HDFS的读机制

HDFS中的NameNode的机制

HDFS的DataNode工作机制

MapperReducer的机制

21Hadoop的shuffle机制

22Yarn的工作原理

23hadoop的处理的数据问题

24 你构建过什么微服务？

25 Springboot的注解启动的原理是什么？

26 使用的数据库有哪些？

27 Hbase数据的库的原理和使用？

28 数据库的集群是怎么实现的？

29 编写过什么接口？写过什么功能？

30 你们是怎么设计这个接口的？怎么实现接口的安全的？

31你们有学习和了解过系统设计的那些知识？

基于虚拟化的混合云集群——基于集群管理监控系统相关推荐

轻松实现基于Heartbeat的高可用web服务集群
高可用集群就是为了保证某项服务能够时时在线,我们可以通过几个9来衡量一个高可用集群提供服务的稳定性,例如5个9的高可用集群必须保证服务一年在线的时间占99.999%,也就是说一年的时间中仅允许服务电线 ...
3、基于多播、安全认证的corosync集群(VIP、Httpd、Filesystem)
Messaging Layer --> CRM --> RA systemd:/usr/lib/systemd/system systemd有一个特性,即便一个服务开机启动,但是在开机后这 ...
基于nginx的tomcat负载均衡和集群(超简单)
今天看到"基于apache的tomcat负载均衡和集群配置 "这篇文章成为javaEye热点. 略看了一下,感觉太复杂,要配置的东西太多,因此在这里写出一种更简洁的方法. 要集群t ...
搭建基于Docker社区版的Kubernetes本地集群
搭建基于Docker社区版的Kubernetes本地集群原文:搭建基于Docker社区版的Kubernetes本地集群 Kubernetes的本地集群搭建是一件颇费苦心的活,网上有各种参考资源,由于 ...
部署基于tomcat 8 的solrCloud 5.5集群
部署基于tomcat 8 的solrCloud 5.5集群 @(OTHERS)[solr] 部署基于tomcat 8 的solrCloud 55集群一版本及准备工作二准备solr相关webapp内 ...
总结 Underlay 和 Overlay 网络,在k8s集群实现underlay网络,网络组件flannel vxlan/ calico IPIP模式的网络通信流程,基于二进制实现高可用的K8S集群
1.总结Underlay和Overlay网络的的区别及优缺点 Overlay网络:  Overlay 叫叠加网络也叫覆盖网络,指的是在物理网络的基础之上叠加实现新的虚拟网络,即可使网络的中的容器可 ...
基于rhcs套件实现的高可用集群
1.基于rhcs套件实现nginx平台的高可用集群实验环境: 1> server1 server5 集群节点为了节省节点我们还用了server1作为管理节点安装了luci图形管理: 2> ...
项目 - 基于Docker Swarm的高可用Web集群
目录项目名称:基于Docker Swarm的高可用Web集群项目环境:Docker 20.10.3,CentOS 8.2 (8台 1核1G),Ansible 2.9.17,Keepalived,N ...
基于LVS高可用架构实现Nginx集群分流
Nginx实用插件_踩踩踩从踩的博客-CSDN博客前言前面文章介绍Nginx的核心及扩展插件必要的性能优化,以及在nginx中如何实用用https:本篇文章会继续讲解重要的概念 lvs高可用框架, ...

基于虚拟化的混合云集群——基于集群管理监控系统

摘要