分布式开发

https://www.zhihu.com/question/20004877 分布式是对业务的纵向拆分，目的是为了降低维护成本，方便后期点对点的纠错或者优化； 集群是对服务的横向扩展，目的是增强服务能力，降低服务压力 集群是个物理形态，分布式是个工作方式。 只要是一堆机器，就可以叫集群，他们是不是一起协作着干活，这个谁也不知道；一个程序或系统，只要运行在不同的机器上，就可以叫分布式，嗯，C/S架构也可以叫分布式。 集群一般是物理集中、统一管理的，而分布式系统则不强调这一点。 所以，集群可能运行着一个或多个分布式系统，也可能根本没有运行分布式系统；分布式系统可能运行在一个集群上，也可能运行在不属于一个集群的多台（2台也算多台）机器上。 前面的答案说的不太准确， 其实分布式不一定就是不同的组件，同一个组件也可以，关键在于是否通过交换信息的方式进行协作。比如说Zookeeper的节点都是对等的，但它自己就构成一个分布式系统。 也就是说， 分布式是指通过网络连接的多个组件，通过交换信息协作而形成的系统。而集群，是指同一种组件的多个实例，形成的逻辑上的整体。 可以看出这两个概念并不完全冲突，分布式系统也可以是一个集群，例子就是前面说的zookeeper等，它的特征是服务之间会互相通信协作。是分布式系统不是集群的情况，就是多个不同组件构成的系统；是集群不是分布式系统的情况

1、为什么要使用消息队列? 分析:一个用消息队列的人，不知道为啥用，有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。 回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰 (1)解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。 我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住

微服务系统 事务 事务的原则 事务：是一种可靠，一致的方式，访问和操作数据库中数据的程序单元 原则特性： 原子性， 一致性 ，隔离性：事务之间互不干扰，持久性： 没提交事务之前，系统挂了，数据还是之前的数据，并没有被改变 mysql 查询事务的隔离级别 SELECT @@GLOBAL.tx_isolation,@@tx_isolation; 默认是 REPEATABLE-READ 可重复读 什么是 可重复读？ 比如 开启一个 事务，这个事务只读某一个表的 某条 的取数据。 但是这时候并没有提交 ， 但是 这时候另一个事务 修改了 该条数据，并提交了事务。 此时 之前的 的那个为 提交的事务，再次查询数据，这时候的数据是 未改变之前的数据，并不会因为 其他事务修改了数据提交了事务， 而显示出来 修改的值。 mysql 可重复读 修复 因为mysql 的事务隔离级别是 可重复读，另一个事务a 在执行更新数据，但是未提交， 这时候 一个事务 读取到 值之后， 另一个事务a更新了数据， 那么这时候 之前读取的值就不对了，怎么解决呢？ 1， 要么改 数据隔离级别是 序列化的, 可以修改当前 连接 session的 事务隔离级别 2. 使用 FOR UPDATE 这时候 比如 SELECT * FROM T_USER FOR UPDATE 此时 如果该表有未 提交事务，将等待 事务提交完成

MyCat是什么？ 从定义和分类来看，它是一个开源的分布式数据库系统，是一个实现了MySQL协议的服务器，前端用户可以把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分表分库读写分离，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里。也可以指定多个写库多个读库。 MyCat发展到目前的版本，已经不是一个单纯的MySQL代理了，它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储。而在最终用户看来，无论是那种存储方式，在MyCat里，都是一个传统的数据库表，支持标准的SQL语句进行数据的操作，这样一来，对前端业务系统来说，可以大幅降低开发难度，提升开发速度。 MyCat可以干什么？ 单纯的读写分离，此时配置最为简单，支持读写分离，主从切换 分表分库，对于超过 1000 万的表进行分片，最大支持 1000 亿的单表分片 多租户应用，每个应用一个库，但应用程序只连接 Mycat，从而不改造程序本身，实现多租户化 报表系统，借助于 Mycat 的分表能力，处理大规模报表的统计 替代 Hbase

HDFS作为分布式文件管理系统，Hadoop的基础。HDFS体系机构包括：NameNode、DataNode、SecondaryNameNode。Hadoop shell上传的文件是存放在DataNode的block中，通过linux shell只能看到block，不能看到文件。 以下是本章的重点： 分布式文件系统与HDFS HDFS体系结构与基本概念 HDFS的shell操作 搭建eclipse开发环境 Java接口及常用api Hadoop的RPC机制 Hadoop读写数据的过程分析 1.分布式文件系统与HDFS DFS:Distributed File System 分布式文件管理系统：数据量越来越多，在一个操作系统管辖的范围存不下，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，因此迫切需要一种系统来管理多台机器上的文件。分布式文件管理系统就是一种允许文件通过网络在 多台主机 上分享的文件系统，可让 多机器 上的 多用户 分享文件和存储空间。 HDFS只是DFS中的一种，适应于 一次写、多次查询 的情况，不支持并发写情况，小文件不合适。HDFS：把客户端的大文件存放在很多节点的数据块中，记住三个关键词：文件、节点、数据块。 更简单的一点来说：HDFS就是windows中存在的文件系统。 2. HDFS的shell操作 HDFS是存取数据的分布式文件系统

