分布式技术

作业的必要性以及存在的问题 1. 为什么需要作业？ 作业即定时任务。一般来说，系统可使用消息传递代替部分使用作业的场景。两者确有相似之处。可互相替换的场景，如队列表。将待处理的数据放入队列表，然后使用频率极短的定时任务拉取队列表的数据并处理。这种情况使用消息中间件的推送模式可更好的处理实时性数据。而且基于数据库的消息存储吞吐量远远小于基于文件的顺序追加消息存储。 (点击放大图像) 但在某些场景下则不能互换： a) 时间驱动 OR 事件驱动：内部系统一般可以通过事件来驱动，但涉及到外部系统，则只能使用时间驱动。如：抓取外部系统价格。每小时抓取，由于是外部系统，不能像内部系统一样发送事件触发事件。 b) 批量处理 OR 逐条处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理，如：电商公司与快递公司结算，一个月结算一次，并且根据送货的数量有提成。比如，当月送货超过1000则额外给快递公司多1%的快递费。 c) 非实时性 OR 实时性：虽然消息中间件可以做到实时处理数据，但有的情况并不需要。如：VIP用户降级，如果超过1年无购买行为，则自动降级。这类需求没有强烈的时间要求，不需要按照时间精确的降级VIP用户。 d) 系统内部 OR 系统解耦：作业一般封装在系统内部，而消息中间件可用于系统间解耦。 2. 当前常见的作业系统存在哪些问题？

场景描述: 　　小型电商网站，下单，生产有一定业务含义的唯一订单编号。 思路分析: 　　如果单台服务器已无法撑起并发量，怎么办？集群？ 　　 分布式锁的用途:　 　 　　 　　在分布式环境下协同共享资源的使用。 分布式锁的特点: 　　1.排他性: 只有一个线程能获取到。 　　2.阻塞性: 其他未抢到的线程阻塞，直到锁释放出来，在抢。 　　3.可重入性:线程获得锁后，后续是否可重复获取该锁。 我们掌握的计算机技术中，有哪些能提供排他性？ 　　1. 文件系统 　　2. 数据库: 主键 唯一约束 for update 　　3. 缓存redis: setnx 　　4. zookeeper: 类似文件系统 常用的分布式锁实现技术 　　1. 基于数据库实现分布式锁 　　　　性能较差。容易出现单点故障。 　　　　锁没有失效时间，容易死锁。 　　2. 基于缓存实现分布式锁 　　　　实现复杂 　　　　存在死锁 　　3. 基于zookeeper实现分布式锁 　　　　实现相对简单 　　　　可靠性高 　　　　性能较好　　 基于zookeeper实现分布式锁 　　方式一: 　　　 1.去获取锁创建节点 　　　2.获取锁成功,执行业务并且释放锁,等待唤醒。 　　　3. 获取锁失败,注册节点的watcher,阻塞等待,直到上一个成功获取锁释放到锁，才会取消watcher，尝试抢锁。 　　特性: 　　

版权声明：本文为CSDN博主「一碗小可爱」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。 原文链接： https://blog.csdn.net/Ybulingbuling/article/details/98074918 26种常用的Java开源项目，适合所有程序员。 希望对正在学习的你一点帮助。谢谢 整理不易，建议收藏阅读。 1.分布式应用服务开发的一站式解决方案 Spring Cloud Alibaba Spring Cloud Alibaba 致力于提供分布式应用服务开发的一站式解决方案。此项目包含开发分布式应用服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。 2. JDBC 连接池、监控组件 Druid Druid是一个 JDBC 组件。 1.监控数据库访问性能。 2.提供了一个高效、功能强大、可扩展性好的数据库连接池。 3.数据库密码加密。 4.SQL执行日志。 3. Java 的 JSON 处理器 fastjson fastjson 是一个性能很好的 Java 语言实现的 JSON

