后端开发需要掌握的技术，后端需要什么技术

作者| L的存在

来源|我是程序员。 ( ID:Lanj1995Q ) ) ) ) )。

说到后端开发，不可避免地会遇到所谓的“关键词”。 不得不说，我对我们应届毕业生小白不熟悉。 学校里确实很少会遇到这些所谓的“高大上”，所以今天就带着学习的态度，和大家分享一些可以伪装成飞的强有力的关键词吧。 大纲

对于分散在学校的项目，一个Web系统可能只需要一个人。 因为很少考虑并发量，所以性能怎么样？ 所谓的“还可以”就足够了，但是为了面试，必须要找一个类似的秒杀系统作为简历的支持项目。 那么首先是第一个问题，为什么采用了分布式的程序落地这个项目呢？

如果一个人或几十个人使用你的系统，哎呀我去，请求秒次，效果就会加倍。 所以简历明明写得很潦草，居然是牛x，面试官会问你这个项目做了什么，测试过吗，并发量怎么样，性能怎么样。 你… .

越来越多的用户访问系统，但由于系统资源有限，需要更多的CPU和内存来处理用户的计算请求。 当然，为了处理数据的传输，需要更大的网络带宽，需要在更多的磁盘空间中存储数据。

资源不够，消耗太多，服务器崩溃，系统也不起作用了，那么在这种情况下怎么处理？

沿垂直方向伸缩

纵向生长。 通过提高单台服务器的处理能力，抵制更大的请求访问。 例如，使用更高频率的CPU，使用更快的网卡，填充更多的磁盘等。

其实，这种处理方式在电信、银行等企业很常见。 把摩托车变成轿车，变成更强大的计算机，处理能力也越强，但对运维来说也越复杂。 那真的就这样花钱买设备就完了吗？

当然，一台服务器的计算能力是有限的，严重受到计算机硬件水平的限制。

水平伸缩

一台机器处理不完，所以我用多台便宜的机器合并同时处理。 人多力量大啊。 通过由多台服务器构成分布式集群，提高系统整体的处理能力。 这里说到方差，我们来看看方差的成长过程

请记住一句话。 系统的技术架构由需求驱动

第一个单元系统只能由部分用户访问。 单体结构

建立系统的理由当然是有需求、有价值、能赚钱。 随着使用系统的用户越来越多，这个时候关注的人越来越多，单个服务器扛不住了，关注的人觉得响应慢，没意思，开始吐槽。 但是这个吐槽用户很多，毕竟大家都喜欢哈密瓜。

在此状态下，必须进行系统升级，将数据库和APP应用程序分离。 隔离数据库APP应用程序

这样，如何分离数据库和APP应用后，部署在不同的服务器上，从一台服务器改为多台服务器，处理响应迅速，内容也充分，访问的用户呈指数级增加，这多台服务器有点吃不消

添加缓存吧。 将APP应用所需的数据临时存储在缓冲区中，而不是每次从数据库中读取数据。 缓存分为本地缓存和分布式缓存。 顾名思义，分布式缓存通过使用多个服务器组成群集、存储更多数据和提供缓存服务来提高缓存的能力。

添加缓存的优点是什么？

APP应用程序不再直接访问数据库，从而提高了访问效率。 因为高速缓存的内容在内存中，所以不需要每次都连接到磁盘上存储的数据库。

由于系统越来越热，我们考虑将APP应用服务器也作为群集。 集体感染

现金不能做什么？ 缓存排名第一。 不自夸，缓存适用于计算机的每个角落。 缓存也可以说是软件技术中的杀手锏，无论是在程序代码中使用buffer还是在网络体系结构中使用缓存，虚拟机都会使用大量的缓存。

其实一开始在CPU上也开始使用缓存。 高速缓存有两种：通读高速缓存和旁路高速缓存

通读缓存

如果当前APP应用程序已获取数据且数据存在于通读高速缓存中，则返回。 如果它不在通读高速缓存中，则访问数据源并将数据存储在高速缓存中。

下次访问直接从缓存中获取。 常见的是CDN和反向代理。

