分布式算法

一、ZooKeeper的背景 1.1 认识ZooKeeper ZooKeeper---译名为“动物园管理员”。动物园里当然有好多的动物，游客可以根据动物园提供的向导图到不同的场馆观赏各种类型的动物，而不是像走在原始丛林里，心惊胆颤的被动 物所观赏。为了让各种不同的动物呆在它们应该呆的地方，而不是相互串门，或是相互厮杀，就需要动物园管理员按照动物的各种习性加以分类和管理，这样我们才能更加放心安全的观赏动物。 回到企业级应用系统中，随着信息化水平的不断提高，企业级系统变得越来越庞大臃肿，性能急剧下降，客户抱怨频频。拆分系统是目前我们可选择的解决系统可伸缩性和性能问题的唯一行之有效的方法。但是拆分系统同时也带来了系统的复杂性——各子系统不是孤立存在的，它们彼此之间需要协作和交互，这就是我们常说的分布式系统0。各个子系统就好比动物园里的动物，为了使各个子系统能正常为用户提供统一的服务，必须需要一种机制来进行协调——这就是ZooKeeper（动物园管理员）。 1.2 为什么使用ZooKeeper 我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。他可能在网络故障迁就收到了此消息，也坑没有收到，又或者可能接收方的进程死了。发送方了解情况的唯一方法就是再次连接发送方，并向他进行询问

FROM： https://www.cnblogs.com/jajian/p/10014145.html 之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 1 | 0 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 2 | 0 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐

Eureka、Consul、Zookeeper的基本原理与比较。 前言 在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。 解决的问题 在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。 除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。 CAP CAP原则，指的是在一个分布式系统中，Consistency(一致性)

#0 系列目录# Zookeeper系列 【Zookeeper系列一】Zookeeper应用介绍与安装部署 【Zookeeper系列二】ZooKeeper典型应用场景实践 【Zookeeper系列三】ZooKeeper Java API使用 【Zookeeper系列四】ZooKeeper 分布式锁实现 【Zookeeper系列五】ZooKeeper 实时更新server列表 【Zookeeper系列六】Zookeeper 工作原理 Zookeeper源码 【Zookeeper源码一】Zookeeper 源码环境搭建 【Zookeeper源码二】Zookeeper 客户端创建连接过程分析 【Zookeeper源码三】Zookeeper 单机版服务器介绍 【Zookeeper源码四】Zookeeper 集群版服务器介绍 【Zookeeper源码五】Zookeeper 集群版建立连接过程 Zookeeper应用 基于ZooKeeper的分布式Session实现 #1 Zookeeper概述# ZooKeeper是一个为分布式应用所设计的分布的、开源的协调服务，它主要是 用来解决分布式应用中经常遇到的一些数据管理问题，简化分布式应用协调及其管理的难度，提供高性能的分布式服务 。ZooKeeper本身可以 以Standalone模式安装运行 ，不过

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

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

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

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作为作者之一，谷歌大脑