分布式部署

一、架构简介 目标 单机搭建mongodb分布式集群(副本集 + 分片集群)，演示mongodb分布式集群的安装部署、简单操作。 说明 在同一个vm启动由两个分片组成的分布式集群，每个分片都是一个PSS(Primary-Secondary-Secondary)模式的数据副本集； Config副本集采用PSS(Primary-Secondary-Secondary)模式。 二、配置说明 端口通讯 当前集群中存在shard、config、mongos共12个进程节点，端口矩阵编排如下： 编号 实例类型 1 mongos 2 mongos 3 mongos 4 config 5 config 6 config 7 shard1 8 shard1 9 shard1 10 shard2 11 shard2 12 shard2 内部鉴权 节点间鉴权采用keyfile方式实现鉴权，mongos与分片之间、副本集节点之间共享同一套keyfile文件。 官方说明 账户设置 管理员账户：admin/Admin @01 ，具有集群及所有库的管理权限 应用账号：appuser/AppUser @01 ，具有appdb的owner权限 关于初始化权限 keyfile方式默认会开启鉴权，而针对初始化安装的场景，Mongodb提供了 localhost-exception机制 ，

1. Git与SVN的主要区别 Git是目前世界上最先进的分布式版本控制系统 SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器那里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，宽带够大，速度够快，如果在联网下，网速慢的话，呃呃呃呃呃 Git是分布式版本控制系统，就是没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就可以不联网，反正都在自己的电脑上，如果两个人需要交流的话，要把各自的修改推送给对方就可以了。 （来自 lenovouser） 2. 什么是集群、分布式、集中式、伪分布式 （1）集中式：将项目等部署到同一台机器上，对机器性能要求比较高，一般会用多台机器进行备份，否则，如果机器出现死机等状况，整个项目将不能运行。例如：你要盖房子，如果只有一个人给你盖，那么这个人如果来不了，你又没找到合适的替代他，那么你的房子只能停工。 （2）分布式：将一个项目分成几块，分别在不同的机器上运行，相比较集中式，对机器的要求有所下降。 （3）集群：与集中式、分布式完全不同的概念，分布式一定是集群，但是集群不一定是分布式（例如：集中式的多机备份） 集群只是相对于机器数量的一个概念 （4）伪分布式：不是真正的分布式

关于分布式锁的概念网上太多了，这里就不罗嗦了。对于开发者来说，最关心的应该是什么情况下使用分布式锁。 使用分布式锁，一般要满足以下几个条件: · 分布式系统（关键是分布式） · 共享资源（各系统访问同一资源，资源的载体可能是传统关系型数据库或者NoSQL） · 同步访问（没有同步访问，谁管你资源竞争不竞争） 场景案例 · 光说不练假把式，上点干货。管理后台的部署架构（多台tomcat服务器+redis+mysql）就满足使用分布式锁的条件。多台服务器要访问redis全局缓存的资源，如果不使用分布式锁就会出现问题。 看如下伪代码： long N=0L; //N从redis获取值 if(N<5){ N++； //N写回redis } · 从redis获取值N，对数值N进行边界检查，自加1，然后N写回redis中。 这种应用场景很常见，像秒杀，全局递增ID、IP访问限制等。以IP访问限制来说，恶意攻击者可能发起无限次访问，并发量比较大，分布式环境下对N的边界检查就不可靠，因为从redis读的N可能已经是脏数据。传统的加锁的做法（如java的synchronized和Lock）也没用，因为这是分布式环境，这个同步问题的救火队员也束手无策。在这危急存亡之秋，分布式锁终于有用武之地了。 所谓知己知彼，百战百胜。要想用好他，首先你要了解他。分布式锁可以基于很多种方式实现，比如zookeeper

快速使用分布式定时任务 xxl-job 需要linux服务器环境安装： jdk1.8 , docker 1.docker安装mysql数据库 网站 https://hub.docker.com/_/mysql?tab=tags 查找mysql的版本，拉取镜像 命令： docker pull mysql:5.7 通过镜像运行容器 命令：docker run --name mysql-master --privileged=true -v /home/mysql/master-data:/var/lib/mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7 2.找到xxl-job-admin的docker镜像信息，选择2.1.0版本 网址： https://hub.docker.com/r/xuxueli/xxl-job-admin/tags 拉取镜像命令：docker pull xuxueli/xxl-job-admin:2.1.0 3.下载xxl-job 源码，网址 https://gitee.com/xuxueli0323/xxl-job/tree/2.1.0 4.找到源码中的数据库脚本 xxl-job\doc\db\tables_xxl_job.sql ，在数据库中执行，创建数据库和表 5.启动xxl-job