通读缓存

CDN

CDN被称为内容分发网络。 我们在京东买东西的时候，假设在成都，如果买的东西在成都仓库的话直接送我，可能半天就到了。 用户体验也很好，不用从北京发。

同样，用户可以近距离获取所需的数据，从而提高响应速度，节省网络带宽和服务器资源。

旁路缓存

APP应用程序必须自己从数据源读取数据，并将该数据写入旁路高速缓存。 这样，下次APP应用程序需要数据时，就可以直接从旁路缓存中获取数据。 旁路缓存

缓存的好处

缓存的大部分数据都存储在内存中，因此比从硬盘或网络检索更高效、响应更快，并且性能更高。

通过用CDN等通读缓存，可以降低服务器的负荷能力

因为缓存通常会记录计算结果。 如果直接返回缓存命中，否则将需要大量运算。 所以通过使用缓存，CPU的计算小号也会减少，提高处理速度。

高速缓存缺陷

我们缓存的数据来自源数据。 如果源数据发生了变化，我很乐意缓存数据也发生变化成为脏数据，该怎么办？

过期

每次写入缓存数据时都标记过期日期，并在读取数据时检查数据是否无效，如果无效，则从数据源重新检索数据。

失效通知

当您更新数据源时，APP应用程序会通知您清除缓存中的数据。

数据使用缓存有意义吗？

不，通常可以放入缓存的数据是有热点的数据。 例如，当天的热门商品和人气香瓜新闻。 以这种方式将数据保存在缓存中会导致多次读取，从而提高缓存的命中率。

异步架构如上所述，缓存实际上解决了读取问题，往往提高了数据的读取能力。 因为缓存通常很难保证数据的持久性和一致性，所以通常是将数据写入RDBMAS之类的数据，而不是直接写入缓存。 那么，如何提高系统的写入性能呢？

此时，2个系统分别为a、b，其中a系统依赖于b系统，假设两者的通信采用远程呼叫方式，此时如果b系统故障，有可能引起a系统的故障。

因此，必须单独升级。 我该怎么办？

使用消息队列的异步体系结构也是事件驱动模型。

在异步情况下，同步通常在APP应用程序调用服务时必须等待服务期限的结束，而CPU空闲是徒劳的。 在返回服务结果之前不会继续执行。 同步

例如，小蓝今天在系统中添加了发送邮件的功能，想通过SMTP与远程服务器通信，但是远程服务器上有很多需要等待发送的邮件呢。 现在的邮件可能要花比较长的时间才能发送成功。 发送成功后，请反馈到APP应用程序。

在此过程中，如果远程服务器发送邮件，APP发布将被阻止。 确切地说，它阻止了执行APP高速缓存的线程。

这样的堵塞会带来什么问题？

无法释放占用的系统资源，系统资源不足，影响系统性能

无法迅速响应用户的结果

但实际上，我们发送邮件不需要得到发送结果。 例如，如果用户注册并发送帐户以激活邮件，则无论邮件是否成功发送，都会显示“已发送回复邮件。 请检查邮件，确认是否已激活。” 怎样才能避免APP被屏蔽？ 消息队列的异步模型

在这个时候很明显。 调用者将消息发送到消息队列并直接回复，APP应用程序在收到回复后继续执行，并响应用户释放资源。

专用的用户队列程序从消息队列中检索数据并进行消耗。 如果远程服务发生故障，它将只传递给消费者程序，而不影响APP应用程序。 消息队列

消息队列模型具有生产者、消息队列和消费者三个角色。 生产者生成的数据作为消息发送到消息队列，专用的消费程序从消息队列中取出数据，消费数据。

我认为消息队列主要是缓冲消息，等待消费者消费。 其中消费方式分为两种：

点对点

生产者多消费者多的情况。 一条新闻被消费者消费

增加生产和消费

上述邮件发送示例是典型的点对点模式。 互不干涉。 其中，即使某个服务出现问题，也不会想象整体。

订阅模式

开发者在消息队列中设置主题，生产者向对应的主题发送数据，消费者从对应的主题中消费数据，按照自己的业务逻辑对每个消费者分别进行计算

