Golang语言开发（十二）

　　本篇主要内容为分布式计算框架Hadoop

Spark

Hadoop和Apache Spark两者都是大数据框架，但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，意味着您不需要购买和维护昂贵的服务器硬件。

​ 同时，Hadoop还会索引和跟踪这些数据，让大数据处理和分析效率达到前所未有的高度。Spark，则是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它并不会进行分布式数据的存储。

Hadoop除了提供为大家所共识的HDFS分布式数据存储功能之外，还提供了叫做MapReduce的数据处理功能。所以这里我们完全可以抛开Spark，使用Hadoop自身的MapReduce来完成数据的处理。

​ 相反，Spark也不是非要依附在Hadoop身上才能生存。但如上所述，毕竟它没有提供文件管理系统，所以，它必须和其他的分布式文件系统进行集 成才能运作。这里我们可以选择Hadoop的HDFS,也可以选择其他的基于云的数据系统平台。但Spark默认来说还是被用在Hadoop上面的，毕 竟，大家都认为它们的结合是最好的。

对MapReduce的最简洁明了的解析:

我们要数图书馆中的所有书。你数1号书架，我数2号书架。这就是“Map”。我们人越多，数书就更快。

现在我们到一起，把所有人的统计数加在一起。这就是“Reduce”。

Spark的处理速度远超Reduce

Spark因为其处理数据的方式不一样，会比MapReduce快上很多。MapReduce是分步对数据进行处理的: ”从集群中读取数据，进行一次处理，将结果写到集群，从集群中读取更新后的数据，进行下一次的处理，将结果写到集群，等等…“ Booz Allen Hamilton的数据科学家Kirk Borne如此解析。

​ 反观Spark，它会在内存中以接近“实时”的时间完成所有的数据分析：“从集群中读取数据，完成所有必须的分析处理，将结果写回集群，完成，” Born说道。Spark的批处理速度比MapReduce快近10倍，内存中的数据分析速度则快近100倍。

​ 如果需要处理的数据和结果需求大部分情况下是静态的，且你也有耐心等待批处理的完成的话，MapReduce的处理方式也是完全可以接受的。

​ 但如果你需要对流数据进行分析，比如那些来自于工厂的传感器收集回来的数据，又或者说你的应用是需要多重数据处理的，那么你也许更应该使用Spark进行处理。

​ 大部分机器学习算法都是需要多重数据处理的。此外，通常会用到Spark的应用场景有以下方面：实时的市场活动，在线产品推荐，网络安全分析，机器日记监控等。

灾难恢复

两者的灾难恢复方式迥异，但是都很不错。因为Hadoop将每次处理后的数据都写入到磁盘上，所以其天生就能很有弹性的对系统错误进行处理。

​ Spark的数据对象存储在分布于数据集群中的叫做弹性分布式数据集(RDD: Resilient Distributed Dataset)中。“这些数据对象既可以放在内存，也可以放在磁盘，所以RDD同样也可以提供完成的灾难恢复功能，”Borne指出。

Kafka

RocketMQ 和 Kafka 是目前最热门的两种消息中间件，互联网公司应用最为广泛

从 MQ 的发展历程来看，Kafka 先于 RocketMQ 诞生，并且阿里团队在实现 RocketMQ 时，充分借鉴了 Kafka 的设计思想。掌握了 Kafka 的设计原理，后面再去理解 RocketMQ 会容易很多

Kafka 其实是一个轻量级的 MQ，它具备 MQ 最基础的能力，但是在延迟队列、重试机制等高级特性上并未做支持，因此降低了实现复杂度。从 Kafka 入手，有利于大家快速掌握 MQ 最核心的东西。

Kafka 最开始其实是 Linkedin 内部孵化的项目，在设计之初是被当做「数据管道」，用于处理以下两种场景：

1、运营活动场景：记录用户的浏览、搜索、点击、活跃度等行为。 2、系统运维场景：监控服务器的 CPU、内存、请求耗时等性能指标。

