分布式架构

什么是FastDFS？ FastDFS是一个开源的轻量级分布式文件系统。它解决了大数据量存储和负载均衡等问题。特别适合以中小文件（建议范围：4KB < file_size < 500MB）为载体的在线服务，如相册网站、视频网站等等。 FastDFS架构 FastDFS的工作流程 上传文件 上传的流程： client询问tracker上传到的storage tracker返回一台可用的storage client直接和storage通信，完成文件上传 选择tracker server 集群中tracker之间是对等关系，client在上传文件时可以使用任意一个tracker 选择存储group 当tracker接收到上传文件的请求的时候，会为该文件分配一个可以存储的group。目前支持选择的group的规则有： Round robin，轮询 Sepcified group，上传的时候指定某个group Load balance，生成存储空间较多的group优先 选择storage server 当选定group后，tracker会在group内选择一个storage server给client，目前支持选择server的规则有： Round robin，轮询（默认） 根据IP地址进行排序，选择第一个服务器（IP地址最小者） 根据优先级进行排序，上传优先级由storage

引言 这篇说说分布式事务的问题。企业现在的架构都由传统的架构转向了微服务架构，如下图所示: 那么，都不可避免的会遇到跨数据库调用的，分布式事务问题！ 目前，业内解决分布式事务问题，都基本不用JTA这种强一致性的解决方案，基本是采用如下两套方案 基于TCC的事务框架 消息队列 OK，你们先记住两点 (1)图中的服务A和服务B，如果是同步调用，要求一起成功，或者一起失败，那么此时应选用TCC的事务框架，这点我改天另写一篇，先挖坑！ (2)图中的服务A和服务B，如果是异步调用，比如服务C先调用服务A后，服务C不用管服务B的执行结果，直接返回，那么这种情况下，应选用消息队列！这篇文章重点讲！ 目前为止，大部分文章都讲的太复杂了。导致很多新人看完后于是看这篇文章前，你们先忘记你们在其他文章看到的概念，跟着博主的思路走！ 正文 先给大家套一个业务场景，也是很常见的一个异步调用场景: 支付宝往余额宝转钱 即将服务A假设为支付宝，服务B假设为余额宝。 于是呢，我们的支付宝往余额宝转100块钱是怎么做的呢？ 特别容易，借助消息队列即可，如下图所示 一致性解决 OK，上面这一版有一个致命的问题！如下所示 事务开始 (1)给支付宝账户zhangsan,扣100元 (2)将(给余额宝账户zhangsan,加100元)封装为消息，发送给消息队列 事务结束 敢问你，如何保证第一步和第二步是在同一个事务里完成的

随着微服务架构的流行，一些微服务架构下的问题也会越来越突出，比如一个请求会涉及多个服务，而服务本身可能也会依赖其他服务，整个请求路径就构成了一个网状的调用链，而在整个调用链中一旦某个节点发生异常，整个调用链的稳定性就会受到影响，所以会深深的感受到 “银弹” 这个词是不存在的，每种架构都有其优缺点 。 service map 面对以上情况， 我们就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题，这时候 APM（应用性能管理）工具就该闪亮登场了。 目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking，这里主要介绍 SkyWalking ，它是一款优秀的国产 APM 工具，包括了分布式追踪、性能指标分析、应用和服务依赖分析等。 下面是 SkyWalking 6.x 的架构图： 6.x architecture 说明： SkyWalking 的核心是数据分析和度量结果的存储平台，通过 HTTP 或 gRPC 方式向 SkyWalking Collecter 提交分析和度量数据，SkyWalking Collecter 对数据进行分析和聚合，存储到 Elasticsearch、H2、MySQL、TiDB 等其一即可，最后我们可以通过 SkyWalking UI 的可视化界面对最终的结果进行查看