订阅模式

这个很容易理解。 例如，用户注册的时候，我们把注册信息放入主题用户，消费者订阅这个主题，可能会有制作邮件消息的消费者和推广产品的消费者。 它们都可以根据自己的业务逻辑进行数据处理。 用户注册案例

使用异步模型的优点

迅速的应对

你没必要等。 生产者在向消息队列发送数据后，可以继续执行，不会等待耗时的消费处理

刨山填谷(需要修正) )。

互联网产品根据场景的不同，同时请求量也不同。 网络APP应用的访问压力随时都在变化，访问系统的高峰和低谷的同时压力可能也有非常大的差异。

在压力最大的情况下部署服务群集时，服务大部分时间都处于空闲状态。

但是，使用消息队列可以将要处理的消息排队，消费者可以控制消耗速度，从而减轻系统访问高峰时的压力，在访问高峰时消耗消息队列中未处理的消息

降下联轴器

如果调用已同步，则意味着如果调用已同步，则调用方和被调用方必然存在依赖关系。 另一方面，代码依赖要求APP应用程序依赖于与发送邮件相关的代码，如果需要更改发送邮件的代码，则需要更改APP应用程序。 然后，在追加新功能的情况下

那么，当前主要的消息队列有什么，其缺点是什么？ (请仔细记住这个高频主题) )。

一台机器无法承担负载平衡，需要多台机器的帮助。 既然要使用多台机器，就不要给一台机器带来压力，所以需要通过一种或多种策略来平衡高并发压力和部署负载平衡。 那么，如何分发给不同的服务器呢？

砸钱最先实现负载均衡的方案很直接，直接上硬件，当然会比较贵。 随着互联网的普及，各位科学家的无私奉献，各企业开始引入自己的策略，出现了负载均衡服务器。

HTTP重定向负载均衡

直接而言，在HTTP请求涌向负载均衡服务器后，它会使用一组负载均衡算法计算后端服务器的地址，并将新地址传递给用户的浏览器。 浏览器接收重定向响应并将请求发送到新的APP应用服务器以实现负载平衡。 下图： HTTP重定向负载平衡

优点：

很简单。 如果您是java开发工程师，则只需要servlet中的一些代码

坏处：

增加要求的工作量。 第一次向负载平衡服务器请求，第二次向APP应用服务器请求

由于要先计算APP应用程序服务器的IP地址，因此IP地址可能会暴露在公共网络上。 既然暴露在公共网络上，就没有任何安全性了

DNS负载均衡

了解计算机网络的人应该很了解如何获取IP地址。 其中常见的是通过DNS分析获取IP地址。

用户从浏览器发出HTTP请求时，DNS通过即时关闭域名取得IP地址，用户请求协议栈的IP地址简历HTTP连接访问真正的服务器。 像这样对每个用户进行域名解析，可以获得不同的IP地址，实现负载均衡。

DNS负载均衡

乍一看，它和HTTP重定向的方案很相似吧。 另外，还有DNS分析这一步骤，IP地址也被分析，产生不同的曝光。

需要每次都进行分析吗？ 当然，本机通常有缓存，但在实际工程项目中通常怎么样？

通过DNS分析获取负载均衡集群所在服务器的地址；

负载平衡服务器再次检索某个APP应用服务器，这样就不会将APP应用服务器的IP地址暴露在官方网站上。

反向代理负载平衡

这里的典型功能是Nginx提供的反向代理和负载平衡功能。 用户的请求被直接传递到反向代理服务器，该服务器首先看到本地被缓存，然后被直接返回，否则被传递到后台的APP应用服务器进行处理。

反向代理负载平衡

IP负载平衡

上述方案基于APP应用层，IP显然从网络层进行负载均衡。 TCP./IP协议栈是通过需要上下层结合的方式实现目标，当请求到达网络层时的猴子。

负载平衡服务器转换数据包中的IP地址，并将其发送到APP应用程序服务器。

IP负载平衡