可以看到这两种数据都属于日志范畴，特点是：数据实时生产，而且数据量很大。

Linkedin 最初也尝试过用 ActiveMQ 来解决数据传输问题，但是性能无法满足要求，然后才决定自研 Kafka。

所以从一开始，Kafka 就是为实时日志流而生的。了解了这个背景，就不难理解 Kafka 与流数据的关系了，以及 Kafka 为什么在大数据领域有如此广泛的应用？也是因为它最初就是为解决大数据的管道问题而诞生的。

发展路线

首先，为了将一份消息数据分发给多个消费者，并且每个消费者都能收到全量的消息，很自然的想到了广播

紧接着问题出现了：来一条消息，就广播给所有消费者，但并非每个消费者都想要全部的消息，比如消费者 A 只想要消息 1、2、3，消费者 B 只想要消息 4、5、6，这时候该怎么办呢？

这个问题的关键点在于：MQ 不理解消息的语义，它根本无法做到对消息进行分类投递。

此时，MQ 想到了一个很聪明的办法：它将难题直接抛给了生产者，要求生产者在发送消息时，对消息进行逻辑上的分类，因此就演进出了我们熟知的 Topic 以及发布 - 订阅模型。

这样，消费者只需要订阅自己感兴趣的 Topic，然后从 Topic 中获取消息即可。

但是这样做了之后，仍然存在一个问题：假如 多个消费者都对同一个 Topic 感兴趣（如下图中的消费者 C），那又该如何解决呢

如果采用传统的队列模式（单播），那当一个消费者从队列中取走消息后，这条消息就会被删除，另外一个消费者就拿不到了

也就是：当 Topic 每增加一个新的消费者，就「复制」一个完全一样的数据队列。

这样问题是解决了，但是随着下游消费者数量变多，将引发 MQ 性能的快速退化。尤其对于 Kafka 来说，它在诞生之初就是处理大数据场景的，这种复制操作显然成本太高了。

这时候，就有了 Kafka 最画龙点睛的一个解法：它将所有消息进行了持久化存储，由消费者自己各取所需，想取哪个消息，想什么时候取都行，只需要传递一个消息的 offset 即可

这样一个根本性改变，彻底将复杂的消费问题又转嫁给消费者了，这样使得 Kafka 本身的复杂度大大降低，从而为它的高性能和高扩展打下了良好的基础。（这是 Kafka 不同于 ActiveMQ 和 RabbitMQ 最核心的地方）

这就是 Kafka 最原始的消息模型

存储

面对海量数据，单机的存储容量和读写性能肯定有限，大家很容易想到一种存储方案： 对数据进行分片存储 。 这种方案在我们实际工作中也非常常见：

1、比如数据库设计中，当单表的数据量达到几千万或者上亿时，我们会将它拆分成多个库或者多张表。

2、比如缓存设计中，当单个 Redis 实例的数据量达到几十个 G 引发性能瓶颈时，我们会将单机架构改成分片集群架构。

类似的拆分思想在 HDFS、ElasticSearch 等中间件中都能看到。

Kafka 也不例外，它同样采用了这种水平拆分方案。在 Kafka 的术语中，拆分后的数据子集叫做 Partition（分区） ，各个分区的数据合集即全量数据。

我们再来看下 Kafka 中的 Partition 具体是如何工作的？ 举一个很形象的例子，如果我们把「Kafka」类比成 「高速公路」 ：

1、当大家听到京广高速的时候，知道这是一条从北京到广州的高速路，这是逻辑上的叫法，可以理解成 Kafka 中的 Topic（主题）。

2、一条高速路通常会有多个车道进行分流，每个车道上的车都是通往一个目的地的（属于同一个 Topic），这里所说的车道便是 Partition。

这样，一条消息的流转路径就如下图所示，先走主题路由，然后走分区路由，最终决定这条消息该发往哪个分区

