扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
把in里的数据分段处理。
站在用户的角度思考问题，与客户深入沟通，找到东源网站设计与东源网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：做网站、成都网站建设、企业官网、英文网站、手机端网站、网站推广、域名注册、网站空间、企业邮箱。业务覆盖东源地区。
或者新建个表，把in里的数据批量插入进去再update ... where id in (select id from ...) ，批量插入这个操作的速度应该是有优化办法的,postgresql中有copy命令，其他的不太清楚了。
速度方面我想不到非常好的办法
这种情况最好使用专业报表软件来处理。
推荐FineReport报表软件。这是一种类Excel的报表工具，神似于Excel主界面的设计器、多sheet界面、完美导入Excel数据源、可输出Excel等多种格式，而且支持多源分片，使杂乱无章的数据井然有序。
FineReport是纯java报表软件，天然支持多数据源（集），同一张报表的数据可同时来自多个数据表，多个不同的数据库，或者多个不同的用户自定义数据视图，然后在报表中可直接相互运算形成最终的报表。
FineReport连接数据源的方式多种多样，支持通过JDBC的方式直接连接数据库，或通过JNDI的方式与应用服务器共享数据连接。支持的数据库类型如Oracle、 DB2、SQLServer、MySQL等主流的数据库，除此之外，自定义的程序数据源，文本数据源，Excel数据源，XML数据源等等都可以直接作为报表的数据源来进行设计工作，同时数据源还具有无限的扩展性，可以支持WebService, SOA等标准的数据。因此它可以完美解决你的问题。
在良好的数据库设计基础上，能有效地使用索引是SQL Server取得高性能的基础，SQL Server采用基于代价的优化模型，它对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部分开销是磁盘I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需读几次磁盘就可以了。
所以如果建立了合理的索引，优化器就能利用索引加速数据的查询过程。但是，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。本文就SQL Server索引的性能问题进行了一些分析和实践。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面，所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快。每张表只能建一个聚簇索引，并且建聚簇索引需要至少相当该表120%的附加空间，以存放该表的副本和索引中间页。建立聚簇索引的思想是：
1、大多数表都应该有聚簇索引或使用分区来降低对表尾页的竞争，在一个高事务的环境中，对最后一页的封锁严重影响系统的吞吐量。
2、在聚簇索引下，数据在物理上按顺序排在数据页上，重复值也排在一起，因而在那些包含范围检查(between、、=、、=)或使用group by或order by的查询时，一旦找到具有范围中第一个键值的行，具有后续索引值的行保证物理上毗连在一起而不必进一步搜索，避免了大范围扫描，可以大大提高查询速度。
3、在一个频繁发生插入操作的表上建立聚簇索引时，不要建在具有单调上升值的列(如IDENTITY)上，否则会经常引起封锁冲突。
4、在聚簇索引中不要包含经常修改的列，因为码值修改后，数据行必须移动到新的位置。
5、选择聚簇索引应基于where子句和连接操作的类型。
聚簇索引的侯选列是：
1、主键列,该列在where子句中使用并且插入是随机的。
2、按范围存取的列，如pri_order 100 and pri_order 200。
3、在group by或order by中使用的列。
4、不经常修改的列。
5、在连接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server缺省情况下建立的索引是非聚簇索引，由于非聚簇索引不重新组织表中的数据，而是对每一行存储索引列值并用一个指针指向数据所在的页面。换句话说非聚簇索引具有在索引结构和数据本身之间的一个额外级。一个表如果没有聚簇索引时,可有250个非聚簇索引。每个非聚簇索引提供访问数据的不同排序顺序。在建立非聚簇索引时，要权衡索引对查询速度的加快与降低修改速度之间的利弊。另外，还要考虑这些问题：
1、索引需要使用多少空间。
2、合适的列是否稳定。
3、索引键是如何选择的，扫描效果是否更佳。
4、是否有许多重复值。
对更新频繁的表来说，表上的非聚簇索引比聚簇索引和根本没有索引需要更多的额外开销。对移到新页的每一行而言，指向该数据的每个非聚簇索引的页级行也必须更新，有时可能还需要索引页的分理。从一个页面删除数据的进程也会有类似的开销，另外，删除进程还必须把数据移到页面上部，以保证数据的连续性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情况：
1、某列常用于集合函数(如Sum,....)。
2、某列常用于join,order by,group by。
3、查寻出的数据不超过表中数据量的20%。
三、覆盖索引(covering indexes)的使用
覆盖索引是指那些索引项中包含查寻所需要的全部信息的非聚簇索引，这种索引之所以比较快也正是因为索引页中包含了查寻所必须的数据,不需去访问数据页。如果非聚簇索引中包含结果数据,那么它的查询速度将快于聚簇索引。
但是由于覆盖索引的索引项比较多,要占用比较大的空间。而且update操作会引起索引值改变。所以如果潜在的覆盖查询并不常用或不太关键，则覆盖索引的增加反而会降低性能。
四、索引的选择技术
p_detail是住房公积金管理系统中记录个人明细的表，有890000行，观察在不同索引下的查询运行效果，测试在C/S环境下进行，客户机是IBM PII350(内存64M),服务器是DEC Alpha1000A(内存128M),数据库为SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date’19990101’ and op_date’
19991231’ and pri_surplus1300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date’19990101’ and
pay_month between‘199908’ and’199912’
不建任何索引查询1 1分15秒
查询2 1分7秒
在op_date上建非聚簇索引查询1 57秒
查询2 57秒
在op_date上建聚簇索引查询1 1秒
查询2 52秒
在pay_month、op_date、pri_surplus1上建索引查询1 34秒
查询2 1秒
在op_date、pay_month、pri_surplus1上建索引查询1 1秒
查询2 1秒
从以上查询效果分析，索引的有无，建立方式的不同将会导致不同的查询效果，选择什么样的索引基于用户对数据的查询条件,这些条件体现于where从句和join表达式中。一般来说建立索引的思路是：
(1)主键时常作为where子句的条件，应在表的主键列上建立聚簇索引，尤其当经常用它作为连接的时候。
(2)有大量重复值且经常有范围查询和排序、分组发生的列，或者非常频繁地被访问的列，可考虑建立聚簇索引。
(3)经常同时存取多列，且每列都含有重复值可考虑建立复合索引来覆盖一个或一组查询，并把查询引用最频繁的列作为前导列，如果可能尽量使关键查询形成覆盖查询。
(4)如果知道索引键的所有值都是唯一的，那么确保把索引定义成唯一索引。
(5)在一个经常做插入操作的表上建索引时，使用fillfactor(填充因子)来减少页分裂，同时提高并发度降低死锁的发生。如果在只读表上建索引，则可以把fillfactor置为100。
(6)在选择索引键时，设法选择那些采用小数据类型的列作为键以使每个索引页能够容纳尽可能多的索引键和指针，通过这种方式，可使一个查询必须遍历的索引页面降到最小。此外，尽可能地使用整数为键值，因为它能够提供比任何数据类型都快的访问速度。
五、索引的维护
上面讲到,某些不合适的索引影响到SQL Server的性能,随着应用系统的运行,数据不断地发生变化,当数据变化达到某一个程度时将会影响到索引的使用。这时需要用户自己来维护索引。索引的维护包括：
1、重建索引
随着数据行的插入、删除和数据页的分裂，有些索引页可能只包含几页数据，另外应用在执行大块I/O的时候，重建非聚簇索引可以降低分片，维护大块I/O的效率。重建索引实际上是重新组织B-树空间。在下面情况下需要重建索引：
(1)数据和使用模式大幅度变化。
(2)排序的顺序发生改变。
(3)要进行大量插入操作或已经完成。
(4)使用大块I/O的查询的磁盘读次数比预料的要多。
(5)由于大量数据修改，使得数据页和索引页没有充分使用而导致空间的使用超出估算。
(6)dbcc检查出索引有问题。
当重建聚簇索引时，这张表的所有非聚簇索引将被重建。
2、索引统计信息的更新
当在一个包含数据的表上创建索引的时候，SQL Server会创建分布数据页来存放有关索引的两种统计信息：分布表和密度表。优化器利用这个页来判断该索引对某个特定查询是否有用。但这个统计信息并不动态地重新计算。这意味着，当表的数据改变之后，统计信息有可能是过时的，从而影响优化器追求最有工作的目标。因此，在下面情况下应该运行update statistics命令：
(1)数据行的插入和删除修改了数据的分布。
(2)对用truncate table删除数据的表上增加数据行。
(3)修改索引列的值。
六、结束语
实践表明，不恰当的索引不但于事无补，反而会降低系统的执行性能。因为大量的索引在插入、修改和删除操作时比没有索引花费更多的系统时间。例如下面情况下建立的索引是不恰当的：
1、在查询中很少或从不引用的列不会受益于索引，因为索引很少或从来不必搜索基于这些列的行。
2、只有两个或三个值的列，如男性和女性(是或否)，从不会从索引中得到好处。
另外，鉴于索引加快了查询速度，但减慢了数据更新速度的特点。可通过在一个段上建表，而在另一个段上建其非聚簇索引，而这两段分别在单独的物理设备上来改善操作性能。
一、java基础
学习任何一门编程语言，首先要学习的是基础语法，开启Java学习的第一步，当然就是深入掌握计算机基础、编程基础语法，面向对象，集合、IO流、线程、并发、异常及网络编程，这些我们称之为JavaSE基础。当你掌握了这些内容之后，你就可以做出诸如：电脑上安装的迅雷下载软件、QQ聊天客户端、考勤管理系统等桌面端软件。
JavaSE基础是Java中级程序员的起点，是帮助你从小白到懂得编程的必经之路。
在Java基础板块中有6个子模块的学习：
基础语法，可帮助你建立基本的编程逻辑思维；
面向对象，以对象方式去编写优美的Java程序；
集合，后期开发中存储数据必备技术；
IO，对磁盘文件进行读取和写入基础操作；
多线程与并发，提高程序效率；
异常，编写代码逻辑更加健全；
网络编程，应用服务器学习基础，完成数据的远程传输。
学习该阶段，可以完成一些简单的管理系统、坦克大战游戏、QQ通信等。
技术树
二、数据库
互联网最具价值的是数据，任何编程语言都需要解决数据存储问题,而数据存储的关键技术是数据库。MySQL和Oracle都是广受企业欢迎的数据库管理系统。Java程序和数据库通信的最常见技术是JDBC，Druid和C3P0。学习这些数据库技术后，可以掌握数据库运维技术、复杂业务表结构设计规范、工作中常见的SQL操作、软件数据存储等。
数据库不仅仅是Java开发工程师的必学课程，也是其他语言都需要掌握的技能。用于对交互过程中客户的数据进行存储。
该板块包括关系型数据库和非关系型数据库。
例如：MySQL、oracle、redis、MongoDB等。数据库学习完毕后，可以将数据存储到数据库中，也可以通过SQL语句从数据库中查询数据，结合Java项目可以实现动态站点的数据的保存。
技术树
三、前端技术
浏览器展示给用户看到的网页就是前端，前端有三大基础技术分别为Html、CSS、JavaScript，这些学完后，为了做出更好、更炫的交互式体验效果，我们还需要学习jQuery、ElementUI、Vue、Ajax，以及打包工具webpack。学完这些技术后，我们可以开发微信小程序、响应式网站、移动端网站、开发类似京东一样的B2B2C商城、管理后台等。
Javaweb阶段包括前端、数据库和动态网页。Javaweb是互联网项目的入门课程，是学习后面高进阶课程的基础。
首先，我们先看一下前端板块。该板块主要包括如下几个模块：
HTML5，网页制作标记语言；
CSS，对HTML制作网页进行美化；
JavaScript，嵌入在页面中的脚本语言，具备逻辑性；
Vue，前端框架，简化了与服务器端交互的操作，用户良好的交互体验是必不可少的。
学习前端技术后，可以完成类似京东、淘宝的前端工程的编写。
技术树
四、动态网页
掌握前端技术只能做静态网站，但它页面数据一成不变，而动态网站可以根据数据库中变更的数据实现不同的内容展示，应用更广泛，因此程序员必须要学会做动态网站。使用Java做动态网站，我们需要学习Servlet、Filter、Session、Cookie、JSP、EL表达式、JSTL等做动态网站的完整知识体系，学完可研发出OA系统、内容网站、BBS等。
动态网页是中级程序员服务器端编程的基础，是高级框架学习的必备课程，后期学习的框架、服务底层都是基于动态网页技术之上的。
该板块包括Javaweb核心技术、包括Servlet、Request、Response、Cookie和Session等，通过这些技术的学习可以完成动态站点开发，可更好的完成服务器端与客户的交互，让页面的数据“动”起来，做出小型的应用系统。
技术树
五、编程强化
前面学了JavaSE基础，但它在企业级应用中程序处理业务的效率并不高、扩展差，编程强化是对JavaSE基础的加强，将针对性的提高程序处理业务的执行效率、增强程序扩展性。编程强化将加强多线程高级学习，涉及线程内存、线程通信等技术。学完以后，能增加一个中级程序员的知识储备，无论在面试过程中还是将来技术的深入打一个良好的基础。
编程强化是对解决实际问题方面做一个深入的了解和应用，是对JavaSE基础的加强，对后期自动以框架和对一些服务框架的底层理解做支撑。
编程强化板块主要包括如下几个模块：多线程高级、涉及线程内存、线程通信等；JVM优化，对JVM底层进行调优来提高项目执行效率；NIO，同步非阻塞IO来提高效率。
学习该阶段，可以对原有项目进行优化从而使程序更快更稳定。
技术树
六、软件项目管理
公司开发都是团队协同开发，为更好的掌握实际开发，我们还需要学习常用的项目管理平台、版本控制器、项目构建工具以及自动化部署工具。项目开发一定是有版本升级的，管理好项目进度和版本需要Git、Maven、Sonar这样的系统平台。学习完软件项目管理后，将掌握整个项目实际开发过程以及整个项目开发过程中所使用协同开发工具。
JavaSE基础是Java中级程序员的起点，是帮助你从小白到懂得编程的必经之路。
在Java基础板块中有6个子模块的学习：基础语法，可帮助你建立基本的编程逻辑思维；面向对象，以对象方式去编写优美的Java程序；集合，后期开发中存储数据必备技术；IO，对磁盘文件进行读取和写入基础操作；多线程与并发，提高程序效率；异常，编写代码逻辑更加健全；网络编程，应用服务器学习基础，完成数据的远程传输。
学习该阶段，可以完成一些简单的管理系统、坦克大战游戏、QQ通信等。
技术树
七、热门技术框架
Javaweb掌握后，已经具备企业中实际项目的开发能力了，但它开发效率低，代码量大，开发周期长、开发成本高。企业中广泛使用一些优秀的框架技术来解决上述问题，因此我们还需要学习框架技术，项目开发中主流的Java框架技术有SpringMVC、Spring、MyBatis、MyBatis Plus、SpringData等。这些框架技术都是一个优秀程序员所必备的技能。
使用Javaweb进行企业级开发是完全可以的，但是开发效率比较低，所以对常用的逻辑操作进行封装就形成了框架，因此框架是企业开发的入门技能。
热门框架板块主流框架有如下几个：Spring框架，占据统治地位，其生态系统涉及各个方面解决方案；MyBatis框架，使用ORM思想对数据库进行操作。
该板块学习后，就可以进行真实企业级项目开发了，做出的项目也会更加符合企业要求。
技术树
八、分布式架构
需要用到分布式微服务的技术。学习完该阶段课程，可以具备大型SOA架构和微服务架构能力，能掌握大型微服务项目必备技术和实际经验。企业发展过程中，业务量和用户量逐渐增加，为了保证系统的可用性，系统越做越复杂，研发人员增多，大家很难共同维护一个复杂的系统，往往修改部分内容，导致牵一发而动全身，所以我们需要升级系统架构，
随着互联网的发展，业务的复杂性和用户的体验性都需要提高，所以分布式架构出现了。该板块主要讲解的是分布式架构的相关解决方案。
主要包括如下模块：Dubbo，高性能的 RPC 服务发布和调用框架；SpringBoot，简化Spring应用的初始搭建以及开发过程；Spring Cloud，一系列框架的有序集合，如服务发现注册、配置中心、负载均衡、断路器、数据监控等。
该板块的学习，可以具备大型互联网项目开发的必备技术和实际经验，为进入BATJ打下基础
技术树
九、服务器中间件
在分布式系统架构中，服务与服务之间的异步通信，是非常常见的需求之一，消息中间件的诞生正是为了解决这类问题。目前市面上的主流消息中间件有RabbitMQ、RocketMQ、Kafka，我们将学习这3个消息中间件，实现分布式项目中的异步通信。学习完这些后，可以实现分布式项目的异步通信、分布式应用日志收集、分布式事务等。
中间件板块是大型互联网项目中必备的。服务中间件可以帮助各子模块间实现互相访问，消息共享或统一访问等功能。其包括远程服务框架中间件，例如阿里（Apache）的RPC框架Dubbo等；消息队列中间件，例如：阿里巴巴开源分布式中间件RocketMQ、高吞吐量消息发布和流处理服务Kafka等。
学习服务中间件是中级JavaEE工程师必要技术，也是JavaEE架构师必须精通的技术。
技术树
十、服务器技术
程序开发完成后，我们把它们打包部署到服务器中运行，所以我们需要学习常见的服务器技术，常见的服务器有Linux和Window server，Linux性能高，是当前主流。我们写好的项目需要用一个软件运行起来，这个软件叫web容器，我们需要在服务器上安装web容器来发布项目，当前主流的web容器有tomcat、jetty、nginx、undertow。
不管是使用原生Javaweb进行开发，还是使用框架进行开发，项目最终需要对外发布才能供全世界的人访问到，而服务器板块就可以解决这个问题，所以服务器是项目发布的必要技术。该板块包括虚拟化和web应用服务器的学习，主要包括如下几个模块：Vmware，虚拟机软件；Linux，专门用于服务器的系统；Nginx，集群部署时反向代理服务器；Tomcat，项目发布时主要使用的服务器。
该板块学习后，我们就可以把开发好的项目发布到服务器中，然后供你的小伙伴远程访问了，超酷！
技术树
十一、容器技术
具备了服务器操作系统及web容器，我们就可以部署单机的站点，在分布式系统中，几十上百的服务，如果使用单机这种部署方式，会投入很高的人力，同时出错的几率也大。所以服务器虚拟化技术Docker也称为如今的必备技术了，Docker可以帮助运维人员实行快速部署，批量维护.使用Kubernetes实现自动化部署、大规模可伸缩、应用容器管理。
容器化技术是近两年超级火的一个专题，通过容器化技术可以对环境进行打包，方便移植，大大提高了开发效率。该板块包括容器化技术Docker和其平台管理引擎Kubernetes，其中，Docker 是一个开源的应用容器引擎，可以打包应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows 机器上，也可以实现虚拟化。而Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效。通过该板块的学习，你可以通过上述技术快速搭建环境，节省开发时间，提高开发效率。
技术树
十二、业务解决方案
企业开发中会遇到一些通用的业务场景，诸如：搜索引擎、缓存、定时任务、工作流、报表导出、日志管理、系统监控等，那么这些通用的解决方案也有现成优秀的免费开源中间件，可供使用。诸如：ElasticSearch、Lucene、Solr、redis、MongoDB、slf4J、ECharts、Quartz、POI等。业务解决方案课程的业务方案和技术难点，解决了企业开发中90%以上的痛点和难点。
虽然我们已经具备了基础技术和高阶技术，但是要想与企业开发相接轨，还需要对实际项目的业务解决方案进行探究。而此版块就是在实际业务场景中的真实解决方案集合，常用的业务解决方案有如下：搜索业务场景解决方案、日志收集与分析场景解决方案、工作流引擎场景解决方案、任务调度场景解决方案、地图开发平台场景解决方案、支付开放平台场景解决方案、图表可视化场景解决方案。通过分析实际业务来学习这个解决方案技术集，完全可以达到中级甚至高级工程师水平。
技术树
java学习路线大陆传送门
介绍
分布式计算简单来说，是把一个大计算任务拆分成多个小计算任务分布到若干台机器上去计算，然后再进行结果汇总。 目的在于分析计算海量的数据，从雷达监测的海量历史信号中分析异常信号(外星文明)，淘宝双十一实时计算各地区的消费习惯等。
海量计算最开始的方案是提高单机计算性能，如大型机，后来由于数据的爆发式增长、单机性能却跟不上，才有分布式计算这种妥协方案。 因为计算一旦拆分，问题会变得非常复杂，像一致性、数据完整、通信、容灾、任务调度等问题也都来了。
举个例子，产品要求从数据库中100G的用户购买数据，分析出各地域的消费习惯金额等。 如果没什么时间要求，程序员小明就写个对应的业务处理服务程序，部署到服务器上，让它慢慢跑就是了，小明预计10个小时能处理完。 后面产品嫌太慢，让小明想办法加快到3个小时。
平常开发中类似的需求也很多，总结出来就是，数据量大、单机计算慢。 如果上Hadoop、storm之类成本较高、而且有点大才小用。 当然让老板买更好的服务器配置也是一种办法。
利用分片算法
小明作为一个有追求有理想的程序员，决定用介于单机计算和成熟计算框架的过度解决方案，这样成本和需求都能满足了。 分布式计算的核心在于计算任务拆分，如果数据能以水平拆分的方式，分布到5台机器上，每台机器只计算自身的1/5数据，这样即能在3小时内完成产品需求了。
如上所述，小明需要把这些数据按照一定维度进行划分。 按需求来看以用户ID划分最好，由于用户之间没有状态上的关联，所以也不需要事务性及二次迭代计算。 小明用简单的hash取模对id进行划分。
f(memberid) % 5 = ServerN
这样程序可以分别部署到5台机器上，然后程序按照配置只取对应余数的用户id，计算出结果并入库。 这种方式多机之间毫无关联，不需要进行通信，可以避免很多问题。 机器上的程序本身也不具备分布式的特性，它和单机一样，只计算自身获取到的数据即可，所以如果某台机器上程序崩溃的话，处理方式和单机一样，比如记录下处理进度，下次从当前进度继续进行后续计算。
利用消息队列
使用分片方式相对比较简单，但有如下不足之处。
它不具有负载均衡的能力，如果某台机器配置稍好点，它可能最先计算完，然后空闲等待着。也有可能是某些用户行为数据比较少，导致计算比较快完成。
还有一个弊端就是每台机器上需要手动更改对应的配置， 这样的话多台机器上的程序不是完全一样的，这样可以用远程配置动态修改的办法来解决。
小明这种方式引入了个第三方，消息队列。 小明先用一个单独的程序把用户信息推送到消息队列里去，然后各台机器分别取消费这个队列。 于是就有了3个角色：
推送消息的，简称Master。
消息队列，这里以Rabbitmq为例。
各个处理程序，简称Worker或Slave都行。
虽然仅仅引入了个第三方，但它已经具备了分布式计算的很多特性。
计算任务分发。 Master把需要计算的用户数据，不断的推送消息队列。
程序一致性。 Worker订阅相同的消息队列即可，无需更改程序代码。
任意扩容。 由于程序完全一样，意味着如果想要加快速度，重复部署一份程序到新机器即可。 当然这是理论上的，实际当中会受限于消息队列、数据库存储等。
容灾性。 如果5台中某一台程序挂了也不影响，利用Rabbitmq的消息确认机制，机器崩溃时正在计算的那一条数据会在超时，在其他节点上进行消费处理。
Hadoop简介
Hadoop介绍已经相当多了，这里简述下比如:”Hadoop是一套海量数据计算存储的基础平台架构”，分析下这句话。
其中计算指的是MapReduce，这是做分布式计算用的。
存储指的是HDFS，基于此上层的有HBase、Hive，用来做数据存储用的。
平台，指可以给多个用户使用，比如小明有一计算需求，他只需要按照对应的接口编写业务逻辑即可，然后把程序以包的形式发布到平台上，平台进行分配调度计算等。 而上面小明的分布式计算设计只能给自己使用，如果另外有小华要使用就需要重新写一份，然后单独部署，申请机器等。Hadoop最大的优势之一就在于提供了一套这样的完整解决方案。
下面找了介绍Hadoop的概览图，跟小明的设计做对比下:
图中“大数据计算任务” 对应小明的100G用户数据的计算任务。
”任务划分“ 对应Master和消息队列。
“子任务” 对应Worker的业务逻辑。
”结果合并“ 对应把每个worker的计算结果入库。
“计算结果” 对应入库的用户消费习惯数据。
PS：为了方便描述，把小明设计的分布式计算，叫做小和尚。
MapReduce
由于MapReduce计算输入和输出都是基于HDFS文件，所以大多数公司的做法是把mysql或sqlserver的数据导入到HDFS，计算完后再导出到常规的数据库中，这是MapReduce不够灵活的地方之一。 MapReduce优势在于提供了比较简单的分布式计算编程模型，使开发此类程序变得非常简单，像之前的MPI编程就相当复杂。
狭隘的来讲，MapReduce是把计算任务给规范化了，它可以等同于小和尚中Worker的业务逻辑部分。 MapReduce把业务逻辑给拆分成2个大部分，Map和Reduce，可以先在Map部分把任务计算一半后，扔给Reduce部分继续后面的计算。 当然在Map部分把计算任务全做完也是可以的。 关于Mapreduce实现细节部分不多解释，有兴趣的同学可以查相关资料或看下楼主之前的C#模拟实现的博客【探索C#之微型MapReduce】。
如果把小明产品经理的需求放到Hadoop来做，其处理流程大致如下：
把100G数据导入到HDFS
按照Mapreduce的接口编写处理逻辑，分Map、Reduce两部分。
把程序包提交到Mapreduce平台上，存储在HDFS里。
平台中有个叫Jobtracker进程的角色进行分发任务。 这个类似小和尚的Master负载调度管理。
如果有5台机器进行计算的话，就会提前运行5个叫TaskTracker的slave进程。 这类似小和尚worker的分离版，平台把程序和业务逻辑进行分离了， 简单来说就是在机器上运行个独立进程，它能动态加载、执行jar或dll的业务逻辑代码。
Jobtracker把任务分发到TaskTracker后，TaskTracker把开始动态加载jar包，创建个独立进程执行Map部分，然后把结果写入到HDFS上。
如果有Reduce部分，TaskTracker会创建个独立进程把Map输出的HDFS文件，通过RPC方式远程拉取到本地，拉取成功后，Reduce开始计算后续任务。
Reduce再把结果写入到HDFS中
从HDFS中把结果导出。
这样一看好像是把简单的计算任务给复杂化了，其实如果只有几台计算任务的话，使用Mapreduce确实是杀鸡用牛刀了。 如果有TB、PB级别的数据、跑在成百上千台计算节点上，Mapreduce的优势才会体现出来。 其计算框架图架构如下：
离线计算
通常称Mapreduce及小和尚这种计算为离线计算，因为它对已经持久化的文件数据进行计算，不能实时响应。 还有个原因就是它的处理速度比较慢，它的输入和输出源都是基于HDFS设计，如果数据不是一开始就写入到HDFS上，就会涉及到数据导入导出，这部分相对耗费时间。 而且它的数据流动是基于文件系统的，Map部分输出的数据不是直接传送到Reduce部分，而是先写入HDFS再进行传送。
处理速度慢也是Mapreduce的不足之处，促使了后面实时计算的诞生。
另外个缺点是Mapreduce的计算任务流比较单一，它只有Map、Reduce两部分。 简单的可以只写一部分逻辑来解决，如果想拆分成多个部分，如逻辑A、逻辑B、逻辑C等， 而且一部分计算逻辑依赖上一次计算结果的话，MapReduce处理起来就比较困难了。 像storm框架解决此类问题的方案，也称为流式计算，下一章继续补充。
要了解三次握手四次挥手的过程，就需要对TCP的报头以及有限状态机的概念有所了解，本文将介绍TCP报头的字段的含义，以及有限状态机各个状态的意义，最后对三次握手和四次挥手的过程做介绍
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
这里将介绍TCP报头的特性以及TCP报头各个字段的含义
.工作在传输层面向连接协议
.全双工协议
.半关闭
.错误检查
.将数据打包成段，排序
.确认机制
.数据恢复，重传
.流量控制，滑动窗口
.拥塞控制，慢启动和拥塞避免算法
.源端口、目标端口 ：计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个
. 序列号 ：表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从0 开始
. 确认号 ：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送发：我希望你（指发送方）下次发送的数据的第一个字节数据的编号是这个确认号
. 数据偏移 ：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出TCP 报文段的数据起始处距离TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节
. URG ：表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效
. ACK ：表示是否前面的确认号字段是否有效。ACK=1，表示有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段
. PSH ：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中
. RST ：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段
. SYN ：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段
. FIN ：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段
. 窗口大小 ：表示现在充许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量
. 校验和 ：提供额外的可靠性
. 紧急指针 ：标记紧急数据在数据字段中的位置
. 选项部分 ：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节
常见选项 ：
.最大报文段长度：MaxiumSegment Size，MSS
.窗口扩大：Windows Scaling
.时间戳：Timestamps
.a 最大报文段长度
指明自己期望对方发送TCP报文段时那个数据字段的长度。默认是536字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS接入这一字段。MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中
.b 窗口扩大
为了扩大窗口，由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产
生（如卫星通信），需要更大的窗口来满足性能和吞吐率，所以产生了这个窗口扩大选项
.c 时间戳
可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中，当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文
2.3 TCP协议PORT
.传输层通过port号，确定应用层协议
.Port number:
. tcp ：0-65535,传输控制协议，面向连接的协议；通信前需要建立虚拟链路；结束后拆除链路.
. udp ：0-65535,User Datagram Protocol，无连接的协议.
. IANA :互联网数字分配机构（负责域名，数字资源，协议分配）
0-1023：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https)
1024-49151：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用，1433/tcp(SqlServer)，1521/tcp(oracle),
3306/tcp(mysql),11211/tcp/udp(memcached)
49152-65535：动态端口或私有端口，客户端程序随机使用的端口
其范围的定义：/proc/sys/net/ipv4/ip_local_port_range
有限状态机，（英语：Finite-state machine, FSM），又称有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。
常见的计算机就是使用有限状态机作为计算模型的：对于内存的不同状态，CPU通过读取内存值进行计算，更新内存中的状态。CPU还通过消息总线接受外部输入设备（如键盘、鼠标）的指令，计算后更改内存中的状态，计算结果输出到外部显示设备（如显示器），以及持久化存储在硬盘。
TCP协议也存在有限状态机的概念，TCP 协议的操作可以使用一个具有 11 种状态的有限状态机来表示
.CLOSED 没有任何连接状态
.LISTEN 侦听状态，等待来自远方TCP端口的连接请求
.SYN-SENT 在发送连接请求后，等待对方确认
.SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认
.ESTABLISHED 代表传输连接建立，双方进入数据传送状态
.FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认
.FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求
.TIME-WAIT 完成双向传输连接关闭，等待所有分组消失
.CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认
.LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失
.CLOSING 双方同时尝试关闭传输连接，等待对方确认
.客户端通过connect系统调用主动与服务器建立连接connect系统调用首先给服务器发送一个同步报文段，使连接转移到SYN_SENT状态。
.此后connect系统调用可能因为如下两个原因失败返回：
.1、如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一个复位报文段，connect调用失败。
.2、如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段，则connect调用失败。
.connect调用失败将使连接立即返回到初始的CLOSED状态。如果客户端成功收到服务器的同步报文段和确认，则connect调用成功返回，连接转移至ESTABLISHED状态
.当客户端执行主动关闭时，它将向服务器发送一个结束报文段FIN，同时连接进入FIN_WAIT_1状态。若此时客户端收到服务器专门用于确认目的的确认报文段，则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器也关闭连接（发送结束报文段），则客户端将给予确认并进入TIME_WAIT状态
.客户端从FIN_WAIT_1状态可能直接进入TIME_WAIT状态（不经过FIN_WAIT_2状态），前提是处于FIN_WAIT_1状态的服务器直接收到带确认信息的结束报文段（而不是先收到确认报文段，再收到结束报文段）
注意，客户端先发送一个FIN给服务端，自己进入了FIN_WAIT_1状态，这时等待接收服务端的报文，该报文会有三种可能：
a 只有服务端的ACK，只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续2MSL(TCP报文段在网络中的最大生存时间,RFC 1122标准的建议值是2min).客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失
b 只有服务端的FIN，回应一个ACK给服务端，进入CLOSING状态，然后接收到服务端的ACK时，进入TIME_WAIT状态
c 同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态
.收到服务器ACK后，客户端处于FIN_WAIT_2状态，此时需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则它将一直停留在这个状态。如果不是为了在半关闭状态下继续接收数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等服务器关闭连接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿进程类似）。
.Linux为了防止孤儿连接长时间存留在内核中，定义了两个内核参数：
./proc/sys/net/ipv4/tcp_max_orphans 指定内核能接管的孤儿连接数目
./proc/sys/net/ipv4/tcp_fin_timeout指定孤儿连接在内核中生存的时间
TCP协议中的三次握手和四次挥手
客户机端的三次握手和四次挥手
服务器端的三次握手和四次挥手
1 client 首先发送一个连接试探，此时ACK=0,表示确认号无效，SYN=1表示这是一个请求连接或连接接受报文，同时表示这个数据包不携带数据，seq=x表示此时client自己数据的初始序号是x,这时候client进入syn_sent状态，表示客户端等等服务器的回复
2 server 监听到连接请求报文后，如同意建立连接，则向client发送确认，将TCP报文首部的SYN和ACK都置为1，因为client上一个请求连接的报文中seq=x,所以服务器端这次就发ack=x+1,表示服务器端希望客户端下一个报文段的第一个数据字节序号是x+1，同时表示x为止的所有数据都已经正确收到了，其中，此时服务器端发送seq=y表示server自己的初始序号是y，这时服务器进入了SYN_RCVD状态，表示服务器已经收到了客户端的请求，等待client的确认。
3 client收到确认后还要再次给服务器端发送确认，同时携带要发给server的数据。ACK=1表示确认号ack=y+1有效，client这时的序号seq为x+1
一旦client确认后，这个TCP连接的client 和 server 都直接进入到established状态，可以发起http请求了
4.2 四次挥手详解
第一次挥手：client向server，发送FIN报文段，表示关闭数据传送，此时ACK=0,seq=u,表示客户端此时数据的报文序号是u，此时，client进入FIN_WAIT_1状态，表示没有数据要传输了
第二次挥手：server收到FIN报文段后进入CLOSE_WAIT状态（被动关闭），然后发送ACK确认，表示同意你关闭请求了，主机到主机的数据链路关闭，同时发送seq=v,表示此时server端的数据包字节序号是v,ack=u+1,表示希望client发送的下一个包的序号是u+1,表示确认了序号u之前的包都已经收到，客户端收到server的ACK报文后，进入FIN_WAIT_2状态
第三次挥手：server等待client发送完数据，发送FIN=1，ACK=1到client请求关闭，server进入LAST_ACK状态。此时发送的seq有变化，因为上一个ACK的后server端可能又发送了一些数据，说以数据字节序号发送了变化，为w,但是ack还是保持不变
第四次挥手：client收到server发送的FIN后，回复ACK确认到server，client进入TIME_WAIT状态。发送ack=w+1,表示希望服务器下个发送的报文的字节序号是w+1,确认了服务器之前发送的w字节都已经正确收到，发送seq=u+1表示当前client的字节序号是u+1.server收到client的ACK后就关闭连接了，状态为CLOSED。client等待2MSL，仍然没有收到server的回复，说明server已经正常关闭了，client关闭连接。
其中，MSL（Maximum Segment Lifetime）：报文最大生存时间，是任何报文段被丢弃前在网络内的最长时间。当client回复server的FIN后，等待(2-4分钟)，即使两端的应用程序结束。
TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态的原因是如果client直接进入CLOSED状态，由于IP协议不可靠性或网络问题，导致client最后发出的ACK报文未被server接收到，那么server在超时后继续向client重新发送FIN，而client已经关闭，那么找不到向client发送FIN的连接，server这时收到RST并把错误报告给高层，不符合TCP协议的可靠性特点。如果client直接进入CLOSED状态，而server还有数据滞留在网络中，当有一个新连接的端口和原来server的相同，那么当原来滞留的数据到达后，client认为这些数据是新连接的。等待2MSL确保本次连接所有数据消失。
当客户端等待2MSL后服务器端没有再次发送确认的报文后，client认为该次断开连接已经正常结束，client进入closed状态。四次挥手正式结束
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
微信二维码
移动版官网