分布式开发

Scrapy-Redis代码实战 Scrapy 是一个通用的爬虫框架，但是不支持分布式，Scrapy-redis是为了更方便地实现Scrapy分布式爬取，而提供了一些以redis为基础的组件(仅有组件)。 scrapy-redis在scrapy的架构上增加了redis，基于redis的特性拓展了如下四种组件： Scheduler Duplication Filter Item Pipeline Base Spider scrapy-redis架构 Scheduler Scrapy原本的queue是不支持多个spider共享一个队列的，scrapy-redis通过将queue改为redis实现队列共享。 Duplication Filter Scrapy中通过Python中的集合实现request指纹去重，在scrapy-redis中去重是由Duplication Filter组件来实现的，它通过redis的set不重复的特性，巧妙的实现了DuplicationFilter去重。 Item Pipeline 引擎将(Spider返回的)爬取到的Item给Item Pipeline，scrapy-redis 的Item Pipeline将爬取到的 Item 存入redis的 items queue。修改过Item Pipeline可以很方便的根据 key 从 items

一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 2. 微服务架构与SOA架构的区别 微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。 3. 微服务架构引发的问题 随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。

据 IDC 最新报告预测，2022 年中国 50% 以上的组织都将成为数字化坚定者，依靠新的商业模式、数字化产品与服务实现业务增长。 面对数字化转型的时代浪潮，青小云为大家准备了一份硬核大礼 —— 《数字化转型之路》 ，包含 基础设施 、 业务架构 、 解决方案 到 行业实践 、 未来探索 五个部分，该系列 是对数字化转型理论与具体实践路径的系统梳理 ，希望帮助读者全面准确把握数字化转型发展趋势与前沿技术，促进企业与组织能够在变革的数字化世界中创造更大的价值，实现更强健的生命力。 今天与大家分享的是《数字化转型之路》中基础设施篇——QingStor®️ 云时代企业级分布式存储平台。 以下是 分享正文 首先为大家简单介绍青云在存储上的思考和产品线的布局，让大家对青云的存储、特别是软件定义存储有一个全面的了解。 市场发展趋势 这是 IDC 2018 年的报告，可以看出 2018 年软件定义存储领域的增长比较快，同比增长率超过 50%，往前追溯一年，2017 年同比 2016 年是超过百分百的增长率。 在 SDS 市场中，按存储接口领域区分，主要分为分布式块存储、分布式文件存储和分布式对象存储。在这三种接口里占比最大的是分布式文件存储，2018 年大概有六成市场属于分布式文件存储，块存储大概是两成左右，对象存储也是两成左右。 这是三种存储分别在 2018 年的增长态势

前言 文件系统是最常用的数据存储形式，所以，常用Linux操作系统的用户必然知道ext4、xfs等单机文件系统，用Windows操作系统的用户也都知道NTFS单机文件系统。各种业务场景下，不同的数据都存储于文件系统之上，大量业务逻辑就是基于文件系统而设计和开发的。提供最常用的存储访问方式，这是我们做文件系统的出发点之一。 另一方面，单机文件系统有其明显限制，主要是容量、文件数量限制，以及可靠、可用性限制。单机文件系统毕竟存储空间有限，且掉电或坏盘等故障会带来数据不可达或丢失。通过分布式文件系统解决这些问题，这是我们的出发点之二。 但做分布式文件系统会面临很多挑战，也会面临非常多的选择。 Google GFS论文面世之后，Hadoop HDFS随之诞生，HDFS的选择是处理大文件，面向MapReduce这种非在线数据分析业务，重吞吐而非延时，对HDFS内部存储的数据进行访问，需要借助其提供的专有命令行和SDK，意味着它并不是一个通用型的文件系统。它的主要架构是元数据服务（本文统一用MetaData Service的缩写MDS来指代元数据服务）和数据服务（本文统一用Data Storage Service的缩写DSS来指代数据服务），其中MDS是单点的，单点的MDS能做出一致的决策，为了保证MDS可靠性，一般会选择再做一个备份。HDFS的DSS则可以是很多个。因为文件大小和形式固定

背景： 初代的服务器架构往往比较简单，应用程序、数据库、文件、代码等所有资源都放在一台服务器上，也就是单机结构。随着企业业务量的增多，一台服务器已经难以满足数据处理的需求了，那么对单机进行“复制粘贴”，就能收获一个处理能力高出好几倍的“服务器集群”。 不过，集群式扩展很容易到达物理上限，最直接的反映就是无论怎么增加节点，整个集群的性能似乎也没有被提升多少，这时候，就需要分布式系统登场了。 如果说分布式系统代表着网络服务的发展方向，那么云计算的社会化，可能是其快速普及的重要推手。 集中式架构、分布式架构、微服务架构图解 什么是分布式？ 所谓分布式，就是将不同的服务模块部署在多台不同的服务器上，然后通过远程调用协同工作，共同对外提供服务。对于用户来说，就像是一台计算机在服务一样。 在实际业务中，分布式系统可以将不同的业务功能对应到一个个独立的子系统中去，比如针对电商平台，可以将用户服务、产品服务、店铺管理、数据分析等不同的数据处理项目部署在不同的计算机集群上。这些独立的集群可能是在不同的机房，甚至是不同的城市中，有的大型数据中心还会分布在不同的国家和地区。它们之间通过RPC消息传递进行通信和协调，再向用户提供服务。 在分布式系统的背景下，企业架构也由早期的单体式应用架构渐渐转为更加灵活的分布式应用架构，经历了单体分层架构、SOA 服务化架构、微服务架构、云原生架构等不同架构模式的变迁