其中分区路由可以简单理解成一个 Hash 函数，生产者在发送消息时，完全可以自定义这个函数来决定分区规则。如果分区规则设定合理，所有消息将均匀地分配到不同的分区中。

通过这样两层关系，最终在 Topic 之下，就有了一个新的划分单位：Partition。先通过 Topic 对消息进行逻辑分类，然后通过 Partition 进一步做物理分片，最终多个 Partition 又会均匀地分布在集群中的每台机器上，从而很好地解决了存储的扩展性问题

因此，Partition 是 Kafka 最基本的部署单元。本文之所以将 Partition 称作 Kafka 架构设计的任督二脉，基于下面两点原因：

1、Partition 是存储的关键所在，MQ「一发一存一消费」的核心流程必然围绕它展开。 2、Kafka 高并发设计中最难的三高问题都能和 Partition 关联起来。

因此，以 Partition 作为根，能很自然地联想出 Kafka 架构设计中的各个知识点，形成可靠的知识体系。

为什么 Kafka 会采用 Logging（日志文件）这种很原始的方式来存储消息，而没考虑用数据库或者 KV 来做存储？

而对 Kafka 有所了解的同学，应该能快速说出一些 知识点：比如 Append Only、Linear Scans、磁盘顺序写、页缓存、零拷贝、稀疏索引、二分查找等等。

了解了 Kafka 的存储设计后，能对 Append Only Data Structures 这一经典的底层存储原理认识更加深刻，因为它驱动了业界太多极具影响力的存储系统走向成功，比如 HBase、Cassandra、RocksDB 等等

Kafka 的存储选型逻辑，我认为跟我们开发业务需求的思路类似，到底用 MySQL、Redis 还是其他存储方案？一定取决于具体的业务场景。

我们试着从以下两个维度来分析下：

1、功能性需求：存的是什么数据？量级如何？需要存多久？CRUD 的场景都有哪些？ 2、非功能性需求：性能和稳定性的要求是什么样的？是否要考虑扩展性？

再回到 Kafka 来看，它的功能性需求至少包括以下几点：

1、存的数据主要是消息流：消息可以是最简单的文本字符串，也可以是自定义的复杂格式。

但是对于 Broker 来说，它只需处理好消息的投递即可，无需关注消息内容本身。

2、数据量级非常大：因为 Kafka 作为 Linkedin 的孵化项目诞生，用作实时日志流处理（运营活动中的埋点、运维监控指标等），按 Linkedin 当初的业务规模来看，每天要处理的消息量预计在千亿级规模。

3、CRUD 场景足够简单：因为消息队列最核心的功能就是数据管道，它仅提供转储能力，因此 CRUD 操作确实很简单。

首先，消息等同于通知事件，都是追加写入的，根本无需考虑 update。其次，对于 Consumer 端来说，Broker 提供按 offset（消费位移）或者 timestamp（时间戳）查询消息的能力就行。再次，长时间未消费的消息（比如 7 天前的），Broker 做好定期删除即可。

接着，我们再来看看非功能性需求：

1、性能要求：之前的文章交代过，Linkedin 最初尝试过用 ActiveMQ 来解决数据传输问题，但是性能无法满足要求，然后才决定自研 Kafka。ActiveMQ 的单机吞吐量大约是万级 TPS，Kafka 显然要比 ActiveMQ 的性能高一个量级才行。

2、稳定性要求：消息的持久化（确保机器重启后历史数据不丢失）、单台 Broker 宕机后如何快速故障转移继续对外提供服务，这两个能力也是 Kafka 必须要考虑的。

3、扩展性要求：Kafka 面对的是海量数据的存储问题，必然要考虑存储的扩展性。

再简单总结下，Kafka 的存储需求如下：

1、功能性需求：其实足够简单，追加写、无需 update、能根据消费位移和时间戳查询消息、能定期删除过期的消息。 2、非功能性需求：是难点所在，因为 Kafka 本身就是一个高并发系统，必然会遇到典型的高性能、高可用和高扩展这三方面的挑战。