更多资源和教程请关注公众号： 非科班的科班 。 如果觉得我写的还可以请给个赞，谢谢大家，你的鼓励是我创作的动力 课程目录介绍 01、开班仪式 02、并发编程专题之多线程基础 03、并发编程专题之Java内存模型 04、并发编程专题-多线程之间通讯 05、并发编程专题-线程池原理分析 06、并发编程专题-Callable与Future模式 07、并发编程专题-锁的深入化 08、并发编程专题-Disruptor框架 09、设计模式专题-反射机制与单例五种创建方式 10、设计模式专题-简单工厂&工厂方法&抽象工厂&静态代理&动态代理 11、设计模式专题-建造者&模版方法&适配器&外观模式 12、设计模式专题-策略模式&原型模式 13、性能优化专题-JVM-Java内存结构与垃圾回收机制算法分析 14、性能优化专题-JVM-垃圾收集器&性能监控工具&实战参数调优案例分析 15、性能优化专题-JVM-动态字节码技术 16、性能优化专题-JVM-类加载器 17、源码分析-手写Spring事务框架 18、源码分析-手写Spring注解版本&事务传播行为 19、源码分析-手写SpringIOC容器框架之手写@Service和@Resource注解 20、源码分析-手写SpringMVC框架之手写@RequestMapping和@Controller注解 21、源码分析-纯手写数据库连接池 22

转自： https://www.cnblogs.com/rjzheng/p/8994962.html 引言 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 小A，工作于传统软件行业(某社保局的软件外包公司)，每天工作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写几个SQL，生成下报表。又或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种生活，技术零成长。 小B，工作于某国企，虽然能接触到一些中间件技术。然而，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使用这些中间件啊？如何保证高可用啊？没有充分的认识。 庆幸的是两位朋友都很有上进心，于是博主写这篇文章，帮助他们复习一下关于消息队列中间件这块的要点 复习要点 本文大概围绕如下几点进行阐述: 为什么使用消息队列？ 使用消息队列有什么缺点? 消息队列如何选型? 如何保证消息队列是高可用的？ 如何保证消息不被重复消费? 如何保证消费的可靠性传输? 如何保证消息的顺序性？ 我们围绕以上七点进行阐述。需要说明一下，本文不是《消息队列从入门到精通》这种课程，因此只是提供一个复习思路，而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人，去找点消息队列的博客看看，再看本文，收获更大 正文 1、为什么要使用消息队列? 分析 :一个用消息队列的人，不知道为啥用，这就有点尴尬

转自： https://www.cnblogs.com/rjzheng/p/9041659.html 引言 为什么写这篇文章？ 首先，缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作。 但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议。目前没有一篇全面的博客，对这几种方案进行解析。于是博主战战兢兢，顶着被大家喷的风险，写了这篇文章。 文章结构 本文由以下三个部分组成 1、讲解缓存更新策略 2、对每种策略进行缺点分析 3、针对缺点给出改进方案 正文 先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。因此，接下来讨论的思路不依赖于给缓存设置过期时间这个方案。 在这里，我们讨论 三种 更新策略： 先更新数据库，再更新缓存 先删除缓存，再更新数据库 先更新数据库，再删除缓存 应该没人问我，为什么没有先更新缓存，再更新数据库这种策略。 (1)先更新数据库，再更新缓存 这套方案，大家是普遍反对的。为什么呢

一 什么是事务？有什么用？ 事务的特性ACID 事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。 1）原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作 要么都发生，要么都不发生。 2）一致性（Consistency）一个事务中，事务前后数据的完整性必须保持一致。 3）隔离性（Isolation）多个事务，事务的隔离性是指多个用户并发访问数据库时， 一个用户的 事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。 4）持久性（Durability）持久性是指一个事务一旦被提交，它对数据库中数据的改变 就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。 二 事务的并发会产生的问题有哪些 1.脏读 一个事务正在对数据进行更新操作，但是更新还未提交，另一个事务这时也来操作这组数据，并且读取了前一个事务还未提交的数据，而前一个事务如果操作失败进行了回滚，后一个事务读取的就是错误的数据，这样就造成了脏读 2.不可重复读 一个事务多次读取同一个数据，在该事务还未结束时，另一个事务也对该数据进行 了操作，而且在第一个事务两次读取之间，第二个事务对数据进行了更新，那么第一个