请注意，此方案通常在内核级别。 数据较小时没问题，但在大多数情况下，这是一个资源文件(如图像)，这会导致负载平衡服务器响应或请求过大所带来的瓶颈。

数据链路负载均衡

可以解决由于数据量大而导致负载均衡服务器带宽不足的问题。 是怎么实现的？ 更改数据包的mac地址，而不是IP地址。

APP应用服务器和负载平衡服务器使用相同的虚拟IP。

数据链路负载均衡

以上介绍了几种负载均衡方式，但没有设计重要的负载均衡算法，其中包括轮询、随机、最低连接，将分别进行介绍。

数据存储公司的存在价值是流量，流量需要数据，考虑到数据的存储，数据的高可用性可以说是公司的灵魂。 那么，有什么手段和方法可以改善数据的存储呢？

主从复制

主从设备很容易理解，需要使用两个数据库存储相同的数据。 其原理是，当APP应用程序a向主服务器发送更新命令时，数据库会将该命令同步记录到Binlog中。

然后，其他线程从Binlog读取，并通过远程通信复制到其他服务器。 服务器接收更新日志并将其添加到自己的Relay Log中，然后SQL执行线程从Relay Log中读取辅助日志并在本地数据库中运行一次，以实现与主从数据库中的数据相同的数据。

主从复制

主从复制易于读写分离，可以使用主从方法确保高可用性。 如果断开与数据库a的连接，可以将读取操作从数据库迁移到达到高可用性。

但是，如果主数据库挂起，则是Mysql的主复制。 但是，上述方法并没有提高存储能力，因此需要对数据库进行分片。

数据库切片

通过将一个表存储在多台服务器上，并将其分割为各自包含行记录一部分的多个片，然后将每个片存储在不同的服务器上，可以确定一个表存储在多台服务器上，以及哪个片存储在哪里。

最初使用的是“硬编码”方式。 这种方式可以理解为字面上直接指定为代码。 假设表是用户表，使用ID奇偶校验将其存储在不同的服务器上，如下图所示。

这种方式的缺点很明显，如果需要增加服务，就需要更改代码，这是不友好的。 比较常见的数据库切片算法是通过剩余散列算法，基于主键ID和服务数量取模，基于剩余确定服务。

搜索引擎我们使用谷歌浏览器的时候，输入搜索关键词，就会出现多少个搜索结果，需要多长时间，它是怎么在这么短的时间内完成这么大数据量的搜索的？

首先考虑一下第一个问题吧。 世界上这么多的页面在哪里？

互联网的存在让你和我隔着屏幕知道你有多帅。 当然，各页面中存在许多指向其他页面的超链接，这样构成了巨大的网络。

对于搜索引擎来说，目标是分析这些页面以获取超链接并下载链接内容。

将URL保存在池中，从池中取出URL模拟请求，下载对应的HTML并存储在服务器中，在分析HTML的内容时，如果存在超链接URL，则检测是否有攀登过，如果没有临时队列，则从后面依次攀登体系结构图如下。 爬行动物的一般方法

对所有获取的网页进行编号，然后获取网页的集合。 然后通过分词技术得到各个单词，构成矩阵如下：分词

这样像单词-文档一样组织被称为倒排索引。 备份索引

谷歌通过创建单词、地址这样的文档，主要通过搜索单词移动到文档的地址列表中，并根据列表中文档的编号显示文档信息，实现快速搜索。

如果搜索结果很多，谷歌如何能更准确地向我们展示我们需要的信息呢？ 很明显有排序功能。 那个是怎么排序的？

谷歌使用了一种叫做“PageRank”的算法。 通过计算每个网页的权重，按权重排序，权重高的自然会显示在前面。 那么，为什么权重高的东西会显示在前面，通常是用户需要的吧。 这必须理解pagerank算法。

在pagerank中，当页面a中包含页面b时，说明a承认了b，并投下一票。 如图中ABCD的四个页面所示，箭头表示超链接的方向，例如，A-B表示a页中包含b超链接的pagerank

你是怎么计算的？

ABCD的初始值都是1，根据关系计算权重。 例如，如果b中包含两个AD页，则权重1被分为两个1/2，分别给予a和d，此时，如果a中包含BCD，则a页的新权重为1/2 1/3 1=11/6。