什么是分布式锁 在学习Java多线程编程的时候，锁是一个很重要也很基础的概念，锁可以看成是多线程情况下访问共享资源的一种线程同步机制。这是对于单进程应用而言的，即所有线程都在同一个JVM进程里的时候，使用Java语言提供的锁机制可以起到对共享资源进行同步的作用。如果分布式环境下多个不同线程需要对共享资源进行同步，那么用Java的锁机制就无法实现了，这个时候就必须借助分布式锁来解决分布式环境下共享资源的同步问题。分布式锁有很多种解决方案，今天我们要讲的是怎么使用缓存数据库Redis来实现分布式锁。 Redis分布式锁方案一 使用Redis实现分布式锁最简单的方案是在获取锁之前先查询一下以该锁为key对应的value存不存在，如果存在，则说明该锁被其他客户端获取了，否则的话就尝试获取锁，获取锁的方法很简单，只要以该锁为key，设置一个随机的值就行了。比如，我们有一批任务需要由多个分布式线程处理，每个任务都有一个taskId，为了保证每个任务只被执行一次，在工作线程执行任务之前，先获取该任务的锁，锁的key可以为taskId。因此，获取锁的过程可以用如下伪代码实现： 上述就是最简单的获取锁的方案了，但是大家可以想想这个方案有什么问题呢？有没有什么潜在的坑？在分析这种方案的优缺点之前，先说一下获取锁后我们一般是怎么使用锁，并且又是如何释放锁的，以Java语言为例

在一个基于SOA架构的分布式系统体系中，服务（Service）成为了基本的功能提供单元，无论与业务流程无关的基础功能，还是具体的业务逻辑，均实现在相应的服务之中。服务对外提供统一的接口，服务之间采用标准的通信方式进行交互，各个单一的服务精又有效的组合、编排成为一个有机的整体。在这样一个分布式系统中某个活动（Activity）的实现往往需要跨越单个服务的边界，如何协调多个服务之间的关系使之为活动功能的实现服务，涉及到SOA一个重要的课题：服务协作（Service Coordination）。而具体来讲，一个分布式的活动可能会执行几秒钟，比如银行转帐；也可能执行几分钟、几个小时、几天甚至更长，比如移民局处理移民的申请。事务，无疑是属于短暂运行服务协作（Short-Running Service Coordination）的范畴。 一、 什么是事务（Transaction） 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。事务具有如下四个属性，根据其首字母，我们一般将其称为事务的ACID四大属性： 原子性（Atomicity）： “原子”这个词的本义就是不可分割的意思

文章目录 springBoot 分布式zookeeper+Dubbo 一、基础知识 单一应用架构 垂直应用架构 分布式架构 流动计算架构 什么是RPC？ 二、Dubbo 什么是Dubbo 为什么使用Dubbo 调用关系说明 Dubbo环境搭建 window下安装dubbo-admin SpringBoot + Dubbo + zookeeper 服务提供者(provider) 服务消费者（consumer） springBoot 分布式zookeeper+Dubbo 一、基础知识 什么是分布式系统 1 、分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统 2 、分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。 3 、分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。 为什么提倡分布式架构 随着互联网规模和需求越来越大，传统的单体应用已经不能支撑 单一应用架构 将网站所有东西打包在一个应用中，将其部署，减少部署成本，此时ORM成为重点 优点：适合小网站，访问量不大的情况下 缺点： 性能扩展比较难 协同开发问题 不利于升级维护 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时

微服务架构 BAT互联网架构这些年的演进分析 国内外常见分布式系统架构状况介绍 微服务架构指南:领域驱动设计DDD模型 SpringCloud1-2实战篇 Config分布式配置中心 Eureka注册与发现机制 Ribbon客户端负载均衡 Hystrix服务熔断组件 Feign声明式服务调用 Zuul网关服务 项目实战：SpringCloud微服务架构 4.1 高并发分布式技术专题 - 分布式开发技术 4.1.1 RPC 4.1.2 分布式系统指挥官Zookeeper 4.1.3 Dubbo框架 4.2 高并发分布式技术专题 - 高并发开发技术 4.2.1 Java多线程并发编程 4.2.2 NIO与实战 4.2.3 高并发-缓存 4.2.4 高并发-消息队列 4.2.5 高并发- 分流 4.3 高并发分布式技术专题 - 实战技巧篇 4.3.1 分布式锁实现方案 基于redis实现 基于zookeeper实现 分布式锁应用场景 4.3.2 分布式事务解决方案 基于X/A协议相关的解决方案 消息队列解决方案 TCC解决方案 本地消息表解决方案 4.3.3 分布式系统校验解决方案 分布式session JWT方式 单点登录框架 4.3.4 互联网高可用架构分析 负载均衡技术分析 通过keepalived实现常用中间件的高可用 4.3.5 分布式订单流水号生成策略分析 基于数据库

本文转载自： 什么是分布式微服务架构？三分钟彻底弄懂什么是分布式和微服务 一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 2. 微服务架构与SOA架构的区别 微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。 3. 微服务架构引发的问题