分布式架构

两大主流开源分布式存储的对比： GlusterFS vs. Ceph 存储世界最近发生了很大变化。十年前，光纤通道SAN管理器是企业存储的绝对标准，但现在的存储必须足够敏捷，才能适应在新的基础架构即服务云环境内运行。 GlusterFS和Ceph是在现代云环境中表现最出色的两个敏捷存储系统。 在讲述GlusterFS和Ceph的相同点和区别之前，我们先谈一谈云环境中敏捷存储的一些关键点。 纵向升级和横向扩展。在云环境中，很容易向服务器添加更多存储空间和扩展可用存储池。Ceph和GlusterFS都符合这一需求，让新的存储设备可以轻松融入现有存储产品环境。 高可用。GlusterFS和Ceph都会使用复制方法将数据同时写入不同存储节点。这种运作模式会增加读写次数，但同时也确保了数据的可用性。以Ceph为例，数据在默认情况会被复制到三个不同的节点，确保数据副本一直可用。 通用的硬件。GlusterFS和Ceph的开发基础都是Linux操作系统(OS)。因此，对于硬件的唯一要求就是：能够正常运行Linux即可。由于几乎任何商品硬件都能运行Linux操作系统，只要选择这些存储技术，这些技术的使用单位就可以大幅节省硬件投入。实际上，有许多公司也正在投资专用于GlusterFS或Ceph的硬件平台，因为专门优化的硬件可以更快速高效地访问存储空间。 去中心化

6-1HDFS课程概述 HDFS Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。 HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求（requirements）这样可以实现流的形式访问（streaming access）文件系统中的数据。 课程概述 一、操作HDFS 1、Web Console：端口50070 2、命令行 3、Java API 二、HDFS输出数据原理 1、数据上传的原理（过程） 2、数据下载的原理（过程） 三、HDFS的高级特性 1

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 知识脑图： 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性，ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用

#0 系列目录# 大型分布式网站架构 大型分布式网站架构技术总结 本文是学习大型分布式网站架构的技术总结。对架构一个高性能，高可用，可伸缩，可扩展的分布式网站进行了概要性描述，并给出一个架构参考。一部分为读书笔记，一部分是个人经验总结。对大型分布式网站架构有很好的参考价值。 #1 大型网站的特点# 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 #2 大型网站架构目标# 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 安全性：提供网站安全访问和数据加密，安全存储等策略。 扩展性：方便的通过新增/移除方式，增加/减少新的功能/模块。 敏捷性：随需应变，快速响应； #3 大型网站架构模式# 分层：一般可分为，应用层，服务层，数据层，管理层，分析层； 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页，用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应

这一章简单搭建一个分布式服务： 1、Dubbo简介： Dubbo 是一个分布式服务框架，是阿里巴巴开源项目。 Dubbo 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，Dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有Dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。 dubbo流程图如下： 节点角色说明： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 调用关系说明： 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 2、Zookeeper注册中心： 官方推荐使用

一般来说，构建分布式系统的目的一是增加系统容量，二是提高系统的可用性。转换成技术方面，也就是宛成以下两件事。 大流量处理。通过集群技术把大规模并发请求的负载分散到不同的机器上 关键业务保护。提高后台服务的可用性，把故障隔离起来阻止多米诺骨牌效应（雪崩效应）。如果流量过大，需要到业务降级。 说白了就是干两件事，一是提高整体架构的吞吐量，服务更多的并发和流量，二是提高系统的稳定性，让系统的可用性更高。 提高架构的性能 提高架构的稳定性 分布式系统的关键技术 引入分布式系统，会引入一堆技术问题，需要从以下几个方面解决 服务治理。服务拆分、服务调用、服务发现，服务依赖，服务的关键度定义……服务治理的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。 架构软件管理。服务之间有依赖，而且有兼容性问题，所以，整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理，以及对服务的编排、聚合、事务处理等服务调度功能。 DevOps。分布式系统可以更为快速地更新服务，但是对于服务的测试和部署都会是挑战。所以，还需要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署等。 自动化运维。有了 DevOps 后，我们就可以对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术了。 资源调度管理