pagerank的值越推荐，表示用户越想看。 根据每个网页的pagerank值对重排索引中的文档列表进行排序。 前者是用户想看的文档。

这是因为超链接对引入权重的方式进行了排序。 其他还有商品销售次数排行榜和电影点赞和评价分数排行榜等。

此外，如果希望通过关键字搜索找到与搜索词的相关性，则可能会按表示搜索词与文档相关性的字数TF进行排序。 词数TF

例如，在“Java后端”中搜索的结果将来自“后端”的相关技术。

大多数应用都涉及搜索引擎技术。 技术庞大而复杂。 请老铁根据自己的情况进行搜索所需的学习，避免在学校面试中出现盲点。

微服务技术的引入一定是想解决某些痛点。 我不希望在一个系统中，有一点小小的改变会影响全局。 希望各功能模块能明确划分，无论是测试还是运输都能节省更多的时间。

单体体系结构存在哪些问题？

代码分支很难管理

虽然各部门都完成了各自的任务，但最后需要merge在一起成为整个系统，有merge流程经验的人都知道，问题真的很多。 所以不是996

新功能故障

随着项目效果越来越好，用户的需求也越来越多，招聘人员可能也会越来越多。 对初学者来说是无知，老员工忙得要死，新员工成了摸鱼专家

用尽连接

随着用户的增加，每个APP应用程序都必须连接到数据库，这会给与数据库的连接带来很大的压力，甚至会耗尽连接

微服务

“微-------微微一笑很倾城，微笑的，寥寥无几。 顾名思义，讲大系统，分割成一个个小服务，管理每个小服务。 我觉得这样说太不专业了。 专业地

将大APP应用程序划分为小模块

小模块不属于集群

通过远程呼叫依赖各个独立的模块来完成业务的处理

这些小模块被称为------微服务器，整体是所谓的微服务器的框架。

既然分割成了小服务，那么问题就在于这么多小服务如何协调，甚至不知道如何降级该服务，那么在微服务的整体框架中出现了注册中心，谁需要调用提供的接口呢如下图所示，登记中心

从上图可以看出主要有三个概念：

服务提供者

微服务的具体提供者可以通过其他微服务或接口调用

服务消费者

根据服务提供者，按照提供者界面编程即可。 这么轻松，当然有很多细节。 例如，所示的dubbo服务框架中，服务接口经由dubbo框架代理机制访问dubbo客户端，客户端经由服务接口声明去往注册中心

然后，客户端根据负载平衡策略选择其中一个服务，并通过远程调用发送服务调用。 使用微服务需要重视哪一点？

选择中的注意事项

不要用工具勉强提高需求，和业务结合起来也许比较好！

高可用性高可用性是指一台机器挂起也没关系，其他机器正常工作。 用户的体验是一样的。 用户不知道。 卧床休息，你升级了系统，我什么都感觉不到。 那么，高可用性总是有标准的吧。 80%可以吗，还是90%？

有很多原因导致某个系统突然无法访问：

硬件故障

数据库关闭

孙欢

臭虫

光缆断了

可用性指标

用几个9来测定？ 例如，大宝系统的可用性为4个9，意味着99.99%，表示服务保证的正常运行时间只有0.01。

高可用性涉及技术和设备成本，高可用性值并不是越高越好，而是根据特定工具的具体方案在此共享高可用性策略。

冗馀备份

每个服务都有备份。 重复一遍，我们会备份我们的笔记本电脑相关文件。 以防万一。 即使一台服务器停止工作，也可以立即切换，以免用户觉得“这个系统为什么这么垃圾”。

负载平衡

使用多台服务器分担一台服务器的压力，满足高并发要求。 是怎么实现的呢？ APP有心率检测/体检机制。 发现问题的话切换就可以了。 上述数据库主复制也是高可用性方案之一，技术思想还是相通的

负载平衡

限流降级

我们的目标不是没有蛀牙，而是防止整个系统挂起。 流限制是指放弃处理某些请求，使大多数用户都能成功完成任务。

