分布式开发

Hadoop家族学习路线图 Hadoop家族系列文章 ，主要介绍Hadoop家族产品，常用的项目包括Hadoop, Hive, Pig, HBase, Sqoop, Mahout, Zookeeper, Avro, Ambari, Chukwa，新增加的项目包括，YARN, Hcatalog, Oozie, Cassandra, Hama, Whirr, Flume, Bigtop, Crunch, Hue等。 从2011年开始，中国进入大数据风起云涌的时代，以Hadoop为代表的家族软件，占据了大数据处理的广阔地盘。开源界及厂商，所有数据软件，无一不向Hadoop靠拢。Hadoop也从小众的高富帅领域，变成了大数据开发的标准。在Hadoop原有技术基础之上，出现了Hadoop家族产品，通过“大数据”概念不断创新，推出科技进步。 作为IT界的开发人员，我们也要跟上节奏，抓住机遇，跟着Hadoop一起雄起！ 关于作者： 张丹(Conan), 程序员Java,R,PHP,Javascript weibo：@Conan_Z blog: http://blog.fens.me email: bsspirit@gmail.com 转载请注明出处： http://blog.fens.me/hadoop-family-roadmap/ 前言 使用Hadoop已经有一段时间了，从开始的迷茫

基于SOA的分布式高可用架构和微服务架构，是时下如日中天的互联网企业级系统开发架构选择方案。在核心思想上，两者都主张对系统的横向细分和扩展，按不同的业务功能模块来对系统进行分割并且使用一定的手段实现服务之间的通信，并且基于弹性云服务搭建高可用的分布式解决方案。 但它们之间的区别可能比相似的地方要多，特别是体现在对服务的使用和与云服务的深度结合上。在具体实践中，微服务的架构也可以与其它互联网中间件组合在一起，组成规模更为庞大的SOA分布式系统。本文主要对一个典型的SOA分布式应用的架构和组件做详细的说明。 企业级系统架构的演变 单体式 单体架构即所有系统功能和模块基于MVC的设计模式耦合在一个单体服务器单元中。基于传统的MVC思想，单体应用基于前后端分离的原则，通过Model、Control和View共同来完成一个特点的服务请求。这种传统的架构模式带了了多人团队合作、代码更新和维护、持续部署方面的困难，更重要的是，这种架构无法支持互联网行业对高并发的需求。下图为一个典型商城应用的单体架构及其SSM实现架构： 关于单体式应用的更多资料，可参看： JavaWeb开发之详解Servlet及Servlet容器 基于SSM的Java Web应用开发原理初探 集群 至少在高并发的需求上，单体应用的缺陷是行业所无法忍受的， 那如何提升并发性能呢？一个直接的思路是，把单体应用变成多体，变成集群

