分布式架构

什么是分布式架构 分布式系统（distributed system）是建立在网络之上的软件系统。 分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。 内聚性是指每一个数据库分布节点高度自治，有本地的数据库管理系统。 透明性是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。 在分布式数据库系统中，用户感觉不到数据是分布的，即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。 简单来讲：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。 1-3-01-jpg 分布式系统作为一个整体对用户提供服务，而整个系统的内部的协作用户来说是透明的，用户就像是在使用一个MySQL一样。 如分布式MySQL中间件-Mycat，来处理大并发大数据量的构架。 分布式架构的应用 有 分布式文件系统，分布式缓存系统，分布式数据库，分布式WebService，分布式计算 我们来举例说明： 分布式文件系统： 出名的有 Hadoop 的HDFS ,还有 google的 GFS , 淘宝的 TFS 等 分布式缓存系统：memcache , hbase ,

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

【编者按】DTCC 2019已经结束，云栖社区沉淀了很多阿里巴巴所分享的优质演讲 整理稿件 。这篇转载自IT168&ITPUB执行总编老鱼的公众号，分享给大家。 李飞飞，现任阿里巴巴集团副总裁、高级研究员，阿里云智能数据库事业部总负责人。加入阿里巴巴之前为美国犹他大学计算机系终身教授。研究成果多次获得了IEEE ICDE、ACM SIGMOD最佳论文奖等重要学术奖项。 2018年，李飞飞加入阿里巴巴达摩院，带领团队投入到具有自主知识产权的研究当中。目前，带领的阿里云智能数据库事业部所研发的新一代分布式数据库系统，支撑了阿里巴巴集团的复杂业务、海量数据和双11交易洪峰的挑战，已经被应用于多个城市的智能城市交通网络管理，并服务了金融、零售、物流、制造等行业企业。 2018年，阿里云数据库成功进入Gartner数据库魔力象限，这是该榜单首次出现中国公司，近日，阿里云数据库再次入选Forrester数据库评估报告，成为国内首个获得两大顶级机构认可的科技公司。 2019年5月10日，DTCC 2019(第十届中国数据库技术大会)在北京举办，李飞飞来到现场发表了精彩的主题演讲，并在大会期间接受了IT168&ITPUB执行总编老鱼的深度专访，众多独特观点精彩纷呈。 透露两条信息： 1、PolarDB从去年10月开始商业化到目前，已经成为阿里云上增长最快的数据库产品； 2

读累了就看看实操 https://www.cnblogs.com/huasky/p/10214642.html 一、SOA 概念：SOA：Service-Oriented Architecture，面向服务的架构，将应用程序的不同功能(服务)通过定义的接口来实现数据通信；服务治理；服务调度中心和治理中心； 架构演变：单一应用架构ORM | 垂直应用架构MVC | 分布式服务架构RPC | 流动计算架构SOA ORM ：流量小，单一应用，部署一起；关注于简化增删改查的对象关系映射， MVC ：流量增加，应用拆分；关注于提高前端开发速度； RPC ：远程过程调用；通过网络进行远程计算机服务的请求；核心业务抽取；关注于业务的复用和整合； 由统一到分布式： 使用场景由混乱到统一： SOA又叫服务治理，SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准； 统一标准：各系统的协议、地址、交互方式。 新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，我们并不关心如果找到其他子系统，我们只招数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个只路人的作用。 数据总线是起到调度服务的作用，数据总线不是集成服务，数据总线更新一个调度框架，每个服务需要根据约定向数据总线注册服务；服务不是经过总线的