概述 互联网应用发展到今天，从单体应用架构到SOA以及今天的微服务，随着微服务化的不断升级进化，服务和服务之间的稳定性变得越来越重要，分布式系统之所以复杂，主要原因是分布式系统需要考虑到网络的延时和不可靠，微服务很重要的一个特质就是需要保证服务幂等，保证幂等性很重要的前提需要分布式锁控制并发，同时缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 随着业务不断的发展，按业务域的划分子系统越来越多，每个业务系统都需要缓存、限流、分布式锁、幂等工具组件，distributed-tools组件(暂未开源)正式包含了上述分布式系统所需要的基础功能组件。 distributed-tools组件基于tair、redis分别提供了2个springboot starter，使用起来非常简单。 以使用缓存使用redis为例，application.properties添加如下配置 redis.extend.hostName=127.0.0.1 redis.extend.port=6379 redis.extend.password=pwdcode redis.extend.timeout=10000 redis.idempotent.enabled=true 接下来的篇幅，重点会介绍一下缓存、限流、分布式锁、幂等的使用方式。 缓存 缓存的使用可以说无处不在，从应用请求的访问路径来看，用户user

原文地址： http://www.sohu.com/a/228804309_99940985 我们很高兴地宣布，今天 蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！ SOFA 是蚂蚁金服 自主研发 的 金融级 分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架， 分布式数据库 代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。 蚂蚁金服期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固，并具备更多金融级的属性。所以我们也非常欢迎社区的伙伴和各行业的伙伴能够参与共同探讨、交流和共建。 Why（为什么要做） SOFA 中间件在蚂蚁内部经历了十年的发展和四代架构的演进，被广泛应用在包括支付，借贷，信用，基金，保险等全金融场景， 支撑着蚂蚁平稳度过历次双十一，双十二，新春红包等大考，创造了25.6 w/s

前言 今天老顾带着大家了解一下 session会话在微服务架构中采用的技术方案 ，以及 企业应用中需要注意的问题。 session作用 我们知道在web应用中， web服务器和浏览器之间是用http协议进行通信的 ，而 http协议是无状态 的，也就是 每个请求都是独立 的。如：用户看一条A新闻，不管是谁看到的都是一模一样的新闻。也就是 跟用户是谁没有任何关系 。 但业务自身的发展，需要把 不同的内容展示给不同的用户 ，即 信息和用户状态关联 起来。如：历史阅读列表---列出用户之前看的新闻。这个需求就是跟用户相关， 每个用户看到的历史阅读列表都是不一样的。 Session的产生 就是为了解决这个问题，把 服务器和客户端之间进行状态保持 的解决方案。 session原理 浏览器在第一次访问web服务器， 服务器端会响应一个sessionId，并且把这个sessionId传输给浏览器，并以cookie保存sessionId到浏览器本地 。 以后的访问会 把这个cookie的sessionId以请求头的方式传给服务器 ，这样服务器就可以拿着 这个sessionId进行查找，服务器中有没有此sessionId对应的用户 ，这样就能标识出哪个用户，如果有用户相关的业务，就是 利用这个sessionId返回用户相关的业务 。 本质就是 浏览器客户端本地保存了sessionId ，

原文: Session分布式共享 = Session + Redis + Nginx 一、 Session 1、 Session 介绍 我相信，搞Web开发的对Session一定再熟悉不过了，所以我就简单的介绍一下。 Session:在计算机中，尤其是在网络应用中，称为“会话控制”。 每个用户（浏览器）首次与web服务器建立连接时，就会产生一个Session，同时服务器会分配一个SessionId给用户的浏览器。我们可以用Fiddler查看cookies中，会看到有一个ASP.Net_SessionId的cookie。大家都知道Http是无状态请求，但是ASP.Net中的Session仿佛又让Http请求变得有状态，其核心就在于这个叫ASP.Net_SessionId的cookie。大家可以想象一下，这个相当于数据库的Key，服务器那边再有个Session内容缓存表，是不是Session的内容就很容易得到了？当然Session不是那么简单，但Session原理不是本文介绍重点，所以请大家自行度娘。 2、又爱又恨的 Session 刚接触程序开发的人一定爱死Session了，因为Session让Http从无状态变成有状态了，页面之间传值、用户相关信息、一些不变的数据、甚至于查出来的DataTable也可以放进去，取值的时候只需要Session[Key]即可，真是方便极了