降级：

可以屏蔽当前认为不是有用任务的部分。 例如，在电子商务系统进行秒杀活动时，确认接收功能压力很大，暂时似乎不是核心任务。 另外，系统过期后也会自动确认收货，所以暂时关机，把系统资源留给准备下单放进购物车的太太们

异地多项工作：

有时我会想，发生地震和火灾等自然灾害时，如何处理很多系统的数据。 仔细想想，大型系统往往采用多机房策略，将数据中心部署到任何地方，并在异地完成大量工作。 用户可以访问任何数据中心。 如果出现问题，用户的要求是如何到达不同的机房的？

网域名称解析

安全公司的数据资产，其重要性不言而喻。 系统的稳健性和安全性是保证系统持续运行的基础。 不要因为数据泄露而关注安全问题。

恐怕说到安全问题，首先要考虑的是“用户名、密码”的泄露，数据库脱裤子泄露数据，hack直接获取用户的机密信息，所以我们通常用什么手段、方法全力抵制hack

数据加密

加密用户密码、身份证等敏感数据是常见的方法。 加密方法通常分为单向散列加密、对称加密和不对称加密。

单向散列加密主要出现在单向二字中，是指对明文加密后无法解密。 即使是加密了明文的加密者，也无法从密文中知道该明文是什么。 这意味着加密是单向的，不支持解密。 这么绝对吗？ 这么无敌吗？

那是理论上的，常用的MD5算法是大象的散列加密，可以用彩虹表等来解密。 怎么解读？

简单地说，我们设定密码的时候，通常用生日吗？ 手机号码？ 什么爱情？ 什么520？因为这些组合有限，所以可以制作生日和密文等映射表，从XX虹表中得到密码的明文。 单向散列加密

所以，通常用单向散列加密时需要放一点盐。 这样一来，hack就会得到密文，不知道盐，无法制作彩虹表，恢复明文变得更加困难。

应用场景：通常应用于用户密码加密。 加密和验证的过程如下。 APP场景

在上图中，我们回顾一下某个网站的注册登录模块的用户部分。 用户注册时必须输入用户名和密码。 不会将裸体密码直接存储在数据库中。 否则，就会被脱下裤子，变得赤裸裸。

因此，用户输入密码，APP应用服务器获得密码后，调用单向散列加密算法将已加密的密文存储在数据库中，用户下次登录时，仍然输入密码

但是，一旦成为Web服务器，Web服务器就会再次对输入的密码进行单向散列加密，并将其与从数据库中检索到的密文进行比较。 如果相同，则用户认证成功。 通常，这样的方式可以保证用户密码的安全性。 当然，加入一点盐，会增加解读的难度。

对称加密

对称加密是指利用加密算法和加密密钥，对明文进行加密得到密文，利用相同密钥和对应的解密算法进行解密得到明文。 对称加密

例如，银行卡号、有效期等不是直接存储在数据库中，而是加密后存储在数据库中。

使用时必须解密密文恢复明文。 此时使用对称加密算法，保存时用加密算法加密，使用时用解密算法解密。

非对称加密

不对称加密是指使用一种加密算法和一个加密私钥获得密文，但对明文进行解密时，其加密密钥和加密密钥是不同的。 加密密钥通常称为公钥，解密密钥称为私钥。 非对称加密

其实我们常用的HTTPS是不对称加密的应用场景。 用户与客户端通信时，对数据使用的加密密钥和加密算法进行加密获取密文，到达服务器端后，使用解密密钥和算法进行解密获取明文。

但是，由于非对称会占用大量资源，因此HTTPS不会对每个请求响应使用非对称加密，而是使用非对称加密在客户和服务器之间交换对称加密的密钥，然后对每个请求响应使用对称加密。

综上所述，使用费对称加密保证了对称加密迷药的安全，使用对称加密密钥保证了请求响应数据的安全。

HTTP攻击与防护

HTTP明文协议可以在嗅探工具中清楚地看到对话的内容。 这也是hack攻击阈值最低的方法。 常见的是SQL注入和XSS攻击。

