分布式架构

一.MFS概述 MooseFS是一个分布式存储的框架，其具有如下特性： （1）通用文件系统，不需要修改上层应用就可以使用（那些需要专门api的dfs很麻烦！）。 （2）可以在线扩容，体系架构可伸缩性极强。（官方的case可以扩到70台了！） （3）部署简单。 （4）高可用，可设置任意的文件冗余程度（提供比raid1+0更高的冗余级别，而绝对不会影响读或者写的性能，只会加速！） （5）可回收在指定时间内删除的文件（“回收站”提供的是系统级别的服务，不怕误操作了，提供类似oralce 的闪回等高级dbms的即时回滚特性！） （6）提供netapp，emc，ibm等商业存储的snapshot特性。（可以对整个文件甚至在正在写入的文件创建文件的快照） （7）google filesystem的一个c实现。 （8）提供web gui监控接口。 # 读写原理 1.MFS的读数据过程 （1） client当需要一个数据时，首先向master server发起查询请求； （2）管理服务器检索自己的数据，获取到数据所在的可用数据服务器位置ip|port|chunkid； （3）管理服务器将数据服务器的地址发送给客户端； （4）客户端向具体的数据服务器发起数据获取请求； （5）数据服务器将数据发送给客户端； 2.MFS的写数据过程 （1）当客户端有数据写需求时

Paxos Paxos算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法。由于算法难以理解，起初并没有引起大家的重视，Lamport在1998年将论文重新发表到TOCS上，即便如此Paxos算法还是没有得到重视，2001年Lamport用可读性比较强的叙述性语言给出算法描述。 06年Google发布了三篇论文，其中在Chubby锁服务使用Paxos作为Chubby Cell中的一致性算法，Paxos的人气从此一路狂飙。 基于Paxos协议的数据同步与传统主备方式最大的区别在于：Paxos只需超过半数的副本在线且相互通信正常，就可以保证服务的持续可用，且数据不丢失。 Basic-Paxos Basic-Paxos解决的问题：在一个分布式系统中，如何就一个提案达成一致。 需要借助两阶段提交实现： Prepare阶段： Proposer选择一个提案编号n并将prepare请求发送给 Acceptor。 Acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息，则Acceptor将自己上次接受的提案回复给Proposer，并承诺不再回复小于n的提案。 Accept阶段： 当一个Proposer收到了多数Acceptor对prepare的回复后，就进入批准阶段

第一章 课程介绍和学习路线 1、微服务架构SpringCloud课程介绍 简介：课程介绍和课程大纲讲解，讲课风格和重点内容理解技巧 2、技术选型和学后水平 简介：课程所需基础和技术选型讲解，学完课程可以到达怎样的程度， 第二章 架构演进和分布式系统基础知识 1、传统架构演进到分布式架构 简介：讲解单机应用和分布式应用架构演进基础知识 (画图) 2、微服务核心基础讲解 简介：讲解微服务核心知识 ：网关、服务发现注册、配置中心、链路追踪、负载均衡器、熔断 3、常见的微服务框架 简介:讲解常用的微服务框架 4、微服务下电商项目基础模块设计 简介：微服务下电商项目基础模块设计 分离几个模块，课程围绕这个基础项目进行学习 小而精的方式学习微服务 第三章 SpringCloud核心组件注册中心 1、什么是微服务的注册中心 简介：讲解什么是注册中心，常用的注册中心有哪些 (画图) 2、分布式应用知识CAP理论知识 简介：讲解分布式核心知识CAP理论 3、分布式系统CAP原理常见面试题和注册中心选择 简介:讲解CAP原则在面试中回答和注册中心选择 4、SpringCloud微服务核心组件Eureka介绍和闭源后影响 简介： SpringCloud体系介绍 官方地址： http://projects.spring.io/spring-cloud/ Eureka的基础知识-->画图讲解交互流程

