分布式开发

为什么写这篇文章？ 目前网上大部分的基于zookeeper，和redis的分布式锁的文章都不够全面。要么就是特意避开集群的情况，要么就是考虑不全，读者看着还是一脸迷茫。坦白说，这种老题材，很难写出新创意，博主内心战战兢兢，如履薄冰，文中有什么不严谨之处，欢迎批评。 博主的这篇文章， 不上代码，只讲分析 。 (1)在redis方面，有开源redisson的jar包供你使用。 (2)在zookeeper方面，有开源的curator的jar包供你使用 因为已经有开源jar包供你使用，没有必要再去自己封装一个，大家出门百度一个api即可，不需要再罗列一堆实现代码。 需要说明的是，Google有一个名为Chubby的粗粒度分布锁的服务，然而，Google Chubby并不是开源的，我们只能通过其论文和其他相关的文档中了解具体的细节。值得庆幸的是，Yahoo！借鉴Chubby的设计思想开发了zookeeper，并将其开源，因此本文不讨论Chubby。至于Tair，是阿里开源的一个分布式K-V存储方案。我们在工作中基本上redis使用的比较多，讨论Tair所实现的分布式锁，不具有代表性。 因此，主要分析的还是redis和zookeeper所实现的分布式锁。 文章结构 本文借鉴了两篇国外大神的文章，redis的作者antirez的《Is Redlock safe?》以及分布式系统专家Martin的

Hadoop的运行模式 Hadoop一般有三种运行模式，分别是： 单机模式（Standalone Mode），默认情况下，Hadoop即处于该模式，使用本地文件系统，而不是分布式文件系统。，用于开发和调试。 伪分布式模式（Pseudo Distrubuted Mode），使用的是分布式文件系统，守护进程运行在本机机器，模拟一个小规模的集群，在一台主机模拟多主机，适合模拟集群学习。 完全分布式集群模式（Full Distributed Mode），Hadoop的守护进程运行在由多台主机搭建的集群上，是真正的生产环境。 这里介绍的就是如何搭建一个Hadoop完全分布式集群。 安装环境介绍 准备了四个服务器，IP为192.168.0.236、192.168.0.237、192.168.0.238、192.168.0.239，其中192.168.0.236作为主节点，其他3个作为从节点。具体版本信息如下： CentOS 7.4 JDK 8 Hadoop 2.10.0 准备安装环境 设置主机名 在各个服务器上修改对应的主机名： #在192.168.0.236上执行： hostnamectl set-hostname onemore-hadoop-master #在192.168.0.237上执行： hostnamectl set-hostname onemore-hadoop-slave1

Hadoop的运行模式 Hadoop一般有三种运行模式，分别是： 单机模式（Standalone Mode），默认情况下，Hadoop即处于该模式，使用本地文件系统，而不是分布式文件系统。，用于开发和调试。 伪分布式模式（Pseudo Distrubuted Mode），使用的是分布式文件系统，守护进程运行在本机机器，模拟一个小规模的集群，在一台主机模拟多主机，适合模拟集群学习。 完全分布式集群模式（Full Distributed Mode），Hadoop的守护进程运行在由多台主机搭建的集群上，是真正的生产环境。 这里介绍的就是如何搭建一个Hadoop完全分布式集群。 欢迎关注微信公众号： 万猫学社 ，每周一分享Java技术干货。 安装环境介绍 准备了四个服务器，IP为192.168.0.236、192.168.0.237、192.168.0.238、192.168.0.239，其中192.168.0.236作为主节点，其他3个作为从节点。具体版本信息如下： CentOS 7.4 JDK 8 Hadoop 2.10.0 欢迎关注微信公众号： 万猫学社 ，每周一分享Java技术干货。 准备安装环境 设置主机名 在各个服务器上修改对应的主机名： #在192.168.0.236上执行： hostnamectl set-hostname onemore-hadoop-master

分布式RPC框架Apache Dubbo 1. 软件架构的演进过程 软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演进过程，下面我们分别了解一下这几个架构。 1.1 单体架构 架构说明： ​ 全部功能集中在一个项目内（All in one）。 架构优点： ​ 架构简单，前期开发成本低、开发周期短，适合小型项目。 架构缺点： ​ 全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。 ​ 技术栈受限，只能使用一种语言开发。 ​ 系统性能扩展只能通过扩展集群节点，成本高。 1.2 垂直架构 架构说明： ​ 按照业务进行切割，形成小的单体项目。 架构优点： ​ 技术栈可扩展（不同的系统可以用不同的编程语言编写）。 架构缺点： ​ 功能集中在一个项目中，不利于开发、扩展、维护。 ​ 系统扩张只能通过集群的方式。 ​ 项目之间功能冗余、数据冗余、耦合性强。 1.3 SOA架构 SOA全称为Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。 站在功能的角度，把业务逻辑抽象成可复用的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。 架构说明： ​