前言 Spring Could作为目前最流行基于Java开发的构建微服务的完整框架。发现目前相关系列教程太少，本文是基于官网教程做的一套翻译。 何为Spring Cloud? Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁定，领导选举，分布式会话，集群状态）。 分布式系统的协调导致锅炉板模式，使用Spring Cloud开发人员可以快速站起来实现这些模式的服务和应用程序。 它们适用于任何分布式环境。 Spring Cloud能做什么？ Spring Cloud专注于为典型用例提供良好的开箱即用体验，并为其他用户提供可扩展性机制。 分布式/版本化配置 服务注册和发现 路由 服务到服务电话 负载均衡 断路器 全球锁 领导选举和集群国家 分布式消息 Spring Cloud采用非常声明的方法，通常只需更改类路径和/或注释即可获得许多功能。 作为发现客户端的示例应用程序： @SpringBootApplication @EnableDiscoveryClient public class Application { public static void main(String[] args) { SpringApplication.run(Application.class,

1.Hadoop是什么？为什么要使用Hadoop？平常如何使用Hadoop完成工作？ Hadoop是一个大数据开源框架。The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. The project includes these modules: Hadoop Common : The common utilities that support the other Hadoop modules. Hadoop Distributed File System (HDFS™) : A distributed file system that provides high-throughput access to application data. Hadoop YARN

分布式场景常见问题及解决方案 前言: 本文主要是根据平常学习过程中遇到的一些分布式场景常见问题，并作出了解析，有不对或者需要补充的地方，希望广大的程序员朋友们及时改进，另外，想要学习，分布式的朋友，我提供一张分布式的学习路线思维导图，望可以给你们一点建议。 下面进入正题 一、分布式锁 分布式锁是在分布式场景下一种常见技术，通常通过基于redis和zookeeper来实现，本文主要介绍redis分布式锁和zookeeper分布式锁的实现方案和对比： （1）基于redis的普通实现 这个方案的加锁主要实现是基于redis的”SET key 随机值 NX PX 过期时间（毫秒）”指令，NX代表只有key不存在时才设置成功，PX代表在过期时间后会自动释放。 这个方案的释放锁是通过lua脚本删除key的方式，判断value一样则删除key。 使用随机值的原因是如果某个获取到锁的客户端阻塞了很长时间，导致了它获取到的锁已经自动释放，此时可能有其他客户端已经获取到了锁，如果直接删除是有问题的，所以要通过随机值加上lua脚本去判断如果value相等时再删除。 这个方案存在一个问题就是，如果采用redis单实例可能会存在单点故障问题，但如果采用普通主从方式，如果主节点挂了key还没来得及同步到从节点，此时从节点被切换到了主节点，由于没有同步到数据别人就会拿到锁。 （2）redis的RedLock算法

Redis分布式锁进化史 张佳 2019年08月14日 Redis分布式锁进化史 近两年来微服务变得越来越热门，越来越多的应用部署在分布式环境中，在分布式环境中，数据一致性是一直以来需要关注并且去解决的问题，分布式锁也就成为了一种广泛使用的技术，常用的分布式实现方式为Redis，Zookeeper，其中基于Redis的分布式锁的使用更加广泛。 但是在工作和网络上看到过各个版本的Redis分布式锁实现，每种实现都有一些不严谨的地方，甚至有可能是错误的实现，包括在代码中，如果不能正确的使用分布式锁，可能造成严重的生产环境故障，本文主要对目前遇到的各种分布式锁以及其缺陷做了一个整理，并对如何选择合适的Redis分布式锁给出建议。 各个版本的Redis分布式锁 V1.0 tryLock(){ SETNX Key 1 EXPIRE Key Seconds } release(){ DELETE Key } 这个版本应该是最简单的版本，也是出现频率很高的一个版本，首先给锁加一个过期时间操作是为了避免应用在服务重启或者异常导致锁无法释放后，不会出现锁一直无法被释放的情况。 这个方案的一个问题在于每次提交一个Redis请求，如果执行完第一条命令后应用异常或者重启，锁将无法过期，一种改善方案就是使用Lua脚本（包含SETNX和EXPIRE两条命令）

#0 系列目录# 分布式事务 【分布式事务系列】提出疑问和研究过程 对于我们这种初学者，可能会使用Spring带给我们的@Transactional，可能了解JTA，可能会使用jotm、atomikos，又会遇到一些名词XA，支持XA的数据库驱动等等诸多问题，然后就会愈加混乱，自然形成一个疑问，庞大的事务体系的全貌到底是什么样？ #1 需要解决的疑惑# 下面就要具体列出一系列需要解决的问题。 ##1.1 对于事务模型## 三种事务模型是什么？各自的特点是什么？各自的缺陷是什么？ ##1.2 Spring对于事务模型的支持## Spring自己的一系列接口设计： PlatformTransactionManager 事务管理器 TransactionDefinition 事务定义 TransactionStatus 事务状态 等等 上述一系列接口的实现是如何对非分布式和分布式事务的支持的呢？ ##1.3 针对分布式事务的规范## X/Open DTP模型是什么？几个重要的概念是什么？ XA规范是什么？ 2PC是什么？ ##1.4 针对JTA## JTA是什么？JTS又是什么？ JTA与上述的规范又是什么关系？ JTA的接口都有哪些？分别是什么作用 JTA接口中有一个javax.transaction.TransactionManager