1.1.1什么是分布式系统 《分布式系统原理与范型》一书中是这样定义分布式系统的： “分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”。 这里面包含了2个含义： 硬件独立； 软件统一。 1.2.1什么是线程 线程是程序执行流的最小单位。一个标准的线程由线程ID、当前指令指针（PC）、寄存器集合和堆栈组成。 线程拥有三种基本状态： 就绪； 阻塞； 运行。 1.2.3Java编程语言中的线程对象 Java中有两种创建Thread实例的方式： 使用Runnable对象 继承Thread 1.3.2网络I/O模型的演进 同步和异步描述的是用户线程与内核的交互方式： 同步是指用户线程发起I/O请求后需要等待或者轮询内核I/O操作完成后才能继续执行； 同步是指用户线程发起I/O请求后仍继续执行，当内核I/O操作完成后会通知用户线程，或者调用用户线程注册的回调函数。 阻塞和非阻塞描述的是用户线程调用内核I/O操作的方式： 阻塞是指I/O操作需要彻底完成后才返回到用户空间； 非阻塞是指I/O操作被调用后立即返回给用户一个状态值，无须等到I/O操作彻底完成。 一个I/O操作其实被分成了两个步骤：发起I/O请求和实际的I/O操作。 阻塞I/O和非阻塞I/O的区别在于第一步，发起I/O请求是否会被阻塞。 同步I/O和异步I/O的区别在于第二步是否阻塞，如果实际的I

Spring Cloud是一系列框架的有序集合。利用Spring Boot的开发模式简化了分布式系统基础设施的开发，如 服务发现、注册、配置中心、消息总线、负载均衡、断路器、数据监控 等（这里只简单的列了一部分），都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud将目前比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终整合出一套简单易懂、易部署和易维护的分布式系统架构平台。 有spring cloud b2b2c电子商务需求的朋友可以加企鹅求求：三五三六二四七二五九 Spring Cloud组成 Spring Cloud的子项目，大致可分成两类： 一类是对现有成熟框架Spring Boot的封装和抽象，也是数量最多的项目； 第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream就是kafka, ActiveMQ这样的角色。开发人员进行 微服务 的实践，第一类子项目就已经足够使用，如： Spring Cloud Netflix 　　是对Netflix开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。 Spring Cloud Config 　　将配置信息中央化保存, 配置Spring Cloud

1、为什么要使用分布式锁 在分布式场景下为了保证数据最终一致性。在单进程的系统中，存在多个线程可以同时改变某个变量（可变共享变量）时，就需要对变量或代码块做同步(lock—synchronized)，使其在修改这种变量时能够线性执行消除并发修改变量。但分布式系统是多部署、多进程的，开发语言提供的并发处理API在此场景下就无能为力了。 2.分布式锁的使用场景 电商网站用下单操作时需要使用，秒杀活动更是如此，否则会出现超卖（库存100，秒杀活动时库存变负数了 3、分布式锁的实现方式 大概有三种：1.基于关系型数据库，2.基于缓存，3基于zookeeper 大部分网站使用的是基于缓存的，有更好的性能，而缓存一般是以集群方式部署，保证了高可用性 总体来说，支持redis单实例、redis哨兵、redis cluster、redis master-slave等各种部署架构，都可以给你完美实现。 4.基于缓存redis，使用开源 redisson 实现分布式锁 5、关于redisson 锁的几点说明， 1、通过阅读redission锁的API可以得知，其获取锁释放锁的使用和JDK里面的lock很相似，底层的实现采用了类似lock的处理方式 2、redisson 依赖redis，因此使用redisson 锁需要服务端安装redis，而且redisson 支持单机和集群两种模式下的锁的实现 3