SQL注入包括恶意SQL脚本： SQL注入，当攻击者提交请求参数时

server处理计算后提交到数据库的SQL如下：

selectidfromuserswhereusername=' Mike '；

对于恶意攻击，提交的HTTP请求如下：

http://www.a.com username=Mike '； drop table users； --

此时最终生成的SQL如下：

selectidfromuserswhereusername=' Mike '； drop table users； - '；

查询结束后直接删除表格。 怎么防护？

比较常用的解决方案是使用PrepareStaement进行预编译，首先将SQL传递给数据库生成执行计划，然后hack无论提出什么字符串都只依靠这个执行计划来执行，要么生成新的SQL，要么受到攻击

XSS攻击

在站点间脚本攻击中，攻击者通过构建恶意的浏览器脚本文件，使其在其他用户的浏览器上运行来进行攻击。

假设A向360服务器发送了包含恶意脚本的请求。 服务器将恶意脚本保存在本地数据库中。 当其他正常用户通过该服务器查看信息时，服务器会读取数据库中包含恶意脚本的数据并呈现给用户，从而在用户正常使用浏览器时达到攻击目的。

防御：

常见的情况是在门口截获危险要求，如drop table等，并设置web APP应用程序防火墙隔离危险。 安全保护

其实，大数据在上述方差中拥有关于大数据的知识。 除了数据量在增长外，还有一种方法可以以尽可能低的成本存储更多的数据，从而使企业获利。 上述分布式缓存、负载均衡等技术具有如何抵抗高并发压力的共同特征，但这里的大数据技术主要谈如何满足大规模计算。

通过分析数据，挖掘包括数据库数据、日志信息、用户行为数据等在内的海量数据的价值。 怎么保存这么多种类的数据呢？

分布式文件存储HDFS体系结构

如何将数万台服务器变成统一文件存储系统？ 它使用Namenode服务器作为控制块，负责管理元数据(日志文件名、权限、数据存储位置等)，真正的文件存储在DataNode中。

Mapreduce

存储大量数据的目的是用合适的算法进行数据分析，通过深度学习/机器学习获得预测，获得有效的价值。 对于这样大的文件，不能将HDFS作为普通文件从文件中读取和计算数据。 这样的话，就不知道什么时候在哪里计算了。

作为大数据处理的经典处理框架的MapReduce分为Map和Reduce两个阶段，其中一个在各服务器上启动Map流程，计算后输出一个

让我们看一下WordCount在所有数据中合计相同字数的数据的例子，并详细了解Map和Reduce的过程。 wordcoun计算过程

在本例中，对于由value中的1构成的列表，reduce通过对这些1进行加法操作，得到每个单词的词数。 代码实现如下。