Hadoop家族学习路线图 Hadoop家族系列文章 ，主要介绍Hadoop家族产品，常用的项目包括Hadoop, Hive, Pig, HBase, Sqoop, Mahout, Zookeeper, Avro, Ambari, Chukwa，新增加的项目包括，YARN, Hcatalog, Oozie, Cassandra, Hama, Whirr, Flume, Bigtop, Crunch, Hue等。 从2011年开始，中国进入大数据风起云涌的时代，以Hadoop为代表的家族软件，占据了大数据处理的广阔地盘。开源界及厂商，所有数据软件，无一不向Hadoop靠拢。Hadoop也从小众的高富帅领域，变成了大数据开发的标准。在Hadoop原有技术基础之上，出现了Hadoop家族产品，通过“大数据”概念不断创新，推出科技进步。 作为IT界的开发人员，我们也要跟上节奏，抓住机遇，跟着Hadoop一起雄起！ 关于作者： 张丹(Conan), 程序员Java,R,PHP,Javascript weibo：@Conan_Z blog: http://blog.fens.me email: bsspirit@gmail.com 转载请注明出处： http://blog.fens.me/hadoop-family-roadmap/ 前言 使用Hadoop已经有一段时间了，从开始的迷茫

Hinton胶囊网络后最新研究：用“在线蒸馏”训练大规模分布式神经网络 朱晓霞 发表于 目标检测和深度学习 订阅 457 广告 关闭 11.11 智慧上云 云服务器企业新用户优先购，享双11同等价格 立即抢购 新智元报道 来源：arXiv 编译：肖琴、克雷格 【新智元导读】 深度学习领域的大牛、多伦多大学计算机科学教授Geoffrey Hinton近年在distillation这一想法做了一些前沿工作。今天我们介绍的是Hinton作为作者之一，谷歌大脑、DeepMind等的研究人员提交的distillation的更进一步工作：通过online distillation进行大规模分布式神经网络训练。该工作提出了Codistillation的概念，通过大规模实验，发现codistillation方法提高了准确性并加快了训练速度，并且易于在实践中使用。 论文地址：https://arxiv.org/pdf/1804.03235.pdf 在提出备受瞩目的“胶囊网络”（Capsule networks）之后，深度学习领域的大牛、多伦多大学计算机科学教授Geoffrey Hinton近年在 distillation 这一想法做了一些前沿工作，包括Distill the Knowledge in a Neural Network等。今天我们介绍的是Hinton作为作者之一，谷歌大脑

基于SOA的分布式高可用架构和微服务架构，是时下如日中天的互联网企业级系统开发架构选择方案。在核心思想上，两者都主张对系统的横向细分和扩展，按不同的业务功能模块来对系统进行分割并且使用一定的手段实现服务之间的通信，并且基于弹性云服务搭建高可用的分布式解决方案。 但它们之间的区别可能比相似的地方要多，特别是体现在对服务的使用和与云服务的深度结合上。在具体实践中，微服务的架构也可以与其它互联网中间件组合在一起，组成规模更为庞大的SOA分布式系统。本文主要对一个典型的SOA分布式应用的架构和组件做详细的说明。 企业级系统架构的演变 单体式 单体架构即所有系统功能和模块基于MVC的设计模式耦合在一个单体服务器单元中。基于传统的MVC思想，单体应用基于前后端分离的原则，通过Model、Control和View共同来完成一个特点的服务请求。这种传统的架构模式带了了多人团队合作、代码更新和维护、持续部署方面的困难，更重要的是，这种架构无法支持互联网行业对高并发的需求。下图为一个典型商城应用的单体架构及其SSM实现架构： 关于单体式应用的更多资料，可参看： JavaWeb开发之详解Servlet及Servlet容器 基于SSM的Java Web应用开发原理初探 集群 至少在高并发的需求上，单体应用的缺陷是行业所无法忍受的， 那如何提升并发性能呢？一个直接的思路是，把单体应用变成多体，变成集群