分布式技术

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

http://www.cnblogs.com/edisonchou/ 《大型网站技术架构》读书笔记之六：永无止境之网站的伸缩性架构 此篇已收录至 《大型网站技术架构》读书笔记系列目录 贴，点击访问该目录可获取更多内容。 首先，所谓网站的伸缩性，指 不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中，最重要的技术就是 服务器集群 ，通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 　　（1）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性； 　　（2）横向分离：将不同的业务模块分离部署，实现系统的伸缩性； 1.2 单一功通过集群规模实现伸缩 　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同，技术实现也有很大的区别。 　It is said that 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿 　　（1）应用服务器应该被设计成 无状态 的，即应用服务器不存储请求上下文信息；构建集群后

简述 分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。 例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。 解决方案 在分布式系统中，要实现分布式事务，无外乎那几种解决方案。 一、两阶段提交（2PC） 两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。 1. 运行过程 1.1 准备阶段 协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 1.2 提交阶段 如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。 2. 存在的问题 2.1 同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。 2.2 单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。 2.3 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务

更多资源和教程请关注公众号： 非科班的科班 。 如果觉得我写的还可以请给个赞，谢谢大家，你的鼓励是我创作的动力 课程目录介绍 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

jmeter（二十三）分布式测试 转载： https://www.cnblogs.com/imyalost/p/8306866.html jmeter用了一年多，也断断续续写了一些相关的博客，突然发现没有写过分布式测试的一些东西，这篇博客就介绍下利用jmeter做分布式测试的一些技术点吧，权当参考。。。 关于jmeter的介绍和元件作用，之前的博客介绍过，很多其他同行的博客也够详细的，这里不做介绍，对jmeter不甚了解的可以参考之前的博客： jmeter：菜鸟入门到进阶系列 jmeter官方文档： 用户手册 jmeter源码： Apache JMeter 一、为什么要使用分布式测试 按照一般的压力机配置，jmeter的GUI模式下（Windows），最多支持300左右的模拟请求线程，再大的话，容易造成卡顿、无响应等情况，这是限于jmeter其本身的机制和硬件配置。 有时候为了尽量模拟业务场景，需要模拟大量的并发请求，这个时候单台压力机就显得有心无力。针对这个情况，jmeter的解决方案是支持分布式压测，即将大量的模拟并发分配给 多台压力机，来满足这种大流量的并发请求场景。 二、分布式压测的原理 1、分布式测试中，选择一台作为管理机（Contorller），其他的机器作为测试执行的代理机（Agent）； 2、执行测试时，由Contorller通过命令行将测试脚本发给Agent

随着互联网发展，网站的应用规模在不断的扩大，普通的单体应用不能满足需求，可能一处小小的修改就回导致一个应用的重新部署，而且也不能对付大流量的访问。 此时就可以像微服务一样，对网站的功能进行拆分，比如可以拆分出USER（用户模块），order（订单模块）；当用户模块访问量很大时，可以把用户模块独立部署到1号机，2号机，3号机...同时来运行用户模块；1号机200并发，2号机200并发，3号机200并发，这样就一共有600了..；订单模块也可以进行相同的部署； 如果用户模块和订单模块需要数据交互，需要通过RPC（远程调用技术）来实现。以前是通过webservice接口来实现，但是太麻烦了；需要有RPC服务框架；再分布式系统中，国内常用zookeeper+dubbo组合，而Spring Boot推荐使用全栈的Spring（Spring Boot+Spring Cloud）。 当用户模块需要访问订单模块时，需要指定从订单模块1号机，还是2号机来访问...这时就需要注册中心，通过注册中心来判断选择那个。 此时需要用到的注册中心zookeeper 来源： https://www.cnblogs.com/huoxiansudi/p/11788007.html

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

一、为什么要产生Session 　　http协议本身是无状态的，客户端只需要向服务器请求下载内容，客户端和服务器都不记录彼此的历史信息，每一次请求都是独立的。 　　为什么是无状态的呢？因为浏览器与服务器是使用socke套接字进行通信，服务器将请求结果返回给浏览器之后，会关闭当前的socket链接，而且服务器也会在处理页面完毕之后销毁页面对象。 　　然而在Web应用的很多场景下需要维护用户状态才能正常工作(是否登录等)，或者说提供便捷(记住密码，浏览历史等)，状态的保持就是一个很重要的功能。因此在web应用开发里就出现了保持http链接状态的技术：一个是cookie技术，另一种是session技术。 二、Session有什么作用，如何产生并发挥作用 　　要明白Session就必须要弄明白什么是Cookie，以及Cookie和Session的关系。 　　1、什么是Cookie 　　Cookie技术是http状态保持在客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。 　　2、Cookie的产生 　　当用户首次使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息