公共类word count {

//Mapper的四个参数：第一个Object表示输入key的类型； 第二个Text指示输入value的类型。 第三个Text指示输出键的类型。 第四个IntWritable表示输出值类型。 map此处的输出是指输出到reduce

publicstaticclassdomapperextendsmapper {

publicstaticfinalintwritableone=newintwritable ( 1； //此处的IntWritable相当于Int类型

公共静态文本word=new text； //Text相当于字符串类型

//map参数将处理后的数据写入上下文，传递给reduce

protectedvoidmap(objectkey，Text value，Context context ) throws IOException，InterruptedException {

//StringTokenizer是Java工具包中用于拆分字符串的类

stringtokenizertokenizer=new string tokenizer ( value.tostring，' )；

//返回从当前位置到下一个分隔符的字符串

word.set(tokenizer.nexttoken )；

把word存到容器里，记住一个数

context.write(word，one )；

}

}

//参数与Map一样，按输入键类型、输入值类型、输出键类型和输出值类型的顺序显示。 由于此处的输入来源于map，因此类型必须与map的输出类型相对应。

publicstaticclassdoreducerextendsreducer {

privateintwritableresult=newintwritable；

@Override

protectedvoidreduce(textkey，Iterable values，Context context ) )。

throws IOException，InterruptedException {

int sum=0；

//for循环遍历，累计得到的values值

for(intwritablevalue:values ) {

sum =value.get；

}

result.set(sum；

context.write(key，result； //将结果保存到上下文中，最终输出格式为“key' 'result”

}

}

publicstaticvoidmain ( string [ ] args ) throws IOException，ClassNotFoundException，InterruptedException {

system.out.println(start )；

Job job=Job.getInstance；

job.setjobname(wordcount )；

path in=new path ( HDFS://* *:9000/user/Hadoop/input/buyer _ favorite1. txt )； //设置此作业的输入数据的路径( ***部分是您的liunx系统的localhost或ip地址) )。

path out=new path ( ' HDFS://* *:9000/user/Hadoop/output/word count ' )； //设置此作业的输出结果的路径

fileinputformat.addinputpath ( job，in )；

fileoutputformat.setoutputpath ( job，out；

job.setjarbyclass ( word count.class )； //设置执行/处理该作业的类

job.setmapperclass ( do mapper.class； 设置实现了//map步骤的类

job.setreducerclass ( do reducer.class； 设置实现Reduce步骤的类

job.setoutputkeyclass ( text.class )； //设定输出结果key的类型

job.setoutputvalueclass ( int writable.class； //设置输出结果value的类型

///执行作业

system.exit ( job.wait for completion ( true )0 : 1)；

system.out.println('end ' )；

}

}

那么，这个map和reduce进程是如何在分布式群集上启动的呢？

图/读启动流程

上图是比较清晰地叙述的整个过程，描述了另一个波浪。 MR主要有两种进程角色： JobTracke r和TaskTracker。

群集中只能有一个JobTracker，但有多个TaskTracker。 JobClient启动后，它将作业提交给JobTracker，然后JobTracker查看文件路径以确定在哪个服务器上启动映射进程。

然后向TaskTracker发送命令，告诉他准备执行任务。 TaskTracker接收到任务后，它会启动TaskRunner下载与任务对应的程序。

map计算完成，TaskTracker操作map的输出结果shuffer，然后加载reduce函数进行后续计算。 这是各模块协同工作的简单过程。

Hive上述过程果然很麻烦。 我们直接写SQL，然后引擎是否帮助生成mapreduce代码。 我们开发web的时候，不用直接写SQL语句，直接交给引擎就很方便。 有的，那就是Hive。

作为一个例子，SQL分割

使用MR计算流程完成此SQL的处理。 MR TO SQL

SparkSpark是一种基于内存计算的大数据并行计算框架。 基于此，我们将解释上面hadoop组件的缺点。

磁盘IO开销很大。 每次运行时都必须从磁盘中读取，并在计算完成后将中间结果保存到磁盘中

表达能力有限。 大多数计算需要转换为Map和Reduce两种操作，难以描述复杂的数据处理

spark的优点：

编程模型不限于map和reduce，具有更灵活的编程模型

spark提供内存计算，提高了迭代运算的效率，并封装了良好的机器学习算法

采用了基于图DAG的任务调度机制

链接

Flink是大数据处理的新规则，发展速度很快，这两年也相继出现了中文资料。 作为流媒体数据流执行引擎，为数据流的分布式计算提供数据分布、数据通信、容错等功能。 此外，Flink还提供机器学习库、图计算库等。

附上去年参加会议回答问题当选的马克杯，嘻嘻。

去年参加了

关于大数据的知识点可以作为延伸点，面试过程中往往存在很多问题，不仅从算法的角度进行阐述，而且可以从这些框架中吸取经验。

相对于以前参与过c/c开发的我来说，闵适大多是Linux的开发。 因为在学校里很少接触系统性的项目，也不知道后端技术的深奥，文章里包含的可能也是一部分，但是还在学校的伙伴知道有这些东西，通过强大的搜索引擎，给自己一个明确的方向，少一些这周的文章到此为止。 goodbye！

积分共享

• 上一篇：暗黑破坏神2地图插件怎么用，暗黑破坏神2重制版地图插件
• 下一篇：牧场物语重聚矿石镇第一年秋攻略，牧场物语重聚矿石镇第一年冬天攻略