分布式开发

01 高可用 负载均衡（负载均衡算法） 反向代理 服务隔离 服务限流 服务降级（自动优雅降级） 失效转移 超时重试（代理超时、容器超时、前端超时、中间件超时、数据库超时、NoSql超时） 回滚机制（上线回滚、数据库版本回滚、事务回滚） 02 高并发 应用缓存 HTTP 缓存 多级缓存 分布式缓存 连接池 异步并发 03 分布式事务 二阶段提交(强一致) 三阶段提交(强一致) 消息中间件(最终一致性)，推荐阿里的 RocketMQ。 04 队列 任务队列 消息队列 请求队列 05扩容 单体垂直扩容 单体水平扩容 应用拆分 数据库拆分 数据库分库分表 数据异构 分布式任务 06 网络安全 SQL 注入 XSS 攻击 CSRF 攻击 拒绝服务（DoS，Denial　of　Service）攻击 架构师必备工具 01 操作系统 Linux（必备）、某软的 02 负载均衡 DNS、F5、LVS、Nginx、OpenResty、HAproxy、负载均衡SLB 03 分布式框架 Dubbo、Motan、Spring-Could 04 数据库中间件 DRDS 、Mycat、360 Atlas、Cobar (不维护了) 05 消息队列 RabbitMQ、ZeroMQ、Redis、ActiveMQ、Kafka 06 注册中心 Zookeeper、Redis 07 缓存 Redis、Oscache

一、什么是spring cloud？ spring cloud 可以认为是一种分布式服务的框架，它为开发人员提供了快速构建分布式系统的常用模式的一些工具，比如说配置管理、服务的注册与发现、服务调用的负载均衡、资源隔离、熔断降级等等，spring cloud为这些提供了一阵套完整的解决方案。 二、什么是分布式系统？ 上面说spring cloud是一种分布式服务的框架，那么什么是分布式服务呢？ 在谈什么是分布式系统之前，可以先回顾一下以前的那种所有的功能模块都放在一个服务里的那种系统，一个系统化几十万行代码，部署在单台机器上。一个比较大的系统，可能有十几个人协作开发，但是使用的都是同一套代码，大家功能开发完成过后，使用的都是同一套代码来发布生产上线。这样做有些什么问题呢？ 代码耦合严重，维护很困难。大家使用的同一套代码，一旦一个人有需求需要修改公用代码，由于对其他人的业务逻辑不熟悉，很可能改了上线过后，会影响其他人的已经存在于线上的功能。另外数据也有可能是耦合在一起的，一个人修改了数据，然后并不知道别人对这个数据是有依赖的，最后一上线，就发现出问题了。系统不复杂还好，随着业务发展，功能增多，在原有的一个工程里面不断地增加代码，这对于后期的维护简直是一个灾难。 代码复用性问题。多个人协作开发，一个人之前写过这个功能的代码，但对另外一个人没有感知且需要依赖这个功能的代码

