分布式开发

1、为什么要使用分布式锁 在分布式场景下为了保证数据最终一致性。在单进程的系统中，存在多个线程可以同时改变某个变量（可变共享变量）时，就需要对变量或代码块做同步(lock—synchronized)，使其在修改这种变量时能够线性执行消除并发修改变量。但分布式系统是多部署、多进程的，开发语言提供的并发处理API在此场景下就无能为力了。 2.分布式锁的使用场景 电商网站用下单操作时需要使用，秒杀活动更是如此，否则会出现超卖（库存100，秒杀活动时库存变负数了 3、分布式锁的实现方式 大概有三种：1.基于关系型数据库，2.基于缓存，3基于zookeeper 大部分网站使用的是基于缓存的，有更好的性能，而缓存一般是以集群方式部署，保证了高可用性 总体来说，支持redis单实例、redis哨兵、redis cluster、redis master-slave等各种部署架构，都可以给你完美实现。 4.基于缓存redis，使用开源 redisson 实现分布式锁 5、关于redisson 锁的几点说明， 1、通过阅读redission锁的API可以得知，其获取锁释放锁的使用和JDK里面的lock很相似，底层的实现采用了类似lock的处理方式 2、redisson 依赖redis，因此使用redisson 锁需要服务端安装redis，而且redisson 支持单机和集群两种模式下的锁的实现 3

Redis分布式锁进化史 近两年来微服务变得越来越热门，越来越多的应用部署在分布式环境中，在分布式环境中，数据一致性是一直以来需要关注并且去解决的问题，分布式锁也就成为了一种广泛使用的技术，常用的分布式实现方式为Redis，Zookeeper，其中基于Redis的分布式锁的使用更加广泛。 但是在工作和网络上看到过各个版本的Redis分布式锁实现，每种实现都有一些不严谨的地方，甚至有可能是错误的实现，包括在代码中，如果不能正确的使用分布式锁，可能造成严重的生产环境故障，本文主要对目前遇到的各种分布式锁以及其缺陷做了一个整理，并对如何选择合适的Redis分布式锁给出建议。 各个版本的Redis分布式锁 V1.0 tryLock(){ SETNX Key 1 EXPIRE Key Seconds } release(){ DELETE Key } 这个版本应该是最简单的版本，也是出现频率很高的一个版本，首先给锁加一个过期时间操作是为了避免应用在服务重启或者异常导致锁无法释放后，不会出现锁一直无法被释放的情况。 这个方案的一个问题在于每次提交一个Redis请求，如果执行完第一条命令后应用异常或者重启，锁将无法过期，一种改善方案就是使用Lua脚本（包含SETNX和EXPIRE两条命令），但是如果Redis仅执行了一条命令后crash或者发生主从切换，依然会出现锁没有过期时间，最终导致无法释放

近两年来微服务变得越来越热门，越来越多的应用部署在分布式环境中，在分布式环境中，数据一致性是一直以来需要关注并且去解决的问题，分布式锁也就成为了一种广泛使用的技术。 常用的分布式实现方式为Redis，Zookeeper，其中基于Redis的分布式锁的使用更加广泛。 但是在工作和网络上看到过各个版本的Redis分布式锁实现，每种实现都有一些不严谨的地方，甚至有可能是错误的实现，包括在代码中，如果不能正确的使用分布式锁，可能造成严重的生产环境故障。 本文主要对目前遇到的各种分布式锁以及其缺陷做了一个整理，并对如何选择合适的Redis分布式锁给出建议。 一、各个版本的Redis分布式锁 1、V1.0 tryLock(){ SETNX Key 1 EXPIRE Key Seconds } release(){ DELETE Key } 这个版本应该是最简单的版本，也是出现频率很高的一个版本，首先给锁加一个过期时间操作是为了避免应用在服务重启或者异常导致锁无法释放后，不会出现锁一直无法被释放的情况。 这个方案的一个问题在于每次提交一个Redis请求，如果执行完第一条命令后应用异常或者重启，锁将无法过期，一种改善方案就是使用Lua脚本（包含SETNX和EXPIRE两条命令），但是如果Redis仅执行了一条命令后crash或者发生主从切换，依然会出现锁没有过期时间，最终导致无法释放。

Redis分布式锁进化史 近两年来微服务变得越来越热门，越来越多的应用部署在分布式环境中，在分布式环境中，数据一致性是一直以来需要关注并且去解决的问题，分布式锁也就成为了一种广泛使用的技术，常用的分布式实现方式为Redis，Zookeeper，其中基于Redis的分布式锁的使用更加广泛。 但是在工作和网络上看到过各个版本的Redis分布式锁实现，每种实现都有一些不严谨的地方，甚至有可能是错误的实现，包括在代码中，如果不能正确的使用分布式锁，可能造成严重的生产环境故障，本文主要对目前遇到的各种分布式锁以及其缺陷做了一个整理，并对如何选择合适的Redis分布式锁给出建议。 各个版本的Redis分布式锁 V1.0 tryLock() { SETNX Key 1 EXPIRE Key Seconds } release() { DELETE Key } 这个版本应该是最简单的版本，也是出现频率很高的一个版本，首先给锁加一个过期时间操作是为了避免应用在服务重启或者异常导致锁无法释放后，不会出现锁一直无法被释放的情况。 这个方案的一个问题在于每次提交一个Redis请求，如果执行完第一条命令后应用异常或者重启，锁将无法过期，一种改善方案就是使用Lua脚本（包含SETNX和EXPIRE两条命令），但是如果Redis仅执行了一条命令后crash或者发生主从切换，依然会出现锁没有过期时间