一、分布式锁 　　分布式锁是在分布式场景下一种常见技术，通常通过基于redis和zookeeper来实现，本文主要介绍redis分布式锁和zookeeper分布式锁的实现方案和对比： 　　（1）基于redis的普通实现 　　这个方案的加锁主要实现是基于redis的”SET key 随机值 NX PX 过期时间（毫秒）”指令，NX代表只有key不存在时才设置成功，PX代表在过期时间后会自动释放。 　　这个方案的释放锁是通过lua脚本删除key的方式，判断value一样则删除key。 　　使用随机值的原因是如果某个获取到锁的客户端阻塞了很长时间，导致了它获取到的锁已经自动释放，此时可能有其他客户端已经获取到了锁，如果直接删除是有问题的，所以要通过随机值加上lua脚本去判断如果value相等时再删除。 　　这个方案存在一个问题就是，如果采用redis单实例可能会存在单点故障问题，但如果采用普通主从方式，如果主节点挂了key还没来得及同步到从节点，此时从节点被切换到了主节点，由于没有同步到数据别人就会拿到锁。 　　（2）redis的RedLock算法 　　这个方案是redis官方推荐的分布式锁的解决方案，假设有5个redis master实例，然后执行如下步骤去获取一把锁： 　　1）获取当前时间戳，单位是毫秒 　　2）跟上面类似，轮流尝试在每个master节点上创建锁，过期时间较短

一： 　　rpc:远程过程调用协议 是jdk底层协议 　　dubbo只是对这个协议实现的一个框技术 　　rpc就是夸服务器 夸toamct 从一个项目调用另外一个项目中的方法 二： 　 　 Dubbox是一个分布式服务框架， 其前身是阿里巴巴开源项目Dubbo，被国内电商及互联网项目中使用，后期阿里巴巴停止了该项目的维护，当当网便在Dubbo基础上进行优化，并继续维护，为了与原有的Dubbo区分，故将其命名为Dubbox。 Dubbox致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbox就是个服务框架，如果没有分布式需求，其实是不需要用的，只有在分布式的时候，才有dubbox这样的分布式服务框架的需求，并且本质上的作用就是服务调用，说白了就是个远程服务调用的分布式框架。 三： 　　 节点角色说明： · Provider: 暴露服务的服务提供方。 · Consumer: 调用远程服务的服务消费方。 · Registry: 服务注册与发现的注册中心。 · Monitor: 统计服务的调用次调和调用时间的监控中心。 · Container: 服务运行容器。 调用关系说明： · 0. 服务容器负责启动，加载，运行服务提供者。 · 1. 服务提供者在启动时，向注册中心注册自己提供的服务。 · 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

主要应用在集群系统中，具有很好的可扩展性。软件的结构设计良好，易于扩展和配置，通过各个模块的灵活搭配以得到针对性的解决方案。可解决以下问题：网络存储，联合存储(融合多个节点上的存储空间)，冗余备份，大文件的负载均衡(分块)。由于缺乏一些关键特性，可靠性也未经过长时间考验，还不适合应用于需要提供 24 小时不间断服务的产品环境。目前适合应用于大数据量的离线应用。 　　由于它良好的软件设计，以及由专门的公司负责开发，进展非常迅速，几个月或者一年后将会有很大的改进，非常值得期待。GlusterFS通过Infiniband RDMA 或者Tcp/Ip 方式将许多廉价的x86 主机，通过网络互联成一个并行的网络文件系统 Gluster File System 是自由软件，主要由 Z RESEARCH 公司负责开发，十几名开发者，最近非常活跃。文档也比较齐全，不难上手。主要应用在集群系统中，具有很好的可扩展性。软件的结构设计良好，易于扩展和配置，通过各个模块的灵活搭配以得到针对性的解决方案。可解决以下问题：网络存储，联合存储(融合多个节点上的存储空间)，冗余备份，大文件的负载均衡(分块)。由于缺乏一些关键特性，可靠性也未经过长时间考验，还不适合应用于需要提供 24 小时不间断服务的产品环境。目前适合应用于大数据量的离线应用。 由于它良好的软件设计，以及由专门的公司负责开发，进展非常迅速