一、 Dubbo 介绍 1.1 dubbo 出现的背景 大规模服务化之前，应用可能只是通过 RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。 (1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。 并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。 (2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。 (3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。 其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。 1.2 dubbo 的详细介绍 1. Dubbo 是什么？ Dubbo(注：HSF提供的是分布式服务开发框架

基本概念 本地事务 事务由资源管理器（如DBMS）本地管理 优点：严格的ACID 缺点：不具备分布事务处理能力 全局事务（DTP模型） TX协议：应用或应用服务器与事务管理器的接口 XA协议：全局事务管理器与资源管理器的接口 优点：严格的ACID 缺点：效率非常低 两阶段提交 优点 准备后，仍可提交或回滚 准备时，一致性检查必须OK 准备后，事务结果仍然只在事务内可见 准备后，事务结果已经持久化 缺点： 潜在故障点多带来的脆弱性 准备后，提交前的故障引发一系列隔离与恢复难题 http://book.51cto.com/art/201309/410608.htm 跨域的全局事务（DTP模型） 缺点 更高的协议成本 脆弱，故障点多 故障影响大，恢复困难 复杂，更多架构与平台约束 java企业平台中的分布式事务实现 JTA 面向应用、应用服务器与资源管理器的高层事务接口 JTS JTA事务管理器的实现标准，向上支持JTA，向下通过CORBA OTS实现跨事务域的互操作性 EJB 优点 简单一致的编程模型 跨域分布处理的ACID保证 局限 DTP模型本身的局限 缺少充分公开的大规模、高可用、密集事务应用的成功案例 JMS与分布式事务： http://techv5.com/topic/1371/ 其它资源 ws-transaction标准 jbossTransaction系统 Paxos算法

一、事务的ACID原则 　　数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID。 原子性：操作这些指令时，要么全部执行成功，要么全部不执行。只要其中一个指令执行失败，所有的指令都执行失败，数据进行回滚，回到执行指令前的数据状态。 一致性：事务的执行使数据从一个状态转换为另一个状态，但是对于整个数据的完整性保持稳定。 隔离性：在该事务执行的过程中，无论发生的任何数据的改变都应该只存在于该事务之中，对外界不存在任何影响。只有在事务确定正确提交之后，才会显示该事务对数据的改变。其他事务才能获取到这些改变后的数据。 持久性：当事务正确完成后，它对于数据的改变是永久性的。 二、什么是分布式事务 　　事务在单系统中的表现：多次数据库操作用事务进行管理，来保证ACID原则。 　　　　　　　　 　　但是如果各个模块都是单独独立出来的微服务，进行了分布式部署，单系统里的事务将不能保证各个数据库操作的一致性，因此就需要分布式事务来进行统一管理。 　　　　　　　　 三、分布式事务实现方案 　　现在的分布式事务实现方案有多种，有些已经被淘汰，如基于XA的两段式提交、TCC解决方案，还有本地消息表、MQ事务消息，还有一些开源的事务中间件，如LCN、GTS。 　　1

主要定位于互联网企业架构，已内置企业信息化系统的基础功能和高效的代码生成工具，包括：系统权限组件、数据权限组件、数据字典组件、核心工具 组件、视图操作组件、工作流组件组件、代码生成等。采用分层设计、双重验证、提交数据安全编码、密码加密、访问验证、数据权限验证。 平台简介 是一个 分布式框架 ，提供项目模块化、服务化、热插拔的思想，高度封装安全性的Java EE快速开发平台。本身集成Dubbo服务管控、 Zookeeper注册中心 、Redis分布式缓存技术、 FastDFS分布式 文件系统、ActiveMQ异步消息中间件、 Nginx负载均衡 等分布式技术，使用Maven做项目管理，项目模块化，提高项目的易开发性、扩展性，以Spring Framework为核心容器，Spring MVC为模型视图控制器，MyBatis为数据访问层， Apache Shiro为权限授权层，Ehcahe对常用数据进行缓存，Activit为工作流引擎等。前端集成Bootstrap4 metronic框架，UI响应式、扁平化布局，适应所有PC、Pad、Anroid、ios 移动设备等。 主要定位于互联网企业架构，已内置企业信息化系统的基础功能和高效的代码生成工具，包括：系统权限组件、数据权限组件、数据字典组件、核心工具 组件、视图操作组件、工作流组件、代码生成等。采用分层设计、双重验证、提交数据安全编码

原文: Redis系列文章总结：ASP.Net Core 中如何借助CSRedis实现一个安全高效的分布式锁 引言：最近回头看了看之前和同事一起开发的.Net Core 2.1的项目，其中在多处用到Redis实现的分布式锁，虽然在OnResultExecuting方法中做了防止死锁的处理，但在某些场景下还是会发生死锁的问题，下面我只展示部分代码： 问题： （1）这里setnx设置的值“1”，我想问，你最后del的这个值一定是你自己创建的吗？ （2）图中标注的步骤1和步骤2不是原子操作，会有死锁的概率吗？ 大家可以思考一下先，下面让我们带着这两个问题往下看，下面介绍一下使用Redis实现分布式锁常用的几个命令。 一、使用Redis实现分布式锁常见的几个命令 命令：SETNX key value 说明：将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。 时间复杂度：O(1) 返回值：设置成功，返回1 ； 设置失败，返回 0 命令：GETSET key value 说明：将给定 key 的值设为 value ，并返回 key 的旧值(old value)。当 key 存在但不是字符串类型时，返回一个错误。 时间复杂度：O(1) 返回值

开发工具 1.Eclipse IDE：采用Maven项目管理，模块化。 2.代码生成：通过界面方式简单配置，自动生成相应代码，目前包括三种生成方式（增删改查）：单表、一对多、树结构。生成后的代码如果不需要注意美观程度，生成后即可用。 技术选型（只列了一部分技术） 1、后端 服务框架：Dubbo、zookeeper、Rest服务 缓存：Redis、ehcache 消息中间件：ActiveMQ 负载均衡：Nginx 分布式文件：FastDFS 框架简介--主要定位于互联网企业架构，已内置企业信息化系统的基础功能和高效的代码生成工具，包括：系统权限组件、数据权限组件、数据字典组件、核心工具 组件、视图操作组件、工作流组件组件、代码生成等。采用分层设计、双重验证、提交数据安全编码、密码加密、访问验证、数据权限验证。平台简介 是一个分布式的框架，提供项目模块化、服务化、热插拔的思想，高度封装安全性的Java EE快速开发平台。 本身集成Dubbo服务管控、Zookeeper注册中心、Redis分布式缓存技术、FastDFS分布式文件系统、ActiveMQ异步消息中间件、Nginx负载均衡等分布式技术 使用Maven做项目管理，项目模块化，提高项目的易开发性、扩展性 以Spring Framework为核心容器，Spring MVC为模型视图控制器，MyBatis为数据访问层， Apache

开发工具 1.Eclipse IDE：采用Maven项目管理，模块化。 2.代码生成：通过界面方式简单配置，自动生成相应代码，目前包括三种生成方式（增删改查）：单表、一对多、树结构。生成后的代码如果不需要注意美观程度，生成后即可用。 技术选型（只列了一部分技术） 1、后端 服务框架：Dubbo、zookeeper、Rest服务 缓存：Redis、ehcache 消息中间件：ActiveMQ 负载均衡：Nginx 分布式文件：FastDFS 框架简介--主要定位于互联网企业架构，已内置企业信息化系统的基础功能和高效的代码生成工具，包括：系统权限组件、数据权限组件、数据字典组件、核心工具 组件、视图操作组件、工作流组件组件、代码生成等。采用分层设计、双重验证、提交数据安全编码、密码加密、访问验证、数据权限验证。平台简介 是一个分布式的框架，提供项目模块化、服务化、热插拔的思想，高度封装安全性的Java EE快速开发平台。 本身集成Dubbo服务管控、Zookeeper注册中心、Redis分布式缓存技术、FastDFS分布式文件系统、ActiveMQ异步消息中间件、Nginx负载均衡等分布式技术 使用Maven做项目管理，项目模块化，提高项目的易开发性、扩展性 以Spring Framework为核心容器，Spring MVC为模型视图控制器，MyBatis为数据访问层， Apache

在我的博客中，介绍过很多关于分布式和事务的文章，在阅读本文之前，希望读者可以对这些基础知识有所了解，这里简单把之前的文章列举下，已经按照顺序排好，可按顺序阅读。 初识分布式系统 关于分布式一致性的探究 分布式系统的CAP理论（需要到博客中查看） 分布式系统的BASE理论（需要到博客中查看） Java中的事务――JDBC事务和JTA事务 Java中的事务――全局事务与本地事务 关于分布式事务、两阶段提交协议、三阶提交协议 深入理解分布式系统的2PC和3PC 这里简单总结下以前几篇文章，算是本文的背景知识。在分布式系统中，存在CAP理论，即可用性、数据一致性和分区容错性无法同时满足。所以，一个基于CAP的最终一致性理论BASE理论是目前解决分布式问题比较靠谱的。 在分布式系统中，是无法使用本地事务保证数据的一致性的。一种标准的分布式事务就是全局事务（DTP模型）。他是基于2PC来控制的。但是由于2PC自身就存在同步阻塞的问题，这也就导致全局事务效率很低。所以，这种全局事务并不适合解决大型网站的分布式事务问题。 柔性事务 在业内，主要用来解决分布式事务的方案是使用柔性事务。所谓柔性事务，相比较与数据库事务中的ACID这种刚性事务来说，柔性事务保证的是“基本可用，最终一致。”这其实就是基于BASE理论，保证数据的最终一致性。 虽然柔性事务并不像刚性事务那样完全遵循ACID，但是