一.构建工程 　　1.引入依赖 　　<!--SpringBoot2.0以上版本需引入该依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-discovery</artifactId> </dependency> 2.创建主类 @SpringBootApplication @EnableDiscoveryClient @EnableZuulProxy @RestController public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } 3.配置application.properties zuul.routes.api-a.path=/api-a/** zuul.routes.api-a

设计理念 1 时间换空间 1.1 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）， 反向代理缓存，应用端的缓存(memcache)，内存数据库，Buffer、cache机制（数据库，中间件等）。 1.2 索引 哈希、B树、倒排、bitmap 哈希索引:适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引:适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引:实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap:是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 2.1 任务切分、分而治之(MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。 2.2 多进程

很多人问阿里的飞天大数据平台、云梯2、MaxCompute、实时计算到底是什么，和自建Hadoop平台有什么区别。 先说Hadoop 什么是Hadoop？ Hadoop是一个开源、高可靠、可扩展的分布式大数据计算框架系统，主要用来解决海量数据的存储、分析、分布式资源调度等。Hadoop最大的优点就是能够提供并行计算，充分利用集群的威力进行高速运算和存储。 Hadoop的核心有两大板块：HDFS和MapReduce。 HDFS全称Hadoop Distributed File System，是一种分布式文件存储系统。分布式文件系统是指将固定于某个地点的某个文件系统，扩展到任意多个文件系统，众多的节点组成一个文件系统网络。每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输。人们在使用分布式文件系统时，无需关心数据是存储在哪个节点上、或者是从哪个节点获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据。HDFS有着高容错性，可以部署在低廉的硬件；提供高吞吐量来访问应用程序的数据；可以有效解决超大数据量存储和管理难题的分布式文件系统属性的特点。因此HDFS天然适合有着超大数据集的应用程序，或者说本身就是为超大规模数据量处理的应用程序而设计的。 MapReduce是一个分布式离线并行计算框架，能够对大数据集进行并行处理

原文: 分布式事务,EventBus 解决方案:CAP【中文文档】 最新文档地址： https://github.com/dotnetcore/CAP/wiki 前言 很多同学想对CAP的机制以及用法等想有一个详细的了解，所以花了将近两周时间写了这份中文的CAP文档，对 CAP 还不知道的同学可以先看一下 这篇文章 。 本文档为 CAP 文献（Wiki），本文献同时提供中文和英文版本，英文版本目前还在翻译中，会放到Github Wiki 中。 目录 前言 1、Getting Started 1.1 介绍 1.2 应用场景 1.3 Quick Start 2、API接口 2.1 发布/发送 2.1.1 事务 2.2 订阅/消费 2.2.1 例外情况 3、配置 3.1 Cap Options 3.2 RabbitMQ Options 3.3 Kafka Options 3.4 SqlServer Options 3.5 MySql Options 4、设计原理 4.1 动机 4.2 持久化 4.3 通讯数据流 4.4 一致性 5、实现 5.1 消息表 5.2 消息格式 5.3 EventBus 5.4 重试 6、分布式事务 6.1 异步确保 7、FAQ 1、Getting Started 1.1 介绍 CAP 是一个遵循 .NET Standard 标准库的C#库

问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如

技术站点 Hacker News：非常棒的针对编程的链接聚合网站 Programming reddit：同上 MSDN：微软相关的官方技术集中地，主要是文档类 infoq：企业级应用，关注软件开发领域 OSChina：开源技术社区，开源方面做的不错哦 cnblogs，51cto，csdn：常见的技术社区，各有专长 stackoverflow：IT技术问答网站 GitHub：全球最大的源代码管理平台，很多知名开源项目都在上面，如Linux内核， OpenStack等免费的it电子书：http://it-ebooks.info/ DevStore:开发者服务商店 不错的书籍 人件 人月神话 代码大全2 计算机程序设计艺术 程序员的自我修养 程序员修炼之道 高效能程序员的修炼（成为一名杰出的程序员其实跟写代码没有太大关系） 深入理解计算机系统 软件随想录 算法导论（麻省理工学院出版社） 离线数学及其应用 设计模式 编程之美 黑客与画家 编程珠玑 C++ Prime Effective C++ TCP/IP详解 Unix 编程艺术 《精神分析引论》弗洛伊德 搞定：无压力工作的艺术 平台工具（都是开源的好东东哦） Redmine/Trac：项目管理平台 Jenkins/Jira(非开源)：持续集成系统（Apache Continuum，这个是Apache下的CI系统，还没来得及研究）