视图可以看作定义在SQL Server上的虚拟表.视图正如其名字的含义一样，是另一种查看数据的入口.常规视图本身并不存储实际的数据，而仅仅存储一个Select语句和所涉及表的metadata. 视图简单的理解如下: 通过视图，客户端不再需要知道底层table的表结构及其之间的关系。视图提供了一个统一访问数据的接口。 为什么要使用视图(View) 从而我们不难发现，使用视图将会得到如下好处: 视图隐藏了底层的表结构，简化了数据访问操作 因为隐藏了底层的表结构，所以大大加强了安全性，用户只能看到视图提供的数据 使用视图，方便了权限管理，让用户对视图有权限而不是对底层表有权限进一步加强了安全性 视图提供了一个用户访问的接口，当底层表改变后，改变视图的语句来进行适应，使已经建立在这个视图上客户端程序不受影响 视图(View)的分类 视图在SQL中可以分为三类 普通视图(Regular View) 索引视图(Indexed View) 分割视图(Partitioned View) 下面从这几种视图类型来谈视图 普通视图(Rugular View) 普通视图由一个Select语句所定义，视图仅仅包含其定义和被引用表的metadata.并不实际存储数据。MSDN中创建视图的模版如下: CREATE VIEW [ schema_name . ] view_name [ (column [ ,..

引言 在开发中，往往会遇到一些关于延时任务的需求。例如 生成订单30分钟未支付，则自动取消 生成订单60秒后,给用户发短信 对上述的任务，我们给一个专业的名字来形容，那就是 延时任务 。那么这里就会产生一个问题，这个 延时任务 和 定时任务 的区别究竟在哪里呢？一共有如下几点区别 定时任务有明确的触发时间，延时任务没有 定时任务有执行周期，而延时任务在某事件触发后一段时间内执行，没有执行周期 定时任务一般执行的是批处理操作是多个任务，而延时任务一般是单个任务 下面，我们以判断订单是否超时为例，进行方案分析 方案分析 (1)数据库轮询 思路 该方案通常是在小型项目中使用，即通过一个线程定时的去扫描数据库，通过订单时间来判断是否有超时的订单，然后进行update或delete等操作 实现 博主当年早期是用 quartz 来实现的(实习那会的事)，简单介绍一下 maven项目引入一个依赖如下所示 <dependency> <groupId>org.quartz-scheduler</groupId> <artifactId>quartz</artifactId> <version>2.2.2</version> </dependency> 调用Demo类MyJob如下所示 package com.rjzheng.delay1; import org.quartz.JobBuilder;

分布式事务解决方案整理 1.2PC/3PC模式 1.1 介绍： 依赖资源管理器(mysql, redis)支持XA协议， 数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务, 所有结点要么全做要么全不做。 1.2 特点: 需要依赖资源管理器RM(数据库)对XA的支持。 整个处理过程需要锁住事务资源，性能比较低。 场景一： 1）协调者节点向所有参与者节点发出”正式提交(commit)”的请求。 2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。 3）参与者节点向协调者节点发送”完成”消息。 4）协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。 场景二： 1）协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。 2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。 3）参与者节点向协调者节点发送”回滚完成”消息。 4）协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。 2. TCC模式 2.1介绍 2PC的另类实现，TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑的调度来实现分布式事务，

CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

3 月，跳不动了？>>> CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

在信息产业高速发展的今天， 企业 间的竞争将更加激烈。随着规模的不断扩大和业务的不断更新，企业迫切需求完整的分布式解决方案，用于管理复杂的异构环境，实现不同硬件设备、软件系统、网络环境及数据库系统之间的完整集成。 背景介绍 纵观人类计算机的发展历史，每隔十年至十五年，信息产业就会发生周期性的变革，1950年至1970年期间，企业主要采用大型主机－终端的体系结构，企业 应用 系统则采用单一、集中的方式为用户提供资源共享服务。80年代初期，开放系统与关系型数据库管理系统被企业大量采用，有别于集中式系统，应用程序逻辑分散在主从两端。随着Windows的普及，90年代则是图形化的应用时代，Client/Server体系结构也被广泛采用。90年代后期，信息产业出现了分布式对象技术，应用程序可以分布在不同的系统平台上，通过分布式技术实现异构平台间对象的相互通信。将企业已有系统集成于分布式系统，可以极大地提高企业应用系统的扩展性。90年代末出现的 多层 分布式应用为企业进一步简化应用系统的开发指明了方向。 在传统的Client/Server结构中，应用程序逻辑通常分布在 客户端 和 服务器 两端，客户端发出数据资源访问请求，服务器端将结果返回客户端。Client/Server结构的缺陷是，当客户端数目激增时，服务器的性能将会因为无法进行负载平衡而大大下降。而一旦应用的需求发生变化

zookeeper 分布式锁 分布式锁的概念，大家应该都已经理解，在此不会细讲。 分布式锁简单来说就是服务器集群环境下出现用户高并发访问同一个资源时，对该资源访问进行加锁等待，以保证资源的准确性。 zookeeper的分布式锁是并发的多线程通过循环的请求创建zk节点来竞争锁的占有权，待取得占有权后，其他线程进入等待。待释放占有权后，其他线程再进行循环竞争。 本编文章，主要讲解zk分布式锁，如何使用，具体逻辑还需根据实际场景进行调整。 代码是在本地建设，为了方便测试，所以里面都是静态方法。真正的开发环境都是基于webservlet或微服务工程，使用bean的方式进行类对象或者方法的调用。大家可以根据自己的工程业务做zk分布式锁的封装。 重点提醒下： 如果使用zk的watcher监听通知，节点创建后并瞬间删除，zkServer将会监听失败。因为zkServer的监听有延迟，当执行监听的时候，他发现并无该节点的stat信息，故不执行监听。 1.客户端创建 　 　zk是支持集群的，所以这里两种客户端形式，代码操作是一样的，唯有连接地址略有差异。 package com.qy.zk.lock; import org.apache.curator.RetryPolicy; import org.apache.curator.framework.CuratorFramework; import

大数据开发总体架构： Hadoop是大数据开发所使用的一个核心框架。使用Hadoop可以方便的管理分布式集群，将海量数据分布式的存储在集群中，并使用分布式并行程序来处理这些数据。 Hadoop由许多子系统组成，如下图： Hadoop1.x与2.x的对比： YARN：管理集群资源（内存、CPU） 来源： https://www.cnblogs.com/dreamboy/p/12512702.html