Zookeeper 是一个典型的 分布式数据一致性 的解决方案，是谷歌 Chubby 的开源实现，在分布式系统中有非常广泛的应用。 分布式应用程序可以基于它来实现 数据发布/订阅、分布式协调/通知、集群管理、Master 选举、命名服务、分布式锁和分布式队列 等功能。 在诸如 HDFS、Yarn、HBase、Kafka、Flink 等著名分布式系统中都使用 Zookeeper 来实现各自的 分布式协调机制 。 在大数据系统中， Zookeeper 是必不可少的组件 ，所有大数据平台上必定运行着一组 Zookeeper 服务器集群。 对于大部分业务开发人员来说，Zookeeper 是属于幕后默默干活奉献的角色，在开发过程中接触的往往都是基于 Zookeeper 的上层系统，这使得很多开发人员对 Zookeeper 处于一种 知道它很重要，但是对它缺不熟悉 的状态。 虽然在大部分工作中，开发人员并不需要完全了解 Zookeeper 是如何实现的，但是保持对这个重要组件的了解与探索能够在一定程度上 提升对现有分布式系统实现的理解 。 本文将会从 Zookeeper 的 基本概念 开始介绍，随后使用客户端API模拟了一个简单的 Master-Slaves 集群 中主从节点的行为，并在之后讨论到其 内部实现的机制与服务端相关的参数配置 ，为分布式系统应用揭开最后一层神秘的面纱。

场景 什么是分布式系统 分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统。 分布式系统是建立在网络之上的软件系统。 注： 博客： https://blog.csdn.net/badao_liumang_qizhi 关注公众号 霸道的程序猿 获取编程相关电子书、教程推送与免费下载。 实现 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。 单一应用结构特点 适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。 缺点： 1、性能扩展比较难 2、协同开发问题 3、不利于升级维护 垂直应用结构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。 垂直应用结构特点 通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。 缺点： 公用模块无法重复利用，开发性的浪费 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

1. CAP理论 C: Consistency 一致性 A: Availability 可用性 P: Partition tolerance 分区容错性 CAP定理：一个分布式系统不可能同时满足CAP三个要求，最多只能同时满足其中两项。 1.1. CA: 放弃分区容错性，所有数据放一个节点，退回单机模式。 1.2. CP: 放弃可用性，一旦网络故障，受影响服务需要等待恢复时间，系统处于不可用状态。 1.3. AP: 放弃一致性，这里指放弃强一致性，确保最终一致性。 大多数分布式系统的选择。 2. BASE理论 BASE: B ase A vailable(基本可用)， S oft state(软状态), E ventually consistent(最终一致性)。 BASE是对CAP一致性和可用性权衡的结果。 1. 基本可用：指分布式系统出现不可预知故障时，允许损失部分可用性，响应时间合理延长，服务上适当降级。 2. 软状态: 允许分布式系统中的数据处于中间状态，允许各节点数据同步时存在延时。 3. 最终一致性：允许系统中所有数据副本，在经过一段时间同步后，最终能够达到一个一致的状态。不需要实时保证系统的数据一致性。 3. 两阶段提交 (2PC) 数据库支持2PC，又叫XA transactions。 MySQL从5.5版，Oracle从7版，SQL Server 2005开始支持

老套路 1、什么是Redis 2、为什么要用Redis 3、怎么用Redis 4、使用Redis过程中遇到的问题 1、什么是Redis 　　介绍Redis之前先了解一下Nosql（非关系型数据库） 　　我们都知道MySql是一种关系型数据库，那什么是非关系型数据库呢？它又是做什么呢？ 　　为了解决高并发、高可用、高可扩展，大数据存储等一系列问题而产生的数据库解决方案，就是NoSql。它不能替代关系型数据库，只能作为关系型数据库的一个良好补充。 　　Redis是使用c语言开发的一个高性能 键值数据库 。Redis通过 键值类型 存储数据。 　　 Redis使用场景 ：缓存（数据查询、短连接、新闻内容、商品内容等等） 　　（最多使用） 分布式集群架构中的session分离 　　聊天室的在线好友列表 　　任务队列 　　（秒杀、抢购、12306等等） 应用排行榜 　　网站访问统计 　　数据过期处理（可以精确到毫秒） 2、为什么要用Redis 　　为了解决高并发、高可用、高可扩展，大数据存储等一系列问题，MySql不能很好为我们提供服务，引入了Redis。 　　那么为什么要用Redis呢？ 　　1、速度快：首先Redis由C语言编写，纯内存操作，第二个 核心是基于非阻塞的IO多路复用机制，单线程避免了多线程的频繁上下文切换问题 　　2、支持多种数据类型，5种数据类型： String、Hash

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列