https://zhuanlan.zhihu.com/p/381258330

架构

Partition 是 Topic 之下的一个划分单位，它是 Kafka 最基本的部署单元，它将决定 Kafka 集群的组织方式。

假设现在有两个 Topic，每个 Topic 都设置了两个 Partition，如果 Kafka 集群是两台机器

可以看到：同一个 Topic 的两个 Partition 分布在不同的消息服务器上，能做到消息的分布式存储了。 但是对于 Kafka 这个高并发系统来说，仅存储可扩展还不够，消息的拉取也必须并行才行，否则会遇到极大的性能瓶颈。

那我们再看看消费端，它又是如何跟 Partition 结合并做到并行处理的？

从消费者来看，首先要满足两个基本诉求：

1、广播消费能力：同一个 Topic 可以被多个消费者订阅，一条消息能够被消费多次。 2、集群消费能力：当消费者本身也是集群时，每一条消息只能分发给集群中的一个消费者进行处理。

为了满足这两点要求，Kafka 引出了消费组的概念，每个消费者都有一个对应的消费组，组间进行广播消费，组内进行集群消费。此外，Kafka 还限定了：每个 Partition 只能由消费组中的一个消费者进行消费

最终的消费关系如下图所示：假设主题 A 共有 4 个分区，消费组 2 只有两个消费者，最终这两个消费组将平分整个负载，各自消费两个分区的消息

如果要加快消息的处理速度，该如何做呢？也很简单，向消费组 2 中增加新的消费者即可，Kafka 将以 Partition 为单位重新做负载均衡。当增加到 4 个消费者时，每个消费者仅需处理 1 个 Partition，处理速度将提升两倍。

到这里，存储可扩展、消息并行处理这两个难题都解决了。但是高并发架构设计上，还遗留了一个很重要的问题：那就是高可用设计。

在 Kafka 集群中，每台机器都存储了一些 Partition，一旦某台机器宕机，上面的数据不就丢失了吗？

此时，你一定会想到对消息进行持久化存储，但是持久化只能解决一部分问题，它只能确保机器重启后，历史数据不丢失。但在机器恢复之前，这部分数据将一直无法访问。这对于高并发系统来说，是无法忍受的。

所以 Kafka 必须具备故障转移能力才行，当某台机器宕机后仍然能保证服务可用。

如果大家去分析任何一个高可靠的分布式系统，比如 ElasticSearch、Redis Cluster，其实它们都有一套多副本的冗余机制。

没错，Kafka 正是通过 Partition 的多副本机制解决了高可用问题。在 Kafka 集群中，每个 Partition 都有多个副本，同一分区的不同副本中保存的是相同的消息。

副本之间是 “一主多从” 的关系，其中 leader 副本负责读写请求，follower 副本只负责和 leader 副本同步消息，当 leader 副本发生故障时，它才有机会被选举成新的 leader 副本并对外提供服务，否则一直是待命状态。

因此 Kafka 的整体架构：

1、Producer：生产者，负责创建消息，然后投递到 Kafka 集群中，投递时需要指定消息所属的 Topic，同时确定好发往哪个 Partition。

2、Consumer：消费者，会根据它所订阅的 Topic 以及所属的消费组，决定从哪些 Partition 中拉取消息。

3、Broker：消息服务器，可水平扩展，负责分区管理、消息的持久化、故障自动转移等。

4、Zookeeper：负责集群的元数据管理等功能，比如集群中有哪些 broker 节点以及 Topic，每个 Topic 又有哪些 Partition 等。

很显然，在 Kafka 整体架构中，Partition 是发送消息、存储消息、消费消息的纽带。吃透了它，再去理解整体架构，脉络会更加清晰。

kafka-go

https://github.com/segmentio/kafka-go

Pulsar