GlusterFS概述 GlusterFS（Gluster File System）是一个开源的分布式文件系统，主要由Z RESEARCH公司负责开发、是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，在存储方面具有强大的横向扩展能力，通过扩展不同的节点可以支持数PB存储容量和处理数干台客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间及无元的设计，可为各种不同的数据负载提供优异的性能。 GlusterFS主要由存储服务器（Block Server）、客户端及NFS/Samba存储网关（可选，根据需要选择使用）组成，GlusteFS架构中最大的设计特点是没有元数据服务器组件，这有助于提升整个系统的性能、可靠性和稳定性。 GlusterFS主要特征如下： 扩展性和高性能 高可用性 全局统一命名空间 弹性哈希算法 弹性卷算法 基于标准协议 GlusterFS的卷类型： GlusterFS支持七种卷，分布式卷、条带卷、复制卷、分布式条带卷、分布式复制卷、条带复制卷和分布式条带复制卷，这七种卷可以满足不同应用对高性能、高可用的需求。 1.分布式卷 分布式卷是GlusterFS的默认卷，在创建卷时，默认选项是创建分布式卷

预期用途 简言之，联邦核心（FC）是一个开发环境，它使得能够紧凑地表示将TensorFlow代码与分布式通信运算符（例如联邦平均中使用的运算符）组合在一起的程序逻辑-计算一组客户端上的分布式和、平均数和其他类型的分布式聚合系统中的设备，这些设备的广播模型和参数等。 您可能知道tf.contrib.distribute，这时自然要问一个问题：这个框架在哪些方面有所不同？毕竟，这两个框架都试图使tensorflow计算分布式。 一种思考的方式是，尽管tf.contrib.distribute的既定目标是允许用户使用现有的模型和训练代码，而只需对其进行最小的更改即可实现分布式训练，但重点在于如何利用分布式基础设施使现有的训练代码更有效，这也是tff联邦核心的目标。是为了让研究人员和实践者明确控制他们将在其系统中使用的分布式通信的特定模式。fc的重点是提供一种灵活的、可扩展的语言来表达分布式数据流算法，而不是提供一组具体的分布式训练功能。 tff的fc api的主要目标受众之一是研究人员和实践者，他们可能希望试验新的联合学习算法，并评估影响分布式系统中数据流编排方式的微妙设计选择的后果，但又不会被系统实现细节所困扰。fc api的抽象级别大致相当于研究出版物中描述联邦学习算法机制的伪代码，即系统中存在哪些数据以及如何转换这些数据，但不会降低到单个点对点网络消息交换的级别。

Hadoop（二）搭建伪分布式集群 前言 　　前面只是大概介绍了一下Hadoop，现在就开始搭建集群了。我们下尝试一下搭建一个最简单的集群。之后为什么要这样搭建会慢慢的分享，先要看一下效果吧！ 一、Hadoop的三种运行模式（启动模式） 1.1、单机模式（独立模式）（Local或Standalone Mode） 　　-默认情况下，Hadoop即处于该模式，用于开发和调式。 　　-不对配置文件进行修改。 　　-使用本地文件系统，而不是分布式文件系统。 　　-Hadoop不会启动NameNode、DataNode、JobTracker、TaskTracker等守护进程，Map()和Reduce()任务作为同一个进程的不同部分来执行的。 　　-用于对MapReduce程序的逻辑进行调试，确保程序的正确。 1.2、伪分布式模式（Pseudo-Distrubuted Mode） 　　-Hadoop的守护进程运行在本机机器，模拟一个小规模的集群　 　　-在一台主机模拟多主机。 　　-Hadoop启动NameNode、DataNode、JobTracker、TaskTracker这些守护进程都在同一台机器上运行，是相互独立的Java进程。 　　-在这种模式下，Hadoop使用的是分布式文件系统，各个作业也是由JobTraker服务，来管理的独立进程。在单机模式之上增加了代码调试功能

更多资源和教程请关注公众号： 非科班的科班 。 如果觉得我写的还可以请给个赞，谢谢大家，你的鼓励是我创作的动力 课程目录介绍 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、为什么要使用消息队列? 分析 :一个用消息队列的人，不知道为啥用，这就有点尴尬

1 session存储策略 存储，即在后台使用session的setAttribute,getAttribute等方法时，这些内部存放的数据最终存储至什么位置。比如在默认的tomcat实现中，相应的数据即存储在内存中，并在停止之后会序列化至磁盘中。 可以使用内存存储和第三方存储，如redis。对于集群式的session存储，那么肯定会使用第三方存储的实现。 在spring-session中，对session存储单独作了一个定义，但定义上基本保证与http session一致，主要的目的在于它可以支持在非http的环境中模拟使用。因此不直接使用http session接口。 先看定义： public interface Session { /** 获取惟一的id,可以理解为即将每个session当作一个实体对象 */ String getId(); <T> T getAttribute(String attributeName); Set<String> getAttributeNames(); void setAttribute(String attributeName, Object attributeValue); void removeAttribute(String attributeName); } 从这个定义来看，如果要使用httpSession