Easy Scheduler Release 1.0.2 Easy Scheduler 1.0.2是1.x系列中的第三个版本。此版本增加了调度开放接口、worker分组(指定任务运行的机器组)、任务流程及服务监控以及对oracle、clickhouse等支持，具体如下： 新特性： [ EasyScheduler-79 ] 调度通过token方式对外开放接口，可以通过api进行操作 [ EasyScheduler-138 ] 可以指定任务运行的机器(组) [ EasyScheduler-139 ] 任务流程监控及Master、Worker、Zookeeper运行状态监控 [ EasyScheduler-140 ] 工作流定义—增加流程超时报警 [ EasyScheduler-134 ] 任务类型支持Oracle、CLICKHOUSE、SQLSERVER、IMPALA [ EasyScheduler-136 ] Sql任务节点可以独立选取抄送邮件用户 [ EasyScheduler-141 ] 用户管理—用户可以绑定队列,用户队列级别高于租户队列级别，如果用户队列为空，则寻找租户队列 增强： [ EasyScheduler-154 ] 租户编码允许纯数字或者下划线这种的编码 修复： [ EasyScheduler-135 ] Python任务可以指定python版本 [

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在这几年越来越火的微服务架构中，几乎可以说是无法避免。 本篇文章将通过详解分布式事务的一致性，以及分布式事务实战解决方案，帮助大家搞懂分布式事务，推荐收藏。 01 为什么需要分布式事务 由于近十年互联网的发展非常迅速，很多网站的访问越来越大，集中式环境已经不能满足业务的需要了，只能按照业务为单位进行数据拆分(包含：垂直拆分与水平拆分)，以及按照业务为单位提供服务，从早期的集中式转变为面向服务架构的分布式应用环境。 举一个典型的例子，阿里的淘宝网站随着访问量越来越大，只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分，以及按照业务为单位提供服务接口。 这个时候 为了完成一个简单的业务功能，比如：购买商品后扣款，有可能需要横跨多个服务，涉及用户订单、商品库存、支付等多个数据库，而这些操作又需要在同一个事务中完，这就涉及到到了分布式事务。 本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。 02 分布式的一致性理论 最早加州大学伯克利分校 Eric Brewer教授提出一个分布式系统特性的CAP理论。 1.CAP 理论的不可能三角 一致性（Consistency） 可用性（Availability） 分区容错性（Partition tolerance） 在分布式系统中

分布式工作流任务调度系统Easy Scheduler正式开源 1、背景 在多位技术小伙伴的努力下，经过近2年的研发迭代、内部业务剥离及重构，也经历一批种子用户试用一段时间后， EasyScheduler 终于迎来了第一个正式开源发布版本 -- 1.0.0 。 相信做过数据处理的伙伴们对开源的调度系统如oozie、azkaban、airflow应该都不陌生，在使用这些调度系统中可能会有这样的体验：比如配置工作流任务不能可视化、任务的运行状态不能实时在线查看、 任务运行时不能暂停、不能支持参数传递、不能补数、不能多租户使用、调度系统不高可用等等问题所烦扰过。 Easy Scheduler 正是在这种背景下应运而生，其目标就是为使调度更加easy，更可以从其中文名“易调度”看出我们的初衷。 2、设计特点 Easy Scheduler 是一个分布式工作流任务调度系统，主要解决数据研发ETL错综复杂的依赖关系所带来的各种问题。 其主要目标如下： 以DAG图的方式将Task按照任务的依赖关系关联起来，可实时可视化监控任务的运行状态 支持丰富的任务类型：Shell、MR、Spark、SQL(mysql、postgresql、hive、sparksql),Python,Sub_Process、Procedure等 支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复，同时支持失败重试/告警