您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
分布式计算简单来说，是把一个大计算任务拆分成多个小计算任务分布到若干台机器上去计算，然后再进行结果汇总。 目的在于分析计算海量的数据，从雷达监测的海量历史信号中分析异常信号(外星文明)，淘宝双十一实时计算各地区的消费习惯等。
海量计算最开始的方案是提高单机计算性能，如大型机，后来由于数据的爆发式增长、单机性能却跟不上，才有分布式计算这种妥协方案。 因为计算一旦拆分，问题会变得非常复杂，像一致性、数据完整、通信、容灾、任务调度等问题也都来了。
举个例子，产品要求从数据库中100G的用户购买数据，分析出各地域的消费习惯金额等。 如果没什么时间要求，程序员小明就写个对应的业务处理服务程序，部署到服务器上，让它慢慢跑就是了，小明预计10个小时能处理完。 后面产品嫌太慢，让小明想办法加快到3个小时。
平常开发中类似的需求也很多，总结出来就是，数据量大、单机计算慢。 如果上Hadoop、storm之类成本较高、而且有点大才小用。 当然让老板买更好的服务器配置也是一种办法。
小明作为一个有追求有理想的程序员，决定用介于单机计算和成熟计算框架的过度解决方案，这样成本和需求都能满足了。 分布式计算的核心在于计算任务拆分，如果数据能以水平拆分的方式，分布到5台机器上，每台机器只计算自身的1/5数据，这样即能在3小时内完成产品需求了。
如上所述，小明需要把这些数据按照一定维度进行划分。 按需求来看以用户ID划分最好，由于用户之间没有状态上的关联，所以也不需要事务性及二次迭代计算。 小明用简单的hash取模对id进行划分。
<pre style="margin:0px;
padding:0px;
white-space:pre-wrap;
overflow-wrap:break-word;
font-family:"
Courier New"
!important;
font-size:12px !important;
">f(memberid) % 5 = ServerN</pre>这样程序可以分别部署到5台机器上，然后程序按照配置只取对应余数的用户id，计算出结果并入库。 这种方式多机之间毫无关联，不需要进行通信，可以避免很多问题。 机器上的程序本身也不具备分布式的特性，它和单机一样，只计算自身获取到的数据即可，所以如果某台机器上程序崩溃的话，处理方式和单机一样，比如记录下处理进度，下次从当前进度继续进行后续计算。
使用分片方式相对比较简单，但有如下不足之处。
小明这种方式引入了个第三方，消息队列。 小明先用一个单独的程序把用户信息推送到消息队列里去，然后各台机器分别取消费这个队列。 于是就有了3个角色：
虽然仅仅引入了个第三方，但它已经具备了分布式计算的很多特性。
Hadoop介绍已经相当多了，这里简述下比如:"Hadoop是一套海量数据计算存储的基础平台架构"，分析下这句话。
下面找了介绍Hadoop的概览图，跟小明的设计做对比下:
PS：为了方便描述，把小明设计的分布式计算，叫做小和尚。
由于MapReduce计算输入和输出都是基于HDFS文件，所以大多数公司的做法是把mysql或sqlserver的数据导入到HDFS，计算完后再导出到常规的数据库中，这是MapReduce不够灵活的地方之一。 MapReduce优势在于提供了比较简单的分布式计算编程模型，使开发此类程序变得非常简单，像之前的MPI编程就相当复杂。
狭隘的来讲，MapReduce是把计算任务给规范化了，它可以等同于小和尚中Worker的业务逻辑部分。 MapReduce把业务逻辑给拆分成2个大部分，Map和Reduce，可以先在Map部分把任务计算一半后，扔给Reduce部分继续后面的计算。 当然在Map部分把计算任务全做完也是可以的。
如果把小明产品经理的需求放到Hadoop来做，其处理流程大致如下：
这样一看好像是把简单的计算任务给复杂化了，其实如果只有几台计算任务的话，使用Mapreduce确实是杀鸡用牛刀了。 如果有TB、PB级别的数据、跑在成百上千台计算节点上，Mapreduce的优势才会体现出来。 其计算框架图架构如下：
通常称Mapreduce及小和尚这种计算为离线计算，因为它对已经持久化的文件数据进行计算，不能实时响应。 还有个原因就是它的处理速度比较慢，它的输入和输出源都是基于HDFS设计，如果数据不是一开始就写入到HDFS上，就会涉及到数据导入导出，这部分相对耗费时间。 而且它的数据流动是基于文件系统的，Map部分输出的数据不是直接传送到Reduce部分，而是先写入HDFS再进行传送。
处理速度慢也是Mapreduce的不足之处，促使了后面实时计算的诞生。
另外个缺点是Mapreduce的计算任务流比较单一，它只有Map、Reduce两部分。 简单的可以只写一部分逻辑来解决，如果想拆分成多个部分，如逻辑A、逻辑B、逻辑C等， 而且一部分计算逻辑依赖上一次计算结果的话，MapReduce处理起来就比较困难了。 像storm框架解决此类问题的方案，也称为流式计算，下一章继续补充。 
针对于上面所涉及到的知识点我总结出了有1到5年开发经验的程序员在面试中涉及到的绝大部分架构面试题及答案做成了文档和架构视频资料免费分享给大家（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术资料），希望能帮助到您面试前的复习且找到一个好的工作，也节省大家在网上搜索资料的时间来学习，也可以关注我一下以后会有更多干货分享。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。