分布式技术

摘要：对于所有的分布式系统，我想事务一致性问题是极其非常重要的问题，因为它直接影响到系统的可用性。本文以下所述所要解决的问题是：对于入HBase和Solr的过程，如何保证HBase中写入的数据与Solr中写入的数据完全一致。 关键词：HBase, Solr, 分布式, 事务, 系统架构, 大数据 作者：王安琪（博客： http://www.cnblogs.com/wgp13x/ ） 一、关于分布式系统事务一致性问题 Java 中有三种可以的事务模型，分别称作本地事务模型（Local Transaction Model），编程式事务模型（Programmatic Transaction Model），和声明式事务模型（Declarative Transaction Model)。事务要求包含原子性（Atomicity），一致性（Consistency），独立性（Isolation），和持久性（Durability）。 《大型网站系统与Java中间件实践》一书中分享了一些解决分步式系统一致性问题的方案构思与实践，如在第六章中谈到的消息中间件。下表展现了解决一致性方案与传统方式的对比。 传统方式是，我做完了，发你消息。解决一致性的方案的意思就是，我先发你消息，我做完了再跟你确认我做完了。这是改进后的有事务的消息中间件。 因为在非XA 环境中，消息队列的插入过程独立于数据库更新操作

Zookeeper 是一个高性能、高可靠的分布式协调系统，是 Google Chubby 的一个开源实现。 Zookeeper 能够为分布式应用提供一致性服务，提供的功能包括： 配置维护、域名服务、分布式同步、组服务等。它 以Fast Paxos算法为基础的，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader (领导者)，只有leader才能提交proposer。 很多工作中用过的组件如Dubbo、kafka、Solr、Hadoop、HBase等都需要依赖Zookeeper。 近日了解到 Kafka 正在酝酿重大更新，可能会提供自管理的元数据仲裁机制以消除对 Zookeeper 的依赖，社区呼吁也相当强烈。那么一般而言 Zookeeper 在分布式系统中扮演什么角色？目前 Zookeeper 都应用在哪些分布式架构中？本文从 Zookeeper 可以聊起，盘点那些离不开 Zookeeper 的分布式技术架构！ 一. Zookeeper 概述 Zookeeper 是一个高性能、高可靠的分布式协调系统，是 Google Chubby 的一个开源实现。 Zookeeper 能够为分布式应用提供一致性服务，提供的功能包括： 配置维护、域名服务、分布式同步

https://www.zhihu.com/question/20004877 分布式是对业务的纵向拆分，目的是为了降低维护成本，方便后期点对点的纠错或者优化； 集群是对服务的横向扩展，目的是增强服务能力，降低服务压力 集群是个物理形态，分布式是个工作方式。 只要是一堆机器，就可以叫集群，他们是不是一起协作着干活，这个谁也不知道；一个程序或系统，只要运行在不同的机器上，就可以叫分布式，嗯，C/S架构也可以叫分布式。 集群一般是物理集中、统一管理的，而分布式系统则不强调这一点。 所以，集群可能运行着一个或多个分布式系统，也可能根本没有运行分布式系统；分布式系统可能运行在一个集群上，也可能运行在不属于一个集群的多台（2台也算多台）机器上。 前面的答案说的不太准确， 其实分布式不一定就是不同的组件，同一个组件也可以，关键在于是否通过交换信息的方式进行协作。比如说Zookeeper的节点都是对等的，但它自己就构成一个分布式系统。 也就是说， 分布式是指通过网络连接的多个组件，通过交换信息协作而形成的系统。而集群，是指同一种组件的多个实例，形成的逻辑上的整体。 可以看出这两个概念并不完全冲突，分布式系统也可以是一个集群，例子就是前面说的zookeeper等，它的特征是服务之间会互相通信协作。是分布式系统不是集群的情况，就是多个不同组件构成的系统；是集群不是分布式系统的情况

上一篇文章讨论了分布式系统中的服务调用和异步消息，今天想在这两个的基础上讨论下分布式系统需要解决的问题，以及常见的解决方案。 其实分布式系统的出现和分布式系统面临的挑战归结到最终都是因为用户数量的急剧增长导致的，随着用户数量和活跃用户数的，应用服务和数据库服务的并发访问压力越来越大，我们不得不进行服务拆分，做数据库的拆分和读写分离。服务拆分之后可以让我们能对每个服务进行针对性的部署，核心服务得到更好的隔离。 对于服务的拆分，我们可以根据领域驱动设计的思想，将整个系统进行域的划分，找出我们的核心子域、支撑子域；服务拆分之后面临的一个问题是服务之间的调用，此时RPC就出现了（当然此前还有webservice等技术），而随着RPC的出现，又带来了新的问题，就是服务的治理，例如新的服务上线之后如何让其他服务发现，服务下线之后如何剔除，服务调用超时之后如何进行处理，还有就是服务的性能监控和可用率监控以及相应的报警措施。 同时，有些场景下可能我们不需要同步的调用一些服务，只需要异步通知就可以了，虽然现在的RPC框架也可以实现异步调用，但是当异步调用失败后还是会影响到通知的准确性，于是就有了消息队列。消息队列可以让我们实现服务之间的异步调用，当需要做某一个通知时，我们只需要往消息队列的服务方发送一条消息，用一个消费者去消费这条消息然后调用其他服务即可。同样每一项技术的引入都会给我们带来新的问题

