分布式开发

分布式设计与开发 CAP原理和最终一致性(Eventually Consistency) 分布式算法 [分布式Paxos算法] 分布式一致性Hash算法 轮循算法（Round Robin） Hash求余算法（Hash） 最少连接算法（Least Connection） 响应速度算法（Response Time） 加权算法（Weighted） 分布式消息 分布式发布订阅消息系统Kafka架构设计 分布式缓存 Redis 分布式 Memcached 分布式 分布式存储 分布式事务 【分布式事务系列一】提出疑问和研究过程 【分布式事务系列二】Spring事务管理器PlatformTransactionManager 【分布式事务系列三】Spring的事务体系 【分布式事务系列四】分布式事务的概念 【分布式事务系列五】jotm的分布式案例 【分布式事务系列六】jotm分布式事务源码分析 【分布式事务系列七】Atomikos的分布式案例 【分布式事务系列八】JTA深度历险-原理与实现 【分布式事务系列九】聊聊分布式事务 来源： oschina 链接： https://my.oschina.net/u/120166/blog/540071

什么是Zookeeper 1、zookeeper是基于 Apache协议，高可用，高可靠，分布式，开元的分布式环境协同工作系统 -----集群、Java、不需要其它套件、可以更任何其它的系统结合 2、提供实现同步（数据同步、状态同步）、配置管理（100台服务器公用相同的配置文件）、分组 和 命名等服务、 3、Google Chubby的开源实现 4、通过Java或C++调用 为什么使用Zookeeper 1、大部分分布式应用需要一个主控、协调器或控制器来管理屋里分布的子程序（如资源、任务分配等） 2、目前，自家开发类似于Zookeeper的服务 3、Zookeeper：提供通用的分布式锁服务，用以协调分布式应用。（通讯） Zookeeper与Hadoop的关系 1、Hadoop生态系统的一员 2、独立于Hadoop 来源： oschina 链接： https://my.oschina.net/u/562875/blog/285789

每个大型网站都是由小变大的，在变大的过程中，几乎都需要经历单机架构、集群架构到分布式架构的演变。而伴随着业务系统架构一同演变的，还有各种外围系统和存储系统，比如关系型数据库的分库分表改造、从本地缓存到分布式缓存的过渡等。 在业务架构逐渐复杂的同时，保证系统的高性能、高可用、易扩展、可伸缩，使框架能有效地满足业务需要，是一个长远而艰巨的任务。本文介绍了五种相关的技术：分布式服务化架构、大流量的限流和削峰、分布式配置管理服务、热点数据的读写优化和数据库的分库分表。 值得注意的是，技术并不是越复杂越好，技术是为了更好地服务业务，只要能达到业务的需求，就是好的技术。简单说就是，即使你有实现复杂技术的能力，没有用户量和利润为基础，也难以落地实施。所以虽然下文中提到了一些框架，但是并不是每一种框架都需要你去亲自实践。很多时候，只是给你提供一个新的思路，一种新的方法，而至于是不是值得被实践，还需要得到业务和用户的考验。 文章目录 分布式服务化架构 集群和分布式 服务化架构，微服务和RPC 服务化架构的组成 服务的横向拆分 服务治理方案 总结 大流量的限流和削峰 分布式系统为什么要进行流量管制 限流方案 削峰方案 基于时间分片的削峰方案 基于异步调用的削峰方案 分布式配置管理服务 热点数据的读写优化 缓存技术 热卖商品的高并发读 基于Redis集群的多写多读方案

消息队列及常见消息队列介绍 一、消息队列(MQ)概述 消息队列（Message Queue），是分布式系统中重要的组件，其通用的使用场景可以简单地描述为： 当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。 消息队列主要解决了应用耦合、异步处理、流量削锋等问题。 当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。 二、消息队列使用场景 消息队列在实际应用中包括如下四个场景： 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败； 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间； 限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况； 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理； 下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用： 2.1 异步处理 具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。 （1）串行方式：新注册信息生成后，先发送注册邮件

一、Ceph简介： Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为openstack 的唯一后端存储来提高数据转发效率。 Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。 官网：https://ceph.com/ 官方文档：http://docs.ceph.com/docs/master/# 二、Ceph特点： 高性能： a. 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡， 并行度高。 b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架 感知等。 c. 能够支持上千个存储节点的规模，支持TB到PB级的数据。 高可用性： a. 副本数可以灵活控制。 b. 支持故障域分隔，数据强一致性。 c. 多种故障场景自动进行修复自愈。 d. 没有单点故障，自动管理。 高可扩展性： a. 去中心化。 b. 扩展灵活。 c. 随着节点增加而线性增长。 特性丰富： a. 支持三种存储接口

Google的三篇论文影响了很多很多人，也影响了很多很多系统。这三篇论文一直是分布式领域传阅的经典。根据MapReduce，于是我们有了Hadoop；根据GFS，于是我们有了HDFS；根据BigTable，于是我们有了HBase。而在这三篇论文里都提及Google的一个lock service---Chubby，哦，于是我们有了Zookeeper。 随着大数据的火热，Hxx们已经变得耳熟能详，现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人打招呼。但实际上对我们这些非大数据开发人员而言，Zookeeper是比Hxx们可能接触到更多的一个基础服务。但是，无奈的是它一直默默的位于二线，从来没有Hxx们那么耀眼。那么到底什么是Zookeeper呢？Zookeeper可以用来干什么？我们将如何使用Zookeeper？Zookeeper又是怎么实现的？ 伴随着Zookeeper有两篇论文：一篇是Zab，就是介绍Zookeeper背后使用的一致性协议的(Zookeeper atomic broadcast protocol)，还有一篇就是介绍Zookeeper本身的。在这两篇论文里都提到Zookeeper是一个分布式协调服务(a service for coordinating processes of distributed applications)

一、分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调 度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问 题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内 容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 图 1.1 分布式系统图 给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到我这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个 分布式系统 。 那我们接下来再分析一下，在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源，然后这三个物理分布的进程都要竞争这个资源，但我们又不希望他们同时进行访问，这时候我们就需要一个 协调器 ，来让他们有序的来访问这个资源

一、分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 图 1.1 分布式系统图 给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到我这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个 分布式系统 。 那我们接下来再分析一下，在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源，然后这三个物理分布的进程都要竞争这个资源，但我们又不希望他们同时进行访问，这时候我们就需要一个 协调器 ，来让他们有序的来访问这个资源

版权声明：本文为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节点上创建锁，过期时间较短