本问主要针对zookpeer、redis实现分布式锁进行探讨， 文中有什么不严谨之处，欢迎批评指正。 redis方面：有开源redisson的jar包供你使用。 zookpeer方面：有开源的curator的jar包供你使用 需要说明的是，Google有一个名为Chubby的粗粒度分布锁的服务，然而，Google Chubby并不是开源的，我们只能通过其论文和其他相关的文档中了解具体的细节。值得庆幸的是，Yahoo！借鉴Chubby的设计思想开发了Zookeeper，并将其开源，因此本文不讨论Chubby。至于Tair，是阿里开源的一个分布式K-V存储方案。我们在工作中基本上redis使用的比较多，讨论Tair所实现的分布式锁，不具有代表性。 因此，主要分析的还是redis和zookpper所实现的分布式锁。 1、使用分布式锁的目的： 无外乎就是保证同一时间只有一个客户端可以对共享资源进行操作。通俗的讲，即：一个方法在高并发情况下的同一时间只能被同一个线程执行！ 使用分布式锁的原因： (1)提升效率 采取锁定可以避免不必要地执行相同的工作两次（例如，一些昂贵的计算）。如果锁定失败并且两个节点最终完成相同的工作，结果是成本略有增加（最终为云服务支付的费用比您原本要多5美分）或稍有不便（例如用户最终）两次收到相同的电子邮件通知）。 (2)提升正确性

GlusterFS概述 GlusterFS（Gluster File System）是一个开源的分布式文件系统，主要由Z RESEARCH公司负责开发、是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，在存储方面具有强大的横向扩展能力，通过扩展不同的节点可以支持数PB存储容量和处理数干台客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间及无元的设计，可为各种不同的数据负载提供优异的性能。 GlusterFS主要由存储服务器（Block Server）、客户端及NFS/Samba存储网关（可选，根据需要选择使用）组成，GlusteFS架构中最大的设计特点是没有元数据服务器组件，这有助于提升整个系统的性能、可靠性和稳定性。 GlusterFS主要特征如下： 扩展性和高性能 高可用性 全局统一命名空间 弹性哈希算法 弹性卷算法 基于标准协议 GlusterFS的卷类型： GlusterFS支持七种卷，分布式卷、条带卷、复制卷、分布式条带卷、分布式复制卷、条带复制卷和分布式条带复制卷，这七种卷可以满足不同应用对高性能、高可用的需求。 1.分布式卷 分布式卷是GlusterFS的默认卷，在创建卷时，默认选项是创建分布式卷

一、写在前面 现在面试，一般都会聊聊分布式系统这块的东西。通常面试官都会从服务框架（Spring Cloud、Dubbo）聊起，一路聊到分布式事务、分布式锁、ZooKeeper等知识。 所以咱们这篇文章就来聊聊分布式锁这块知识，具体的来看看 Redis分布式锁的实现原理。 说实话，如果在公司里落地生产环境用分布式锁的时候，一定是会用开源类库的，比如Redis分布式锁，一般就是用 Redisson框架就好了，非常的简便易用。 大家如果有兴趣，可以去看看Redisson的官网，看看如何在项目中引入Redisson的依赖，然后基于Redis实现分布式锁的加锁与释放锁。 下面给大家看一段简单的使用代码片段，先直观的感受一下： 怎么样，上面那段代码，是不是感觉简单的不行！ 此外，人家还支持redis单实例、redis哨兵、redis cluster、redis master-slave等各种部署架构，都可以给你完美实现。 二 、Redisson实现Redis分布式锁的底层原理 好的，接下来就通过一张手绘图，给大家说说Redisson这个开源框架对Redis分布式锁的实现原理。 （1）加锁机制 咱们来看上面那张图，现在某个客户端要加锁。如果该客户端面对的是一个redis cluster集群，他首先会根据hash节点选择一台机器。 这里注意 ，仅仅只是选择一台机器！这点很关键！ 紧接着

http://www.cnblogs.com/edisonchou/ 《大型网站技术架构》读书笔记之六：永无止境之网站的伸缩性架构 此篇已收录至 《大型网站技术架构》读书笔记系列目录 贴，点击访问该目录可获取更多内容。 首先，所谓网站的伸缩性，指 不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中，最重要的技术就是 服务器集群 ，通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 　　（1）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性； 　　（2）横向分离：将不同的业务模块分离部署，实现系统的伸缩性； 1.2 单一功通过集群规模实现伸缩 　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同，技术实现也有很大的区别。 　It is said that 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿 　　（1）应用服务器应该被设计成 无状态 的，即应用服务器不存储请求上下文信息；构建集群后