论文： https://arxiv.org/pdf/1811.05233.pdf 译文：大规模分布式SGD：瞬间训练完基于ImageNet的ResNet50 摘要 由于 大mini-batch训练的不稳定性 （为什么不稳定？） ，和 梯度同步的开销 ，深度学习分布式训练很难线性扩展到拥有大量GPU的集群。我们通过 控制batch_size 和 label smoothing （这是什么意思？） ，来解决不稳定性。通过 2D-Torus all reduce 算法 来解决梯度同步的开销。2D-Torus all reduce 算法 把GPU按照2D网格的方式组织，并且从不同方向执行通信操作 。这两种技术在NNL中实现了，我们在ABCI集群中，用122秒训练完了基于ImageNet的ResNet50。 介绍 随着数据集和DNN模型的size越来越大，训练模型所需的时间也越来越长。基于数据并行的大规模分布式深度学习是一种减少训练时间的有效手段。但是，大规模分布式训练有两个技术难题。1）大mini-batch训练会导致准确率下降。2）GPU间梯度同步的通信开销。需要一种新方法来解决这两个难题。 在过去的几年，提出了很多技术来解决这两个难题。这些工作利用基于ImageNet的ResNet50来衡量训练效果

1、为什么要使用消息队列? 分析:一个用消息队列的人，不知道为啥用，有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。 回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰 (1)解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。 我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住

1. 分布式缓存 1.1. Redis 有什么数据类型？分别用于什么场景？ 数据类型可以存储的值操作STRING字符串、整数或者浮点数对整个字符串或者字符串的其中一部分执行操作 对整数和浮点数执行自增或者自减操作LIST列表从两端压入或者弹出元素 读取单个或者多个元素 进行修剪，只保留一个范围内的元素SET无序集合添加、获取、移除单个元素 检查一个元素是否存在于集合中 计算交集、并集、差集 从集合里面随机获取元素HASH包含键值对的无序散列表添加、获取、移除单个键值对 获取所有键值对 检查某个键是否存在ZSET有序集合添加、获取、删除元素 根据分值范围或者成员来获取元素 计算一个键的排名 What Redis data structures look like 1.2. Redis 的主从复制是如何实现的？ 从服务器连接主服务器，发送 SYNC 命令； 主服务器接收到 SYNC 命名后，开始执行 BGSAVE 命令生成 RDB 文件并使用缓冲区记录此后执行的所有写命令； 主服务器 BGSAVE 执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令； 1.3. Redis

分布式场景常见问题及解决方案 前言: 本文主要是根据平常学习过程中遇到的一些分布式场景常见问题，并作出了解析，有不对或者需要补充的地方，希望广大的程序员朋友们及时改进，另外，想要学习，分布式的朋友，我提供一张分布式的学习路线思维导图，望可以给你们一点建议。 下面进入正题 一、分布式锁 分布式锁是在分布式场景下一种常见技术，通常通过基于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分布式锁进化史 张佳 2019年08月14日 Redis分布式锁进化史 近两年来微服务变得越来越热门，越来越多的应用部署在分布式环境中，在分布式环境中，数据一致性是一直以来需要关注并且去解决的问题，分布式锁也就成为了一种广泛使用的技术，常用的分布式实现方式为Redis，Zookeeper，其中基于Redis的分布式锁的使用更加广泛。 但是在工作和网络上看到过各个版本的Redis分布式锁实现，每种实现都有一些不严谨的地方，甚至有可能是错误的实现，包括在代码中，如果不能正确的使用分布式锁，可能造成严重的生产环境故障，本文主要对目前遇到的各种分布式锁以及其缺陷做了一个整理，并对如何选择合适的Redis分布式锁给出建议。 各个版本的Redis分布式锁 V1.0 tryLock(){ SETNX Key 1 EXPIRE Key Seconds } release(){ DELETE Key } 这个版本应该是最简单的版本，也是出现频率很高的一个版本，首先给锁加一个过期时间操作是为了避免应用在服务重启或者异常导致锁无法释放后，不会出现锁一直无法被释放的情况。 这个方案的一个问题在于每次提交一个Redis请求，如果执行完第一条命令后应用异常或者重启，锁将无法过期，一种改善方案就是使用Lua脚本（包含SETNX和EXPIRE两条命令）

什么是负载均衡（Load balancing） 在网站创立初期，我们一般都使用单台机器对台提供集中式服务，但随着业务量越来越大，无论性能还是稳定性上都有了更大的挑战。这时候我们就会想到通过扩容的方式来提供更好的服务。我们一般会把多台机器组成一个集群对外提供服务。然而，我们的网站对外提供的访问入口都是一个的，比如www.taobao.com。那么当用户在浏览器输入www.taobao.com的时候如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡在做的事情。 当前大多数的互联网系统都使用了服务器集群技术，集群即将相同服务部署在多台服务器上构成一个集群整体对外提供服务，这些集群可以是Web应用服务器集群，也可以是数据库服务器集群，还可以是分布式缓存服务器集群等。 在实际应用中，在Web服务器集群之前总会有一台负载均衡服务器，负载均衡设备的任务就是作为Web服务器流量的入口，挑选最合适的一台Web服务器，将客户端的请求转发给它处理，实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构，本质上也是将后端服务器作为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不需要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的是后端的集群。 软件负载解决的两个核心问题是： 选谁、转发