一、ZooKeeper 基本概念 1、ZooKeeper 是什么？ Zookeeper官网地址： http://zookeeper.apache.org/ Zookeeper官网文档地址： http://zookeeper.apache.org/doc/trunk/index.html ZooKeeper 是Hadoop下的一个子项目，它是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等； 它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据，简单示例图如下： 2、ZooKeeper设计目标： ZooKeeper允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。 名称空间由ZooKeeper中的数据寄存器组成 - 称为znode，这些类似于文件和目录。 与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

ZooKeeper是 Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeeper典型的应用场景。 ZooKeeper基本原理 1. 数据模型 如上图所示，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识，比如上图中第三层的第一个ZNode, 它的路径是/app1/c1。在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)，这个特性非常有用，在后面的典型应用场景中会介绍到。另外，每个ZNode上还存储了其Acl信息，这里需要注意，虽说ZNode的树形结构跟Unix文件系统很类似，但是其Acl与Unix文件系统是完全不同的，每个ZNode的Acl的独立的，子结点不会继承父结点的，关于ZooKeeper中的Acl可以参考之前写过的一篇文章《 说说Zookeeper中的ACL 》。 2.重要概念 2.1 ZNode 前文已介绍了ZNode

前言 分布式锁一般有3中实现方式： 数据库乐观锁； 基于Redis的分布式锁； 基于ZooKeeper的分布式锁。 以下将详细介绍如何正确地实现Redis分布式锁。 可靠性 首先，为了确保分布式锁的可用，我们至少要确保锁的实现的同时，要满足以下四个条件： 互斥性。 在任意时刻，只有一个客户端持有锁。 不会发生死锁。 即使一个客户端在持有锁的期间发生崩溃而没有主动释放锁，也能保证后续其他客户端能加锁。 具有容错性。 只要大部分的 Redis 节点正常运行，客户端就可以加锁和解锁。 解铃还须系铃人。 加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。 代码实现 　组件依赖 　　首先我们通过 Maven 引入 Jedis 开源组件，在 pom.xml 文件加入以下代码： 1 <dependency> 2 <groupId>redis.clientsgroupId</groupId> 3 <artifactId>jedisartifactId</artifactId> 4 <version>2.9.0version</version> 5 </dependency> 　加锁代码 　　先放代码，后面再解释为什么这样实现： 1 public class RedisTool { 2 3 private static final String LOCK_SUCCESS = "OK";

面试官心理分析 从这个问题开始，面试官就已经进入了 实际的生产问题 的面试了。 一个分布式系统中的某个接口，该如何保证幂等性？这个事儿其实是你做分布式系统的时候必须要考虑的一个生产环境的技术问题。啥意思呢？ 你看，假如你有个服务提供一些接口供外部调用，这个服务部署在了 5 台机器上，接着有个接口就是 付款接口 。然后人家用户在前端上操作的时候，不知道为啥，总之就是一个订单 不小心发起了两次支付请求 ，然后这俩请求分散在了这个服务部署的不同的机器上，好了，结果一个订单扣款扣两次。 或者是订单系统调用支付系统进行支付，结果不小心因为 网络超时 了，然后订单系统走了前面我们看到的那个重试机制，咔嚓给你重试了一把，好，支付系统收到一个支付请求两次，而且因为负载均衡算法落在了不同的机器上，尴尬了。。。 所以你肯定得知道这事儿，否则你做出来的分布式系统恐怕容易埋坑。 面试题剖析 这个不是技术问题，这个没有通用的一个方法，这个应该 结合业务 来保证幂等性。 所谓 幂等性 ，就是说一个接口，多次发起同一个请求，你这个接口得保证结果是准确的，比如不能多扣款、不能多插入一条数据、不能将统计值多加了 1。这就是幂等性。 其实保证幂等性主要是三点： 对于每个请求必须有一个唯一的标识，举个栗子：订单支付请求，肯定得包含订单 id，一个订单 id 最多支付一次，对吧。 每次处理完请求之后

谈谈业务中使用分布式的场景 首先，需要了解系统为什么使用分布式。 随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面： 1.应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。 2.底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。 #场景1：应用系统集群的 Session 共享 应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。 #场景2：应用系统的服务化拆分 服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。 #场景3：底层数据库的压力分摊 如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。 Session 分布式方案 #基于 nfs(net filesystem) 的 Session 共享 将共享服务器目录 mount 各服务器的本地 session 目录，session 读写受共享服务器 io 限制

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