分布式系统

本文题目为《为什么要应用zookeeper》，然而本文并不是专门介绍zookeeper原理及其应用办法的文章。如果你在网上搜寻为什么要应用zookeeper，肯定能能到从zookeeper原理、实用场景到Zab算法原理等各种各样的介绍，然而看过之后是不是还是懵懵懂懂，只是学会了一些全面的、具体的知识点，还是不能文章题目的问题。zookeeper应用一种名为Zab的共识算法实现，除了Zab算法之外还有Paxos、Multi-Paxos、Raft等共识算法，实现上也有cubby、etcd、consul等独立的中间件和像Redis哨兵模式一样的嵌入式实现，这些实现都是基于相似的底层逻辑为了实用于不同场景下的工程学落地，本文的重点内容是共性的底层原理而不是具体的软件应用领导。 多线程与锁我以如何实现分布式锁为切入点，将多线程编程、锁、分布式系统、分布式系统一致性模型（线性一致性、最终一致性）、CAP定理、复制冗余、容错容灾、共识算法等一众概念有机联合起来。采纳层层递进的形式对相干概念及其互相分割开展阐述，不仅让你能将零散的知识点串连成线，而且还能站在理论利用的角度对相干概念从新思考。 之所以用分布式锁来举例，是因为在编程畛域，锁这个概念太广泛了，在多线程编程场景有同步锁、共享锁、排他所、自旋锁和锁降级等与锁无关的概念，在数据库畛域也有行级锁、表级锁、读锁、写锁、谓词锁和间隙锁等各种名词概念。实质上锁就是一种有肯定排他性的资源占有机制，一旦一方持有某个对象的锁，另一方就不能持有同一对象雷同的锁。 那么什么是分布式锁呢？要答复这个问题咱们须要先理解单机状况下锁的原理。在单机多线程编程中，咱们须要同步机制来保障共享变量的可见性和原子性。如何了解可见性和原子性呢？我用一个经典的计数器代码举例。 class Counter{ private int sum=0; public int count(int increment){ return sum += increment }}代码很简略，有过多线程编程教训的人都应该晓得count()办法在单线程下工作失常，然而在多线程场景下就会生效。原则上一个线程循环执行一百遍count(1)和一百个线程每个线程执行一遍count(1)后果应该都是100，然而理论执行的后果大概率是不雷同，这种单线程下执行正确然而多线程下执行逻辑不正确的状况咱们称之为线程不平安。 为什么在多线程下执行后果不正确呢？首先当两个线程同时执行sum=sum+1这条语句的时候，语句并不是原子性的，而是一个读操作和一个写操作。有可能两个线程都同时读取到了sum的值为0，加1操作后sum的值被两次赋值为1，这就像第一个线程的操作被第二个线程笼罩了一下，咱们称之为笼罩更新（表1）。 工夫/线程T1T2t1读取到sum值为0 t2 读取到sum值为0t3执行sum=0+1操作 t4 执行sum=0+1操作（表1） 接下来咱们再说可见性，即便两个线程不是同时读取sum的值，也有可能当一个线程批改了sum值之后，另一个线程不能及时看到最新的批改后的值。这是因为当初的CPU为了执行效率，为每个线程调配了一个寄存器，线程对内存的赋值不是间接更新，而是先更新本人的寄存器，而后CPU异步的将寄存器的值刷新到内存。因为寄存器的读写性能远远大于内存，所以这种异步的读写形式能够大幅度晋升CPU执行效率，让CPU时钟不会因为期待IO操作而暂停。 工夫/线程T1T2t1读取到sum值为0 t2执行sum=0+1操作 t3 读取到sum值为0t4 执行sum=0+1操作（表2） 咱们须要同步机制保障count()的原子性和可见性 class Counter{ private int sum=0; public synchronized int count(int increment){ return sum += increment }}如果替换为锁的语义，这段代码就相当于 class Counter{ private int sum=0; public int count(int increment){ lock(); sum += increment unlock(); return sum; }}lock()和unlock()办法都是伪代码，相当于加锁和解锁操作。一个线程调用了lock()办法获取到锁之后才能够执行前面的语句，执行结束后调用unlock()办法开释锁。此时如果另一个线程也调用lock()办法就会因无奈获取到锁而期待，直到第一个线程执行结束后开释锁。锁岂但能保障代码执行的原子性，还能保障变量的可见性，获取到锁之后的线程读取的任何共享变量肯定是它最新的值，不会获取到其余线程批改后的过期值。 咱们再来放大一下lock()外部细节。显然为了保障获取锁的排他性，咱们须要先去判断线程是否曾经取得了锁，如果还没有线程取得锁就给以后线程加锁，如果曾经有其余线程曾经获取了锁就期待。显然获取锁自身也须要保障原子性和可见性，所以lock()办法必须是一个同步（synchronized）办法，unlock()也是一样的情理。 在强调一下，加解锁办法自身都要具备原子性和可见性是一个重要的概念，前面咱们会用到。 public synchronized void lock(){ if(!hasLocked()){ locked(); return; }else{ awaited(); }}注：以上所有代码均为伪代码，只为阐明锁的作用及原理，无需深究 ...

咱们搞技术要造就见微知著的能力，用逻辑剖析和结构来代替经验主义。例如“背压”（back-pressure）的话题就能够从很简略的模型登程，通过一步步的推导来欠缺解决方案。 生产者-消费者模型这个很简略的模型就是过程内的生产者-消费者（producer-consumer）模型。生产者和消费者在不同线程。生产者和消费者通过有界队列连贯，生产者往队列写入音讯，消费者从队列拿取音讯用于计算。若生产者速率过快，队列会写满，生产者暂停写入；若消费者速率过快，队列会排空，消费者暂停拿取。这就是简洁的压力反馈机制。 背压指的是上游速率较慢时反馈给上游的压力，心愿上游也减慢速率，然而实际上也要思考上游速率较快而压力有余的状况。 拉和推进一步剖析这一模型。如果咱们关注上游拿取数据的形式，这其实是拉模式（pull mode）。上游被动从队列拉取数据，若没有就期待（线程期待队列的信号量），而上游则是在被动往队列推送数据，这其实是推模式（push mode），若推不动就期待（线程期待队列的信号量）。当初上下游在同一个过程内，共享一个队列，拉模式和推模式同时存在。如果是分布式系统，上下游在不同的过程（以及不同的机器），那又如何呢？分布式系统个别会在拉模式和推模式之间二选一，两种模式的压力主导方不同。 在拉模式中：队列在上游，上游的生产者往队列写数据，写满就期待；上游不须要队列，消费者间接向上游申请数据，上游从队列取出数据作为响应返回给上游，这时上游的队列必定是不满的，生产者就能够持续写入数据。这里有一个问题，上游申请上游时处于期待状态，它的计算能力被节约了。更高效的形式是上游超量拉取一些数据，放在上游的外部队列里缓缓解决，同时上游能够申请上游并且期待响应。所以实际上，上游也是有队列的。但这里的重点是，用于跨过程压力反馈的是上游的队列。 在推模式中：队列在上游，生产者间接往上游发送数据，上游若队列已满而不能持续承受数据，就须要告诉上游。一种形式是申请-响应（request-response）模型：上游发送带有数据的申请给上游，并且期待上游返回一个“胜利”的响应，若不能解决就返回相应的“谬误”响应，上游减慢或暂停推送，而后再试探何时能复原推送。这种形式显然不是很快，因而也有发射后不必管（fire-and-forget）模型：上游只管发送数据，上游须要从另一个通道发送反馈音讯给上游。然而若上游不及时处理反馈音讯，还持续发送数据，而上游的队列已满，就只能产生网络丢包了，上游依据丢包率来调整推送速率。实际上，若申请-响应模型每次批量地把多个数据放在一个申请里，只需为多个数据期待一个响应，而发射后不必管模型其实也是在收到多个数据后发回一个相当于响应的反馈音讯，两者又有什么区别呢？区别只有“谁”来决定批量的大小，申请-响应模型是由上游决定批量的大小，发射后不必管模型是由上游决定批量的大小。总之这里的重点是，用于跨过程压力反馈的是上游的队列。 拉模式的次要益处是，队列更凑近上游，反馈更及时。上游总是能够去申请上游，能够通过长轮询（long-polling）来满足实时性，若没有数据就期待在那（Kafka和SQS就是这么干的）。推模式的上游须要很大致力来晓得上游的状态，无论上游是满还是空，上游都要慢一拍才晓得，还可能有丢包的节约。拉模式须要上游每次给上游发申请，这个申请是额定的开销，但只有每次多申请几个数据，申请的开销也不算多大，能承受。 TCP协定中的背压既然说到丢包，就说说TCP协定中的背压吧，学名Flow Control。TCP恰好是推模式，它用滑动窗口（sliding window）来管制推送速率。上游一边推送数据包一边承受ACK包，如果滑动窗口的大小是10，就最多能有10个已收回但未被ACK的数据包。每当有ACK，就空出了一个窗口空位，能再推送一个数据包。这个滑动窗口相当于队列。若有数据包未被ACK，即丢包，能够进行无限次数的重发。未被ACK的数据包要暂存在上游的一个缓冲区里以备重发之需，称之为send buffer。上游收到数据还须要期待程序来解决，要把数据暂存在一个buffer里，称之为receive buffer。TCP的背压机制（用buffer）和应用层的背压机制（用queue）往往是同时存在的，如下图： 滑动窗口只是一个根底机制。为了达到更高效率，TCP还有拥塞管制（Congestion Control）机制，依据丢包率和一些算法来预测和调整推送速率。咱们编写分布式系统时也能够想一些预测性的方法来提高效率，而不是只靠最根本的压力反馈机制。在一个多级数据流水线中，有上游、中游和上游，压力一级级向上传导是有提早的。推模式能够利用水位线（watermark）来提高效率：上游在队列用量达到某个水位线时，把队列的余量信息反馈给上游，让上游提前调整速率而不是等到上游队列写满才做反馈。拉模式也能够利用水位线，当一个上游对应多个上游时（fan-out traffic），水位线很有帮忙（详情待补充）。 总结从根本的生产者-消费者模型登程，能够一步步推导出像数据流水线这样的分布式系统的背压机制。咱们还晓得了拉模式和推模式，对于大多数利用场景，我比拟举荐拉模式。

当一个计算工作过于简单不能被一台服务器独立实现的时候，咱们就须要分布式计算。分布式计算技术将一个大型工作切分为多个更小的工作，用多台计算机通过网络组装起来后，将每个小工作交给一些服务器来独立实现，最终实现这个简单的计算工作。本篇咱们介绍两个经典的计算框架MapReduce和Spark。 — MapReduce批处理引擎 —MapReduce是第一个比拟胜利的计算引擎，次要用于数据批处理。因为企业的大数据业务多是围绕结构化数据等价值密度更高的数据开展，所有的大数据公司开始在大数据平台上打造SQL引擎或散布数据库。2012年开始到随后两年中呈现20多个基于Hadoop的SQL引擎，以解决结构化数据问题。 MapReduce框架是Hadoop技术的外围，它的呈现是计算模式历史上的一个重大事件，在此之前行业内大多是通过MPP(Massive Parallel Programming)的形式来加强零碎的计算能力，个别都是通过简单而低廉的硬件来减速计算，如高性能计算机和数据库一体机等。而MapReduce则是通过分布式计算，只须要便宜的硬件就能够实现可扩大的、高并行的计算能力。一个MapReduce程序会蕴含一个Map过程和一个Reduce过程。在Map过程中，输出为(Key, Value)数据对，次要做过滤、转换、排序等数据操作，并将所有Key值雷同的Value值组合起来；而在Reduce过程中，解析Map阶段生成的(Key, list(value))数据，并对数据做聚合、关联等操作，生成最初的数据后果。每个worker只解决一个file split，而Map和Reduce过程之间通过硬盘进行数据交换，如果呈现任何谬误，worker会从上个阶段的磁盘数据开始从新执行相干的工作，保证系统的容错性和鲁棒性。 图片来源于《MapReduce: simplified data processing on large clusters》MapReduce在设计上并不是为了高性能，而是为了更好的弹性和可扩展性。在等同规模的硬件以及同等量级的数据上，与一些基于关系数据库的MPP数据库相比，MapReduce的剖析性能个别会慢一个数量级，不过MapReduce能够反对的集群规模和数据量级要高几个数量级。在2014年Jeff Dean提出MapReduce的论文里提及的相干集群曾经是1800台服务器的规模，而当初放眼国内，单个集群超过几千个服务器、解决数据量达到PB级别的集群有超过数百个。 除了能够反对PB级别的弹性化数据计算外，MapReduce还有几个很好的架构个性，这些个性也都被起初的一些计算框架（如Spark等）无效地继承。第一个个性是简化的编程接口设计，与之前的MPP畛域风行的MPI等编程接口不同，MapReduce不须要开发者本人解决并行度、数据分布策略等简单问题，而是须要关注于实现Map和Reduce对应的业务逻辑，从而大大简化开发过程。另外MapReduce的计算基于key-value的数据对，value域能够蕴含各种类型的数据，如结构化数据或图片、文件类非结构化数据，因而MapReduce计算框架可能很好地反对非结构化数据的解决。 此外，在容错性方面，因为MapReduce的分布式架构设计，在设计之初即设定了硬件故障的常态性，因而其计算模型设计了大量的容错逻辑，如工作心跳、重试、故障检测、重散布、工作黑/灰名单、磁盘故障解决等机制，笼罩了从JobTracker、TaskTracker到Job、Task和Record级别的从大到小各个层级的故障解决，从而保障了计算框架的良好容错能力。 而随着企业数据分析类需要的逐步深刻，MapReduce计算框架的架构问题从2010年后也逐步裸露进去。首先就是其性能问题，无论是框架启动开销（个别要数分钟），还是工作自身的计算性能都有余，尤其是在解决中小数据量级的数据工作上与数据库相差太大，不能用于交互式数据分析场景。有意思的是，从2010年开始，学术界有大量的论文钻研如何优化MapReduce性能，也有多个开源框架诞生进去，但都未能实现性能在量级上的晋升，因而也逐步淡出了历史。第二个重要问题是不能解决实时类数据，因而不能满足一些疾速倒退的互联网场景需要，如实时举荐、实时调度、准实时剖析等。后续Spark框架的呈现就优先解决了这几个问题，框架启动开销降到2秒以内，基于内存和DAG的计算模式无效的缩小了数据shuffle落磁盘的IO和子过程数量，实现了性能的数量级上的晋升。随着更好的计算框架呈现，MapReduce逐步退出了支流利用场景，不过其作为分布式计算的第一代技术架构，其在计算技术演进的过程中施展了重要的历史价值。 — Spark计算框架 —随着大量的企业开始通过Hadoop来构建企业应用，MapReduce的性能慢的问题逐步成为瓶颈，只能用于离线的数据处理，而不能用于对性能要求高的计算场景，如在线交互式剖析、实时剖析等。在此背景下，Spark计算模型诞生了。尽管实质上Spark依然是一个MapReduce的计算模式，然而有几个外围的翻新使得Spark的性能比MapReduce快一个数量级以上。第一是数据尽量通过内存进行交互，相比拟基于磁盘的替换，可能防止IO带来的性能问题；第二采纳Lazy evaluation的计算模型和基于DAG（Directed Acyclic Graph, 有向无环图）的执行模式，能够生成更好的执行打算。此外，通过无效的check pointing机制能够实现良好的容错，防止内存生效带来的计算问题。 Spark 实现了一种分布式的内存形象，称为弹性分布式数据集(RDD，Resilient Distributed Datasets)。它反对基于工作集的利用，同时具备数据流模型的特点 主动容错、地位感知调度和可伸缩性。RDD 容许用户在执行多个查问时显式地将工作集缓存在内存中，后续的查问可能重用工作集，这极大地晋升了查问速度。RDD提供了一种高度受限的共享内存模型，即RDD是只读的记录分区的汇合，只能通过在其余RDD执行确定的转换操作(如map、join和 groupBy) 而创立，然而这些限度使得实现容错的开销很低。与分布式共享内存零碎须要付出昂扬代价的检查点和回滚机制不同，RDD通过Lineage来重建失落的分区一个RDD中蕴含了如何从其余 RDD衍生所必须的相干信息，从而不须要检查点操作就能够重构失落的数据分区。 除了Spark Core API以外，Spark还蕴含几个次要的组件来提供大数据分析和数据挖掘的能力，次要包含Spark SQL、Spark Streaming、Spark MLLib。 Spark SQL Spark SQL是基于Spark引擎提供应用SQL来做统计分析的模块，因为有较好的SQL兼容性，对一般数据开发者应用比较简单，因而在用户中应用比拟宽泛。SparkSQL充沛排汇了Hive等我的项目的架构优缺点，通过无效的模块化以及与Hive元数据模块的兼容，使得开发者能够间接用Spark SQL来剖析Hive中的数据表，而比间接应用Hive做剖析可能大幅度提高性能。尔后，Spark SQL陆续减少了对JSON等各种内部数据源的反对，并提供了一个标准化的数据源API。数据源API给Spark SQL提供了拜访结构化数据的可插拔机制。各种数据源有了简便的路径去进行数据转换并接入到Spark平台进行计算，此外由API提供的优化器，在大多数状况下，能够将过滤和列修剪都下推到数据源，从而极大地缩小了待处理的数据量，可能显著进步Spark的工作效率。通过这些架构上的翻新，Spark SQL能够无效地剖析多样化的数据，包含Hadoop、Alluxio、各种云存储，以及一些内部数据库。 Spark Streaming Spark Streaming 基于 Spark Core 实现了可扩大、高吞吐和容错的实时数据流解决。Spark Streaming 是将流式计算分解成一系列短小的批处理作业。这里的批处理引擎是Spark，也就是把Spark Streaming的输出数据依照micro batch size(如500毫秒)分成一段一段的数据(Discretized Stream)，每一段数据都转换成 Spark中RDD(Resilient Distributed Dataset)，而后将Spark Streaming中对DStream的转换操作变为针对Spark中对RDD的转换操作，将RDD通过操作变成两头后果保留在内存中。 ...

作者 | 月色如海 导读 随着对用户体验的一直谋求，提早剖析成为大型分布式系统中不可或缺的一环。本文介绍了目前在线服务中罕用的提早分析方法，重点解说了要害路径分析的原理和技术实现计划，实际表明此计划效果显著，在耗时优化方面施展了重要作用，心愿这些内容可能对有趣味的读者产生启发，并有所帮忙。 全文4528字，预计浏览工夫12分钟。 01 背景近年来，互联网服务的响应提早(latency)对用户体验的影响愈发重要，然而以后对于服务接口的提早剖析却没有很好的伎俩。特地是互联网业务迭代速度快，性能更新周期短，必须在最短的工夫内定位到提早瓶颈。然而，服务端个别都由分布式系统形成，外部存在着简单的调度和并发调用关系，传统的提早分析方法效率低下，难以满足当下互联网服务的提早剖析需要。 要害路径分析(Critical Path Tracing)作为近年来崛起的提早分析方法，受到Google，Meta，Uber等公司的青眼，并在在线服务中取得了广泛应用。百度App举荐服务作为亿级用户量的大型分布式服务，也胜利落地利用要害门路提早剖析平台，在优化产品提早、保障用户体验方面施展了重要的作用。本文介绍面向在线服务罕用的提早分析方法，并具体介绍要害路径分析的技术实现和平台化计划，最初结合实际案例，阐明如何在百度App举荐服务中播种理论业务收益。 02 罕用分布式系统提早分析方法以后业界罕用的服务提早剖析有RPC监控(RPC telemetry)，CPU分析(CPU Profiling)，分布式追踪(Distributed Tracing)，上面以一个具体的系统结构进行举例说明： △图1 系统结构示例 A、B、C、D、E别离为五个零碎服务，A1到A4、B1到B5别离为A、B零碎内的子组件(能够了解为A、B零碎外部进一步的细化组成部分)，箭头标识服务或组件之间的调用关系。 2.1 RPC监控RPC是目前微服务零碎之间罕用的调用形式，业界次要开源的RPC框架有BRPC、GRPC、Thrift等。这些RPC框架通常都集成了统计打印性能，打印的信息中含有特定的名称和对应的耗时信息，内部的监控零碎（例如：Prometheus）会进行采集，并通过仪表盘进行展现。 △图2 RPC耗时监控UI实例 此剖析形式比较简单间接，如果服务之间的调用关系比较简单，则此形式是无效的，如果零碎简单，则基于RPC剖析后果进行的优化往往不会有预期的成果。如图1，A调用B，A2和A3是并行调用，A3外部进行简单的CPU计算工作，如果A2的耗时高于A3，则剖析A->B的RPC延时是有意义的，如果A3高于A2,则缩小A->B的服务调用工夫对总体耗时没有任何影响。此外RPC剖析无奈检测零碎外部的子组件，对整体提早的剖析具备很大的局限性。 2.2 CPU ProfilingCPU剖析是将函数调用堆栈的样本收集和聚合，高频呈现的函数认为是次要的提早门路，下图是CPU火焰图的展现成果： △图3 cpu火焰图 程度的宽度示意抽样的次数，垂直方向示意调用的关系，火焰图通常是看顶层的哪个函数宽度最大，呈现“平顶”示意该函数存在性能问题。 CPU Profiling能够解决下面说的RPC监控的有余，然而因为仍然无奈通晓并行的A2和A3谁的耗时高，因而依照RPC链路剖析后果还是依照CPU剖析的后果进行优化哪个真正有成果将变得不确定，最好的形式就是都进行优化，然而这在大型简单的零碎中老本将会变得很大。可见CPU Profiling同样具备肯定的局限性。 2.3 分布式追踪分布式追踪目前在各大公司都有了很好的实际(例如Google的Dapper，Uber的Jaeger)。 △图4 分布式追踪成果示例 分布式追踪将要追踪的“节点”通过span标识，将spans依照特定形式构建成trace，成果如图4所示，从左到右示意工夫线上的不同节点耗时，同一个起始点示意并发执行。这须要收集所有跨服务申请的信息，包含具体的工夫点以及调用的父子关系，从而在内部还原零碎调用的拓扑关系，蕴含每个服务工作的开始和完结工夫，以及服务间是并行运行还是串行运行的。 通常，大多数分布式跟踪默认状况下包含RPC拜访，没有服务外部子组件信息，这须要开发人员依据本身零碎的构造进行补全，然而零碎外部本身运行的组件数目有时过于宏大，甚者达到成千盈百个，这就使得老本成为了分布式跟踪进行具体提早剖析的次要阻碍，为了在老本和数据量之间进行衡量，往往会放弃细粒度的追踪组件，这就使得剖析人员须要破费额定的精力去进一步剖析提早真正的“消耗点”。 上面介绍要害路径分析的基本原理和理论的利用。 03 要害路径分析3.1 介绍要害门路在服务外部定义为一条耗时最长的门路，如果将下面的子组件形象成不同的节点，则要害门路是由一组节点组成，这部分节点是分布式系统中申请处理速度最慢的有序汇合。一个零碎中可能有成千盈百个子组件，然而要害门路可能只有数十个节点，这样数量级式的放大使得老本大大降低。咱们在上图的根底上加上各个子模块的耗时信息。 △图5 加上耗时信息的示例系统结构 如图5所示，在B中B1并行调用B3、B4、B5，提早别离为100,150,120，而后再调用外部的B2，进行返回，要害门路为B1->B4->B2，提早为10 + 150 + 10 = 170，在A中A1并行调用A2，A3。A2和A3都实现后再调用A4，而后返回，要害门路为A1->A2->A4，提早为15 + 170 + 10 = 195 ，因而这个零碎的要害门路为红色线条的门路 A1->A2->B1->B4->B2->A4。 通过这个简略的分布式系统构造表述出要害门路，其形容了分布式系统中申请处理速度最慢步骤的有序列表。可见优化要害门路上的节点必定能达到升高整体耗时的目标。理论零碎中的要害门路远比以上形容的简单的多，上面进一步介绍要害路径分析的技术实现和平台化计划。 3.2 理论利用解决方案要害门路数据的采集到可视化剖析的流程如图所示： ...

原文首发于我的博客：https://kaolengmian7.com/post... PC 端拜访我的博客能够取得最优质的浏览体验同时也能够翻阅我的其余博文。 分布式全局惟一Id生成器有啥用？首先咱们有一个共识，那就是咱们的业务零碎大量用到惟一 Id，比方电商零碎的订单、内容社区的帖子等等。在大部分传统场景中，咱们依赖 Mysql 存储数据，并依附 Mysql 的自增 Id 来取得一个惟一 Id。 如果某个场景咱们无奈依赖 Mysql 的自增 Id（比方分库分表），亦或者应用 Mysql 很节约性能（应用 Mysql 不是为了存储数据，仅仅是为了取得一个惟一 Id），那么此时应用分布式全局惟一 Id 生成器是一个适合的计划。 有哪些分布式全局惟一Id生成形式？UUIDUUID 全称：Universally Unique Identifier。规范型式蕴含 32 个 16 进制数字，以连字号分为五段，模式为 8-4-4-4-12 的 36 个字符，示例：9628f6e9-70ca-45aa-9f7c-77afe0d26e05。 长处：代码实现简略。本机生成，简直没有性能问题。毛病：无奈保障递增。UUID 是字符串，存储和查问相比于整形更麻烦（须要的存储空间大、不好索引等）。拓展：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个破绽曾被用于寻找梅丽莎病毒的制作者地位。 不过咱们这里仅探讨 UUID 作为惟一 Id 的场景，所以不能算作毛病。 利用场景：生成 token 令牌的场景。链路追踪场景。不实用要求 Id 趋势递增的场景。不适宜作为高性能需要的场景下的数据库主键。Mysql && RedisMysql 与 Redis 的原理相似，都是利用数字自增来实现。 长处：整型，且从 0 开始。枯燥递增（区别趋势递增）。查问效率高。可读性好。毛病：存在单点问题，重大依赖 Mysql or Redis。数据库压力大，高并发抗不住。主从 Redis 存在同步提早。（这一点求教了公司团队的大佬）即使应用集群 Redis，仍无奈防止 Redis 单点。（这一点求教了公司团队的大佬）SnowFlakeSnowFlake 是 twitter 开源的分布式 ID 生成算法，也叫雪花算法，基于工夫戳来实现。 ...

背景旁友，你的线上服务是不是偶然来个超时，或者忽然抖动一下，造成用户一堆反馈投诉。而后你费了九牛二虎之力，查了一圈圈代码和日志才总算定位到问题起因了。或者公司外部有链路追踪零碎，尽管能够很轻松地通过监控判断问题呈现的起因，然而对其中的逻辑齐全摸不着头脑。只能上网搜寻一番。 旁友，skywalking分布式链路追踪框架理解一下。 有的旁友会有纳闷，我的Spring Boot 就是一个单体利用么，不须要链路追踪？有问题间接翻日志就行了，然而即便是一个 Spring Boot 单体利用，也会和以下服务打交道： 关系数据库，例如说 MySQL、PostgreSQL 等等。缓存数据库，例如说 Redis、Memcached 等等。内部三方服务，例如说微信公众号、微信领取、支付宝领取、短信平台等等可见，仅仅一个 Spring Boot 单体利用，就曾经波及到散布在不同过程中的服务了。此时，就十分有必要用上skywalking。例如说，线上某个 接口拜访十分慢，用SkyWalking 能够定位是MySQL 查问比较慢呢，还是调用的第三方服务比较慢。 而在分布式服务中，各个大厂外部零碎成千盈百的，链路关系更加简单。比方你在外卖平台上的一个点击申请可能跨了外部几十个Java利用了，在这么长的链路里去排查问题，没有好使的工具怎么行呢。如图是以后分布式系统的现状，图片起源：鹰眼下的淘宝分布式调用跟踪零碎介绍 依据上图，咱们构想： 1.零碎中有可能每天都在减少新服务或删除旧服务，也可能进行降级，当零碎呈现谬误，咱们如何定位问题？ 2.当用户申请时，响应迟缓，怎么定位问题？ 3.服务可能由不同的编程语言开发，1、2 定位问题的形式，是否适宜所有编程语言？ Skywalking框架1.介绍SkyWalking 是什么？ 官网网址 http://skywalking.apache.org/ skywalking是一个优良的国产开源框架，2015年由集体吴晟（华为开发者）开源 ， 2017年退出Apache孵化器。短短两年就被Apache支出麾下，实力可见一斑。 分布式系统的应用程序性能监督工具，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。 提供分布式追踪、服务网格遥测剖析、度量聚合和可视化一体化解决方案。 代码无侵入，通信形式采纳GRPC，实现形式是java探针，反对告警，JVM监控，反对全局调用统计等等 skywalking的架构参考了谷歌的Dapper框架的论文，Dapper并没有开源，只给了篇论文，感兴趣但又不喜英文文档的旁友能够看看论文的中文翻译Dapper，大规模分布式系统的跟踪零碎 整体架构如下： Tracing Metrics Logging ：负责从利用中，收集链路信息，发送给 SkyWalking OAP 服务器。目前反对 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。Java利用通常应用SkyWalking Agent 收集数据SkyWalking OAP ：skywalking服务端（Transport layer，Receiver cluster，Aggregator cluster）负责接管 Agent 发送的 Tracing 数据信息，而后进行剖析，存储到内部存储器( Storage )，最终提供查问性能。Storage option ：Tracing 数据存储。目前反对 ES、H2 多种存储器。咱们用ES存储即可 。GUI ：负责提供可视化控台，查看链路等Alarm：提供告警性能，这里不展现讲2.Docker形式搭建Skywalking环境为了疾速搭建环境，防止各种零碎、配置环境不同造成踩坑的状况。咱们用docker间接创立ElasticSearch、Skywalking-OAP、Skywalking-UI以及ES的管理工具Kibana。这样一套运行环境间接就能用了。话不多说，间接开干 ...

1.什么是分布式对于“分布式系统”的定义，咱们先看下书中是怎么说的。《分布式系统原理和范型》一书中是这样定义分布式系统的：“分布式系统是若干独立计算机的汇合，这些计算机对于用户来说就像是单个相干零碎”。对于这个定义，咱们直观的感触就是：首先，这种零碎相对来说很厉害，由好几台主机组成。以谷歌、亚马逊等服务商而言，他们的数据中心都由上万台主机撑持起来的。其次，尽管很它很厉害，但对于外人来说，是感觉不到这些主机的存在。也就是说，咱们只看到是一个零碎在运作。以最近的“亚马逊 S3 宕机事件”为例，平时，咱们压根不晓得亚马逊所提供的服务背地是由多少台主机组成，然而等到 S3 宕机才晓得，这货曾经是占了互联网世界的半壁江山了。从过程角度看，两个程序别离运行在两个台主机的过程上，它们相互协作最终实现同一个服务（或者性能），那么实践上这两个程序所组成的零碎，也能够称作是“分布式系统”。当然，这个两个程序能够是不同的程序，也能够是雷同的程序。如果是雷同的程序，咱们又能够称之为“集群”。所谓集群，就是将雷同的程序，通过一直横向扩大，来进步服务能力的形式。举一个生存中的例子来阐明：小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。起初客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，两个厨师的关系是集群。为了让厨师分心炒菜，把菜做到极致，再请了个配菜师负责切菜，备菜，备料 ... ， 厨师和配菜师的关系是分布式。一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。一个配菜师因故销假了，然而其余的配菜师还是该啥就干啥，只是没销假的配菜师工作平均的加量了，但他们的工作和职责是不变的，这是集群。店里生意很好，当店长接到订单后，看哪个厨师活儿不重，就将新的订单分给谁，这就是负载平衡。集群：多集体在一起做同样的事 。分布式 ：多集体在一起做不同的事 。负载平衡：决定将工作以某种规定分给谁做。 2.为什么应用分布式部署理解了什么是分布式之后，为什么要应用散布部署呢；首先分布式部署长处很显著，次要体现在上面4个方面：零碎可用性晋升传统的集中式计算或集中式存储在遇见单点故障时很容易造成整个服务不可用，分布式下的服务体系，单台机器有故障，不致于造成整个服务不可用。零碎并发能力晋升比方双 11 流动，平时订单少 50 台机器就够了，到了 11 订单量剧增，服务器减少到 100 台，每台机器之间互相独立，互不影响。零碎容错能力晋升 同一组服务别离部署在北京上海杭州，杭州的机房突发断电或者火灾，杭州机房的流量会被主动散发到北京和上海的机房，不影响用户应用。低提早参考上一个图，北京的用户申请主动散发到北京，上海的用户申请被散发到上海，服务器会依据用户的 IP 抉择间隔本人最近的机房，升高网络提早。同样分布式部署带来益处的同时也会有一些毛病，只有是上面3个方面：分布式服务依赖网络服务器间通信依赖网络，不牢靠网络包含网络延时，丢包、中断、异步，一个残缺的服务申请依赖一连串服务调用，任意一个服务节点网络呈现问题，都可能造成本次申请失败。保护老本高传统单体式服务只须要保护一个站点就能够。分布式服务零碎被拆分成若干个小服务，服务从 1 变为几十个上百个服务后，减少运维老本。 一致性，可用性，分区容错性无奈同时满足这个是最次要的，这三种个性就是平时说的 CAP 定理，在分布式系统中，这三种个性最多只能满足两种，无奈同时满足，须要依据理论状况去调整就义掉其中哪个。 3.BI零碎的分布式部署原理和技术实现随着数据的爆炸性增长，BI零碎须要解决的数据越来越多，动辄TB级，甚至PB级，于是服务器宕机，反应迟钝，查问迟缓等各种性能问题接踵而来，BI零碎的用户，心里几乎又苦又难~~~ 各路BI厂商也意识到这些问题，纷纷推出各种解决方案。 这里提供一种应用分布式部署解决方案。架构图如下： 那么分布式部署呢，次要是对ReportWorker，CotWorker，DashboardWorker组件进行横向扩大，这几个组件次要是负责仪表板和报表运算的组件，能够部署多个以提供零碎的计算性能。为了升高用户部署老本，提供了在线的近程部署形式，UI界面化操作，能够在线增加节点，近程为每个节点部署须要的组件，以及对节点组件进行在线启停，进一步升高用户部署老本。 同时也能够在线的运维治理和系统诊断性能，能够查看系统资源耗费，系统日志下载，不便对BI零碎进行运维治理，升高用户的运维老本。大家如果感兴趣欢送拜访各种在线demo,领会BI工具为数据可视化带来的便当：https://www.grapecity.com.cn/...

这篇文章的初衷，是记录拜读由Nathan Bronson, Aleksey Charapko, Abutalib Aghayev, and Timothy Zhu独特发表的论文Metastable Failures in Distributed Systems的播种，这篇论文形容了一个在大规模分布式系统中很常见的失败场景：亚稳固失败（metastable failures），它们为什么通常在高负载分布式系统中产生，以及解决问题的思路框架：如何辨认和从亚稳固失败中复原，甚至如何防止产生亚稳固失败。 事实世界中的亚稳固失败下图是某个公园中十分驰名的徒步路线中十分要害的一部分：两座山之间一段狭长的山脊，在两座山之间徒步，只有扶着铁链穿过这段山梁能力保障平安。能够假想这段铁链就是一个分布式系统。当公园不对徒步者人数做限度时，就有可能引起人群拥挤以至于长时间在终点期待去尝试减低负载。你能够设想一下”零碎“经验了以下的状态转换。 稳固状态（Stable state）当人群低于某个平安阈值时，任何一个危险因素（例如：迟缓通过铁链的徒步者）都可能引起降速，然而零碎依然可能自愈。软弱状态（Vulnerable state）拥挤人群的数量继续减少超过了某个阈值，对于每段铁链的竞争也会减少 —— 下山的人必须要期待上山的人通过，或者罗唆冒险不应用铁链而绕过他们。同样，上山的人也必须期待下山的人通过。当这种模式产生时，只有拥挤人群的数量低于某个阈值，零碎依然是能够工作的，但它当初是十分软弱的，可能变成不可自愈的失败状态。亚稳固失败状态（Metastable Failure State）当零碎处于软弱状态，某些危险因素可能导致状况好转。设想一下，一组徒步者须要破费更长的工夫通过铁链，这将会使其余上山和下山的人速度降下来。越来越多的人期待，导致在铁链两端和身在其中的残余空间越来越狭隘，进而导致人们须要更多的工夫通过，进一步导致更多的人期待...状况循环好转 —— 进入亚稳固失败状态。放弃零碎处于亚稳固失败状态的正反馈循环因为这个自续的反馈循环，零碎将放弃在这个状态，即便移除最后的诱发危险因素。为了复原，须要采取其余的措施，例如将负载升高到特定阈值以下。 亚稳固失败定义对于亚稳固失败的定义论文中形容如下 亚稳固失败产生在对于负载起源没有管制的开放系统中，一个危险因素导致系统进入一个蹩脚的状态，并且会继续存在甚至危险因素被移除。在这个状态零碎的效率通常会很低，并且会产生继续影响——通常使工作负载放大或者整体效率升高——阻止零碎从这个蹩脚的状态中复原。Metastable failures occur in open systems with an uncontrolled source of load where a trigger causes the system to enter a bad state that persists even when the trigger is removed. In this state the goodput (i.e., throughput of useful work) is unusably low, and there is a sustaining effect — often involving work amplification or decreased overall efficiency — that prevents the system from leaving the bad state.如果这样，那么为什么不总是运行在稳固状态？诚如，在许多零碎中高效的资源利用是十分重要的，所以许多零碎抉择运行在软弱状态而不是稳固状态，已取得更高的效率。当零碎处于亚稳固失败状态，零碎不会自愈，想要复原须要采取重要措施，例如升高负载。 ...

大家好，我是本期的实验室研究员——李帅。领导选举是分布式系统中最辣手的事件之一。同时，了解 Leader 是如何选举产生的以及Leader 的职责，是了解分布式系统的要害。 在分布式系统中，通常一个服务由多个节点或实例组成服务集群，提供可扩展性、高可用的服务。 这些节点能够同时工作，晋升服务解决、计算能力，然而，如果这些节点同时操作共享资源时，那就必须要协调它们的操作，避免每个节点笼罩其余节点所做的更改，从而产生数据错乱的问题。 所以，咱们须要在所有节点中选出一个领导者 Leader，来治理、协调集群的所有节点，这种也是最常见的 Master-Slave 架构。 在分布式环境中的多个节点中选取主节点 Leader，通常会应用以下几种策略： 依据过程 Id 或者实例 Id，抉择最大值，或者最小值作为主节点。实现一种常见的领导者选举算法，比方 Bully 等。通过分布式互斥锁，保障只有一段时间只有一个节点能够获取到锁，并成为主节点。在本文中，我会介绍几种常见的选举算法，包含 ZAB、Bully、Token Ring Election。 Bully 算法Garcia-Monila 在 1982 年的一篇论文中创造了 Bully 算法，这是分布式系统中很常见的选举算法，它的选举准则是“长者”为大，也就是在所有存活的节点中，选取 ID 最大的节点作为主节点。 如果有一个集群， 各个节点能够相互连接，并且每个节点都晓得其余节点的信息（ Id 和节点地址），如下： 集群初始化时，各个节点首先判断本人是不是存活的节点中 ID 最大的，如果是，就向其余节点发送 Victory 音讯，发表本人成为主节点，依据规定，此时，集群中的 P6 节点成为 Master 主节点。 当初集群中呈现了一些故障，导致节点下线。如果下线的是从节点， 集群还是一主多从，影响不大， 然而如果下线的是 P6 主节点，那就变成了一个群龙无首的局面。 当初咱们须要从新选举一个主节点！ 咱们的节点是能够相互连接，并且节点间定时进行心跳查看， 此时 P3 节点检测到 P6 主节点失败，而后 P3 节点就发动了新的选举。 首先 P3 会向比本人 ID 大的所有节点发送 Election 音讯。 因为 P6 曾经下线，申请无响应，而 P4,P5 能够接管到 Election 申请，并响应 Alive 音讯。P3 节点收到音讯后，进行选举，因为当初有比本人 Id 大的节点存活，他们接管了选举。 ...

前言代码上传到集体github仓库6.824多线程编程因为状况过于简单,单单通过运行几次go test -run 2A命令失去PASS是无奈证实代码的可靠性的.能够通过该门课程助教提供的脚本test集体最开始写过的一版代码能通过1000次测试,起初通过从新设计思考后才发现有显著的bug.所以同学们能够多应用该脚本多跑几次,看看有无出错,查找log日志发现错误在哪里.有须要的同学还能够批改测试代码.该版本代码能通过上述脚本运行2000/2000次测试无谬误,集体不敢保障bug free,如有发现错误望能斧正. 运行模型raft次要由三个局部组成: 主部(只能由此局部批改raft状态, 计时等工作都由此局部进行)发送信息局部(进行rpc调用)解决接管信息局部(响应其它raft的rpc调用,响应本人rpc调用收到的reply)同步变量 type Raft struct { rpcMutex sync.Mutex // 将收到,收回rpc调用实现之后的数据处理串行化 但并发调用rpc stateMutex sync.Mutex // 爱护raft状态的读写平安 //用于外部数据同步 requestChan chan InnerRequest responseChan chan InnerResponse timer *time.Timer}raft相当于状态机,要扭转raft的状态只有两种办法 超时 和 接管信息运行形式如下 raft主部串行执行,在加锁的状态下批改完状态之后,依据状况抉择是否reset计时器,再开释锁,应用select监听超时信号或者是解决接管信息局部发送的信号发送信息局部较为简单,只须要加锁状态下拷贝raft状态,而后并发进行rpc调用即可(留神:发送时加锁会导致不同的raft实体循环调用从而导致死锁)接管的信息是并发达到的,在所有处理函数前加锁rpcMutex,函数退出后再开释该锁,使得该阶段串行化. 此外,在执行时如果发现须要告诉raft批改状态,还要通过requestChan和responseChan与主部进行通信,因为都是0缓存,往这两个channel写数据未被读出时,写者处于阻塞状态.代码次要局部1. MainProcess通过rf.state判断执行分支 func (rf *Raft) MainProcess() { for { switch rf.state { case FOLLOWERSTATE: rf.FollowerProcess() case CANDIDATESTATE: rf.currentTerm += 1 rf.votedFor = rf.me rf.numOfVotedPeers = 1 for i := range rf.peers { if i != rf.me { rf.votedStateOfPeers[i] = false } } rf.CandidateProcess() case LEADERSTATE: rf.LeaderProcess() case DEADSTATE: return } }}2. CandidateProcessfunc (rf *Raft) CandidateProcess() { //candidate一个Term内能够发送多轮申请选票 //因而多设置了一个tmpTimer这一个计时器 tmpTimer := time.NewTimer(HEARTBEATS_INTERVAL) //Term计时器 rf.timer.Reset(GetTimeoutInterval()) //并发发送选票申请 go rf.sendAllRequestVote() for { //在进入监听状态之前要对stateMutex进行解锁 rf.stateMutex.Unlock() select { //该轮Term超时 case <-rf.timer.C: rf.stateMutex.Lock() //这里的冗余代码是为了不便揭示,该版本有多处冗余代码 rf.state = CANDIDATESTATE return //超时,发动该Term内的又一轮选票申请 case <-tmpTimer.C: rf.stateMutex.Lock() tmpTimer.Reset(GetTimeoutInterval()) go rf.sendAllRequestVote() continue //解决接管信息函数发来的信号 case tmp := <-rf.requestChan: rf.stateMutex.Lock() //操作类型 operation := tmp.operation //该信号对应的Term, term := tmp.term extraInf := tmp.extraInf //Term过期,摈弃 if term < rf.currentTerm { rf.responseChan <- InnerResponse{false, UNDIFINE, rf.currentTerm, []int{}} continue } switch operation { case NEWTERM: //这里判断条件能够是== if term <= rf.currentTerm { //因为解决局部阻塞在该channel上,即便不操作,也要开释信号 rf.responseChan <- InnerResponse{false, UNDIFINE, rf.currentTerm, []int{}} //continue用于不须要重启计时的操作的分支的退出 continue } else { if !rf.timer.Stop() { <-rf.timer.C } rf.state = FOLLOWERSTATE rf.currentTerm = extraInf[0] rf.votedFor = -1 rf.responseChan <- InnerResponse{true, UNDIFINE, rf.currentTerm, []int{}} //return用于须要重启计时的操作的分支的退出 //返回至MainProcess() //因而这种分支之前须要排空rf.timer.C return } case LEGALLEADER: if !rf.timer.Stop() { <-rf.timer.C } rf.state = FOLLOWERSTATE rf.currentTerm = extraInf[0] rf.responseChan <- InnerResponse{true, UNDIFINE, rf.currentTerm, []int{}} return case LATERCANDIDATE: if !rf.timer.Stop() { <-rf.timer.C } rf.state = FOLLOWERSTATE rf.currentTerm = extraInf[0] rf.votedFor = extraInf[1] rf.responseChan <- InnerResponse{true, UNDIFINE, rf.currentTerm, []int{}} return case VOTEFOR: rf.responseChan <- InnerResponse{false, UNDIFINE, rf.currentTerm, []int{}} continue case GETVOTE: if !rf.votedStateOfPeers[extraInf[1]] { rf.numOfVotedPeers += 1 rf.votedStateOfPeers[extraInf[1]] = true if rf.numOfVotedPeers > rf.numOfAllPeers/2 { if !rf.timer.Stop() { <-rf.timer.C } rf.state = LEADERSTATE rf.responseChan <- InnerResponse{true, UNDIFINE, rf.currentTerm, []int{}} return } else { continue } } else { continue } case BEDEAD: rf.state = DEADSTATE rf.responseChan <- InnerResponse{true, UNDIFINE, rf.currentTerm, []int{}} if !rf.timer.Stop() { <-rf.timer.C } return } } }}须要留神的细节1. 计时器timer的应用在assignment的页面里提到了能够应用time.Sleep()来代替计时性能,因为Timer和Ticker难以使用正确,然而应用time.Sleep()办法终归是不优雅.timer通过time.NewTimer(Duration)创立,在通过指定的Duration工夫之后,会往timer.C这个channel里发送信号,应用timer.Stop()能够进行计时,应用timer.Reset(Duration)能够重设工夫,这些是通过简略地浏览文档就能失去的信息.然而须要留神的一点是调用timer.Stop()的返回值在调用timer.Stop()后正确将计时器进行后,timer.Stop()返回值为true.然而当timer.Stop()在计时器进行后再调用则会返回false,为了不影响后序的信号传递,须要将timer.C排空 ...

前言本篇是对于 2022-MIT 6.828 的对于 Raft 的试验记录；如果发现内容上的纰漏，请不要悭吝您的键盘。Raft 基本概念Raft 是怎么运行的Raft 对于 Paxos 来说是个绝对简略的共识算法，但再怎么简略“Raft 是怎么运行的”也不是喋喋不休就能搞定的，而且我原本就没想喋喋不休搞定。所以在看了 Raft 论文 之后，这里有两个网页能够帮忙你了解 Raft 是怎么运行的： Raft Understandable Distributed ConsensusRaft Visualization另外还有三张我认为对我本人了解 Raft 很有帮忙的图，第一张是试验领导书上的 How the replicated service and Raft communicate，第二三张是 Morris 传授授课的板书截图： 协定对四个指针的束缚Figure 3 中的束缚是 Raft 共识算法运行正确的根底，咱们将要实现的 Raft 代码库就要是实现这些束缚： lastApplied <= commitIndex <= matchIndex < nextIndex 其中 matchIndex 和 nextIndex 是 Leader 才有的字段；在所有节点中，都有上述 lastApplied 和 commitIndex 的关系；在 Leader 中，对与它保护的过半数的 peer 的 commitIndex 和 matchIndex 都有上述关系。在 Leader 中，对与它保护的任一一个 peer 的 matchIndex 和 nextIndex 都有上述关系。无论是 Leader 的 lastApplied 还是 Follower 的 lastApplied 它们都是要尽全力地追赶各自的 commitIndex，途中须要把通过的 LogEntry 通过 applyCh 返回到下层利用中去。Leader 的 commitIndex： ...

对于银保监会对银行业，包含保险业在金融科技方面提出的一些要求。咱们后续会有几方面的重点建设方向： 第一个就是鼎力推动云化转型，包含云原生的转型和大数据云等一系列云化的转型，对于咱们的要求也是越来越高。 第二也是比拟重要的，继续优化科技与业务交融，用数字化反对企业数字化转型，通过为业务赋能为业务开展提供重要的科技根底。 第三就是夯实技术根底，加大数据治理和资产管理体系的建设。 第四是深入麻利转型 第五就是强化人才和文化的保障，这块也是十分的重要。 当初对银行的科技，包含银行的基础设施要求十分的高，很多传统基础设施的建设，曾经没有方法满足咱们当初面临的疾速扩大数据要求的场景，所以须要对原先的整体网络和零碎架构须要做一些调整。咱们须要从新扫视咱们的整体网络架构的设计，推动网络架构重整，次要有几个方面的挑战： 一方面是咱们在数据文件的集成过程中，因为咱们这边的数据交换基本上还是以数据文件的形式，就是咱们会有规范的数据文件卸载，卸载完之后会通过一个相似于HDFS或GPFS这种分布式文件系统来进行共享，然而随着数据量的增大，随着加工次数、加工工作的减少，数据集成的工作的减少，导致GPFS或者HDFS文件系统在性能上和网络带宽上的压力十分的大，当初为了满足这些性能要求，GPFS跟HDFS的存储全副是全场存储，能力保障根本生产和 I/O存储量的要求。网络带宽的话，在本机房的网络根本能满足，然而一旦跨机房并发量就十分的高。 第二点是跨机房的数据加载的场景，咱们之前的计划是用 Spark 间接跨机房把数据拉过来，然而对整个网络的开销十分的大。咱们Spark的数据拉取作业一旦提起来的时候，基本上把咱们两个同城机房的网络带宽全部打满了，就是万兆网全部打满，会影响到其余更加重要的交易业务的发展，所以对咱们的挑战十分大。咱们作为软件和零碎设计者很少去思考网络对咱们带来的耗费，然而当初咱们不得不面对这些给咱们零碎带来的压力。 另外一点就是信创这方面的压力也是十分大的，咱们之前次要抉择的是GPFS，它是IBM 的软件产品，在信创方面是不符合国家要求的，所以咱们当初也是在逐渐地换成国产的合乎生产信创要求的文件存储系统。但因为文件存储系统对咱们整个替换体系是十分要害外围模块，所以咱们也不敢轻易更换，咱们心愿通过Alluxio来做一个缓存，来屏蔽咱们上面不同的文件系统，通过这种形式来达到平稳过渡切换文件系统的目标，这就是咱们机构为什么抉择Alluxio的思考。讲一下跟Alluxio利用接触的历程，其实咱们很早就开始关注Alluxio这个产品，然而那个时候可能还没有那么迫切的须要，咱们只是作为一个前沿技术去钻研，然而到了2019年呈现了网络带宽那个问题之后，咱们感觉能够通过Alluxio来解决咱们跨机房网络加载的问题，所以咱们在那个工夫点开始测试Alluxio，而后逐渐地在2020年的时候开始小规模地试用。 到了2021年的时候，因为咱们过后打算重构咱们的大数据平台，所以在大数据平台上全面推广Alluxio的应用，包含撑持整个大数据的Spark，Impala等组件的运行，在拜访HDFS之前都先用Alluxio做一层缓存，包含所有的数据的入湖、归档这些操作之前，都会用Alluxio进行缓存，前面咱们也会更多地去应用Alluxio。当初介绍咱们这边以后的Alluxio利用的具体的状况，咱们这边分成两个机房，DC-A 机房跟DC-B 机房， DC-A机房是咱们外围的替换域，替换域就是作为文件替换、数据加载的技术平台。当初这个域上部署的是Alluxio，用Alluxio进行缓存和近程拉取，咱们的数据交换、数据入湖，包含数据计算、查问都是在Alluxio平台上运行的，所以咱们其实曾经在外围畛域引入了Alluxio，作为们的重点文件系统做撑持，前面咱们可能心愿Alluxio平台可能通过两个不同的门路进行迭代演变。咱们当初一个场景一个场景地来介绍一下，首先介绍最开始应用Alluxio进行缓存的一个场景，咱们原先在GPFS上把数据进行集成，数据集成之后要分发给不同的子公司或者分行，原先的做法就是间接在 GPFS上解压，解压之后往外发给分行，然而因为GPFS跟Spark之间没有原生的接口，所以咱们的做法就是在 GPFS跟Spark之间加了Alluxio，先把GPFS上的压缩文件解压到Alluxio上，利用Alluxio跟Spark的集成能力。当初应用了Alluxio之后能够做到一次解压，把解压后的文件缓存到 Alluxio上，再用Spark从Alluxio拉取数据。解压的过程可能从原来的屡次解压缩小成一次解压。通过Alluxio的内存，咱们又可能放慢 Spark的数据的基层解决的速度。另外一块是打算介绍缓存的分层，咱们当初刚刚做，包含分层以及存算拆散的一些做法，想通过Alluxio把咱们的数据依照冷热关系进行合成，对于内存、SSD包含近程的HDFS，咱们都想依据不同的须要进行合成，依据每天的理论运行状况，动静地往Alluxio上事后加载一些咱们比较关心的热数据，加大查问引擎的性能。咱们当初的查问引擎次要是用到Spark和Impala，Spark次要面向离线计算和解决的场景，对于大数据的查问产品，个别还是抉择Impala来做，通过Alluxio预加载或者内存缓存，对一些要害的对时效性要求十分高的利用进行减速，从而保障这些要害利用在时效上能满足咱们的要求，比方很多银行开门前的需要，或者一些疾速查问和热点查问的需要，咱们能够依据须要定制化数据寄存地位来实现冷热数据的交互。这个性能很好用也能解决咱们的问题，因为毕竟不可能所有数据都占SSD和内存，这样的话老本切实不太经济。跨机房数据加载解决了咱们一个十分大的问题，之前没有用Alluxio时，间接Spark近程拉取GPFS上的数据，咱们两个计算机房之间的网络是万兆的带宽，基本上一拉取的时候，整个网络带宽打满，影响了其余交易系统的运行零碎，导致常常被数据中心报故障，只能先暂停加载，起初通过引入Alluxio近程地把数据先拉到Alluxio上。通过Alluxio，咱们能够把有须要的数据一一从GPFS上拉到Alluxio，通过Alluxio跟Spark的原生联合能力，就可能反对十分高并发的峰值读写，这样在性能包含网络带宽还有并发性方面都能满足咱们的要求。在Alluxio上咱们也通过一些 TTL、Pin的策略实现了数据的自动式清理，所以也不须要去思考太多的数据清理的工作。这点也是咱们抉择一个专用的零碎来做这件事件的起因，大家都晓得，这件事件能够通过手工或利用上的管制去做，然而如果咱们有一个分布式文件系统可能间接把这个文件都清理和过滤掉，对咱们来讲十分有帮忙，节俭了咱们的很多工作量。对立的数据生命周期的治理，往年开始想做的一个事件就是说把Alluxio作为咱们底层多个文件系统之间的对立的接口，比如说咱们当初的GPFS，包含咱们很有可能引入的信创文件系统，包含 HDFS以及当初比拟炽热的一些对象存储，咱们都想通过Alluxio对立的接口来进行接入，上端提供不同的拜访接口，给各种计算，比如说数据采集、数据加工、报表，包含数据服务，数据迷信等一系列的利用场景提供对立的文件拜访入口。这个拜访入口又可能提供一些数据，依据咱们的编排规定可能对一些要害数据进行减速的解决。这个对于咱们整体的布局是一个十分有意义的事件，既能做到对立又能做到各种档次的不同的逐项的抉择，能够依据不同的倒退状况，抉择不同的存储系统，也能够抉择不同的计算引擎来做不同的事件。然而文件治理包含元数据管理，包含咱们看到的文件都可能通过同一个接口，我感觉对于咱们所有做这种数据体系的人来讲都是一个十分幸福的事件，有这方面教训同学应该有同感。往年在技术畛域上，包含银行的技术畛域上，对于存算拆散架构的钻研十分炽热，因为尽管个别状况下，咱们金融行业的技术热上会比互联网和社区要晚一些，然而当初曾经传导到咱们这边了，减速了咱们在存算拆散这种新的大数据架构上的钻研，预言或者试用，这块对咱们来讲也是很好的。因为咱们当初的计算资源，包含计算资源的治理，包含租户的弹性的治理，都能够通过存算拆散这种形式来实现，而后通过Alluxio进行租户存储资源的治理，这对咱们来讲是很重要的，因为以前对于计算资源的弹性治理、租户治理其实是很简略的，都有很成熟的做法，然而对于存储这一块的资源隔离，包含资源的动态分配，都比拟难做到，我感觉有可能通过Alluxio的权限管制，比方租户之间的数据拜访的隔离，通过对立的存储可能实现不同数据、不同租户的数据按需存储，这对于咱们进行大数据平台的租户治理来讲是一个很有帮忙的方向。 咱们来看一些测试，包含一些理论应用状况下的比照，对咱们平台带来的读写能力的晋升。数据拜访模式这边的话，咱们以HDFS进行比照，拜访都是一次写入屡次读取，依据咱们的测试与理论生产环境的一些数据的验证，Alluxio缓存命中的状况下，相比HDFS效率能进步一倍，就是可能缩短50%的期待拜访时效，相当于升高了HDFS的NameNode的压力，然而如果没有预加载就间接冷读，效率可能要比HDFS再延后一点，然而命中的状况下，有预加载的状况下晋升是很大的，这点还是十分的有成果。另外一点就是网络带宽压力，以方才跨机房网络加载的状况为例，没用Alluxio的时候，咱们的网络峰值会达到30GB/s，峰值十分的高，通过Alluxio的话，咱们基本上可能把峰值升高到2GB/s，也就是占用1/5的万兆光纤的带宽，近程加载了之后，峰值十分明显降低，对咱们的帮忙也十分大。1、咱们前面可能须要Alluxio社区对咱们理论企业应用在一些性能上提供帮忙，或者在将来把一些性能集成到开源社区版本外面去，一个是Cache缓存的优化以及监控，最次要是监控这一块，因为对企业应用来讲，Cache的技能是怎么样的，监控哪些数据，正在产生哪些数据，这些货色咱们都是很关怀的，一旦零碎呈现故障，咱们须要马上可能解决问题，所以监控这块十分重要。 2、第二点的话就是数据中台在存算拆散架构的演进和技术的计划，心愿可能把这种计划更多地共享进去，或者在社区内进行分享，做好租户隔离或者SLA管制，权限治理这块可能更加的优化一些。而后就是 Alluxio对计算引擎的深度优化，我晓得Alluxio对Presto零碎有很多的深度钻研跟优化，因为咱们这边用Impala，咱们心愿社区包含Alluxio这边可能对Impala引擎进行深度的优化，包含与Kubernetes的集成这一块。 3、另外一方面是咱们本人的思考，兴业银行这边总行和分行之间，咱们心愿可能通过Alluxio来做一个数据共享的计划，比如说有核心节点和分部的分中心节点这种企业架构，怎么可能通过Alluxio来实现数据的共享，在不物理搬移的状况下，通过内存的形式实现数据共享，谢谢大家。

前言本篇是对于 2022-MIT 6.828 的对于 MapReduce 的课程笔记及其试验记录；课堂笔记局部根本摘自 Lecture，齐全能够跳过；如果发现内容上的纰漏，请不要悭吝您的键盘。注释课堂笔记You should try everything else, before you try to build a distributed system, because they're not simpler.Lab's Goal? Lab 1: MapReduce implement your own version of the paperLab 2: replication for fault-tolerance using RaftLab 3: fault-tolerant key/value store use your Raft implementation to build a replicated K/V serverLab 4: sharded key/value store clone the K/V server into a number of independent groups and split the data in your K/V storage system to get parallel speed-up and moving chunks of data between servers as they come and go without dropping any ballsWhy do people build distributed systems? ...

原文地址：Distributed Mutual Exclusion算法详解Introduction应用Distributed Mutual Exclusion算法，实现一个分布式系统。 RequirementThis assignment covers material presented during the lectures on distributed systems and builds upon the work in the practicals on distributed systems. After submission you will give a mandatory demo to demonstrate and discuss your solution to the proposed problem in the light of the content of the module on distributed systems (second part of the module). A detailed schedule of demos will follow, starting from available slots in the week. ...

前言最近的ddl属实有些密集，在ddl的夹缝中艰巨地实现了Lab1...因为对Go的语法还是不太纯熟，最初实现还是借鉴了很多sample。心愿之后的lab能够齐全独立地实现吧具体的代码我挂在了GitHub上。 工作形容Lab1次要是实现分布式的MapReduce demo，其中具备worker和coordinator两种角色。worker负责并行地进行Map或Reduce工作，coordinator负责在worker申请或提交工作时进行解决，并设置超时工夫（通常为10秒），查看各worker执行工作状况。如果一个worker在规定工夫内未实现工作，coordinator会在其余worker申请工作时，将该工作将调配给其余worker。 可能会踩的坑测试脚本中的timeout指令和wait -n指令找不到的问题这是因为Mac自带的Bash版本过老，大家能够用brew install bash来装置新版本的bash。批改默认bash如同比拟麻烦，我是间接在GoLand中配置了新bash的门路，通过GoLand去run这个脚本

引子时下，随着通信技术的倒退、挪动互联网的遍及、物联网车联网人工智能的衰亡，每天所产生的数据呈爆炸性的增长。这种尺度的数据不是传统单机零碎能够独立解决的，而只能借助于大规模的分布式系统，因此分布式系统慢慢的变成一门“显学”。而作为一个分布式系统初学者，面对网上未加归类、浩如烟海的学习材料，很容易两眼抓瞎。但分布式系统有其根本钻研内容和独特倒退脉络，比方： 一些根本钻研问题：时序问题、一致性问题、容错技术、共识算法、并发管制等等。一些根本定理：CAP、PACELC、FLP渐次倒退的工业零碎：MapReduce、Spark、GFS、Dynamo、Cosmos因而只须要在“时空”两个维度对分布式系统进行把握，就能提纲挈领，愈学愈明。“时”示意分布式系统的演进脉络，能够通过浏览不同期间、学术界工业界的一些论文来把握。“空”示意分布式系统中所钻研的根本问题的拆解，能够通过浏览一些书籍建设分布式系统的常识体系。本文将我在学习分布式系统常识过程收集到的一些材料，按类别简略汇总，以飨诸君。材料排名没有先后，请按需采纳。 注： 文中举荐的材料大多为英文，如果浏览有艰难，举荐应用 Chrome 浏览器，并且给 Chrome 装一个 “google 翻译”的插件，能够点击一键“翻译此页面”。 作者：木鸟杂记 https://www.qtmuniao.com/2021..., 转载请注明出处 书籍Dr. Martin Kleppmann. Designing Data-Intensive Applications《构建数据密集型利用》，https://dataintensive.net/buy.html，作者提供收费英文版下载，网上也能够搜到。 全书分为三大部分： 零碎基石（Foundations of Data System）扩散数据（Distributed Data）衍生数据（Derived Data）零碎基石局部探讨了数据系统的一些通用侧面： 可靠性、可扩展性、可维护性（Reliable, Scalable, and Maintainable Applications）数据模型和查询语言（Data Models and Query Languages）数据存储和检索（Storage and Retrieval）数据编码和演进（Encoding and Evolution）扩散数据局部探讨了构建扩散在多机上的数据系统和一些准则和面临的问题： 冗余（replication）分片（Partition）事务（Transactions）分布式系统存在的问题（The Trouble With Distributed Systems）一致性和共识（Consistency and Consensus）衍生数据局部其实是在探讨扩散在多机上的零碎的解决问题。包含： 批处理（Batch Processing）流式解决（Stream Processing）数据系统的将来（The Future of Data Systems）近年来流批零碎趋于交融，从而让用户可能更加灵便、高效的对原始数据进行解决和变换。 这些章节拆分的都十分棒。熟读本书，让你在遇到一个新零碎时，能够如庖丁解牛个别纯熟拆解成为多个构件，并了每个构件背地的衡量取舍（trade off）。 M. van Steen and A.S. Tanenbaum, Distributed Systems, 3rd ed., distributed-systems.net, 2017.《分布式系统》第三版，https://www.distributed-systems.net/index.php/books/ds3/。作者提供英文版 PDF 收费下载链接，简介： ...

CAP 定理：一个分布式系统中，一致性（Consistency)、可用性（Availability）、分区容错性（Partition Tolerance)，这三个因素最多只能同时实现两点，不可能三者兼顾。 一致性： 在分布式系统实现某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值 => 要求分布式系统中各节点时刻保持数据一致性可用性：始终能够失常读写。客户端始终能够失常拜访并失去零碎的失常响应。=> 要求不呈现零碎操作失败或响应超时。分区容错性：某个节点或网络分区呈现故障时，整个零碎仍能对外提供满足一致性和可用性的服务。即局部故障不影响整体应用。

假期要完结啦～ 放松完了就收收心持续奋斗吧，五个收费线上充电资源拿去！ 保持学习，升职加薪不可企及。 （本次举荐课程适宜有肯定编程根底的同学） 分布式系统 主讲人：Frans Kaashoek 赫赫有名的 MIT 6.824 分布式系统（Distributed Systems）课程，授课内容应用 Go 语言。解说分布式系统设计原理的同时，也有入手编码的 Lab。 这门课程总共有 20 节课，4 个试验，试验都是基于 Go 实现，课程配套了试验相干的测试用例，入手实现试验能够加深对于相干常识的了解。 （原学习链接：https://pdos.csail.mit.edu/6.824/schedule.html） 学习链接：https://url.leanapp.cn/W11JWYx （B 站含机翻中文字幕） 计算机程序设计：编程原理 主讲人：Peter Norvig 来自 Google 大牛 Peter Norvig ，也是十分经典的课程，内容分享了编程概念、模式和办法，通过课程你还能够学到技术大牛解决编程问题时的一些小技巧。 课程实用于有肯定根底的 Python 程序员，进一步晋升业余能力。 学习链接：https://url.leanapp.cn/GSRry3f 密码学及其利用 主讲人：Christof Paar, Professor for Embedded Security at Ruhr University Bochum B 站有课程搬运，但无中英文字幕，德国的传授，英文讲的很好，授课过程中也没有应用高难度的单词，加快速度高三听力程度还是能够听懂的。 课程可作为密码学入门，传授讲课格调由浅入深，延展性很强，每个公式定理都会现场推演一遍，手写板书的格调也让教学节奏不至于太快。 学完能够手推大部分密码学算法，同时会打下很好的实践根底。 学习链接：https://url.leanapp.cn/pnnyU6M C++ 教程 主讲人：Yan Chernikov 百万播放量，好评如潮，被网友评为互联网解说最具体的 C++ 教程。 学习链接：https://url.leanapp.cn/hUHJlLU 后端开发学习及实际 主讲人：TDS 工程师 由 TDS 团队的工程师分享的一系列后端学习课程，蕴含后端开发的一些实际教程。帮忙工程师实现开发初阶到高阶的转变。 学习链接：https://space.bilibili.com/50642811/video ...

原文：http://book.mixu.net/distsys/... 译：祝坤荣 1.高层面看分布式系统分布式编程是通过应用多计算机来实现与单机算机雷同问题的艺术任何计算机系统都须要解决以下两个根本工作： 存储计算分布式编程是通过应用多计算机来实现与单机算机雷同问题的艺术 - 通常这是因为这个问题曾经不适宜在单个计算机解决了。 对于分布式系统没什么是真正须要的。给你有限的金钱和有限的研发工夫，咱们不须要分布式系统。所有计算和存储都能够在一个神奇盒子中实现 - 你能够花钱请人为你设一个单点，极速与极牢靠的零碎。 尽管如此，只有极少数人有有限的资源。因而，须要找到真实世界老本与收益的平衡点。在很小规模时，降级硬件是个间接的策略。然而，当问题域规模变大时，你会达到一个点，此时硬件降级曾经不能帮你解决一个单个节点能解决的问题，或者解决这个问题老本极为昂扬。在那个点上，欢送你来到分布式系统的世界。 当初的事实是只有中档配置的商用硬件最有价值 - 保护的老本能够通过采纳可容错软件来升高。 高端硬件最次要的计算收益来自于它们能够用外部内存拜访来代替迟缓的网络拜访。高端硬件的性能劣势在须要在节点间进行大量通信的工作时非常受限。 http://book.mixu.net/distsys/... 上图引自Barroso, Clidaras & Hölzle 的 https://www.morganclaypool.co... ，当假如所有节点都应用对立的内存拜访模式时，高端硬件与一般商用硬件的性能差距会变小。 个别感觉上，填加新机器会线性增长零碎的性能和容量。但理论这是不可能的，因为实际上这取决于这些独立的计算机。数据须要被复制，计算工作须要被协调等等。这也是学习分布式算法是值得的 - 它们为特定的问题提供了无效的解决方案，其领导了什么是可行的，一个正确的实现能够破费最小的老本是多大，什么是不可能的。 本文关注的是分布式编程，而零碎则是世俗的然而商业上常见的：数据中心。比方，我不会探讨一个特定网络配置上的特定问题，或者一个共享内存畛域的问题。另外，关注点会关注在零碎设计畛域而不是优化某个特定设计 - 后者是个更特定畛域的问题。 咱们想要达到：可伸缩能力和其余好货色我能看到，所有事件都是从解决规模大小开始的。 在规模很小时大部分事件都很简略 - 而当达到一个特定的规模后同样的问题则变得艰难起来，从流量或其余物理上的限度。举起一片巧克力很简略，举起一座山就很难了。数一个屋子里有多少人很简略，数一个国家里有多少人就很难。 所以事件都是从规模开始的 - 可扩大能力。按正式的说法，一个可伸缩的零碎中，当咱们从小变大，事件不应该在增长中变得更糟。这是另一个定义： 可伸缩(https://en.wikipedia.org/wiki... 是零碎，网络或处理器的一种能力， 以一种牢靠的形式解决一直增长的工作量或能本人变大来适应这种增长。那么什么是增长？实际上你能够通过任何形式来计算增长（人数，应用的电量等）。但有次要有以下三种须要关注： 数量伸缩：退出更多的节点能够让零碎线性增长；数据集的增长不应该导致提早的增长天文上的伸缩： 实践上能够通过多个数据中心来升高用户查问时的响应工夫，多个数据中心之间的提早能够以一种正当的形式解决。管理员伸缩： 填加更多的节点不应该减少管理员管理系统的老本（例如：管理员对机器量的比例）当然，在真实世界的增长同时产生在很多不同的维度；每种指标只捕获了增长中的其中一些局部。 一个可伸缩的零碎能够在用户规模增长时继续满足需要。这外面有两个特定的相干畛域 - 性能与可用性 - 其也能够被通过多种形式来掂量。 本文来自祝坤荣(时序)的微信公众号「麦芽面包」，公众号id「darkjune_think」 开发者/科幻爱好者/硬核主机玩家/业余翻译转载请注明。 微博:祝坤荣B站: https://space.bilibili.com/23... 交换Email: zhukunrong@yeah.net

北京工夫7月13晚间，B站“停电”网站404打不开了，音讯一出迅速刷屏，占据各大热搜榜第一。 同时还有AcFun和豆瓣解体，由此看来解体的都是流量微小的网站，解体一分钟损失上千。 B站官媒发文称，B站的局部服务器机房收到故障，从而导致无奈失常拜访，技术团队立刻开展了排障和培修，当初服务器已恢复正常运作。 此音讯一出B站美股涨幅立马收窄！ 由此看来咱们当初所应用的HTTP网络底层协定并不靠谱，经不起挫折和考验。咱们当初所应用的网络底层协定叫作HTTP，它是一个中心化存储形式，意思就是将所有的数据贮存在一个宏大的存储设备上，一旦这个宏大的设施呈现丝毫问题就会导致数据失落或者是数据异样，就像B站和豆瓣的这种景象，咱们在上网的时候经常会遇到403、403等等状况，其实这种状况就是数据失落或者损坏了。如果遇到十分重要的文件在HTTP上存储失落了这是十分低廉的损失，因为文件一旦失落或者损毁基本上是无奈找回的，HTTP除了容易失落还有很多弊病。比方、核心服务器被黑客入侵，所有的数据将没有隐衷可言，小到个人隐私大到国家机密都会被盗。你上传到云空间外面的机密照片可能会被播放给寰球70亿人观看。当初咱们破费在网络安全上的资金达到百亿甚至更高。 网络速度迟缓和存储老本低廉都是HTTP的弊病，当初一个几十G的云空间一年的租金随随便便大几百块钱，而这就是中心化存储的弊病，咱们在浏览一个网页时同时浏览人数过多就会导致加载速度迟缓，而这并不是网络速度的问题。大哥比如HPPT是一条马路，在这条路上的多了就会堵车相比而言IPFS并没有下面的这些故障，IPFS是一个联合区块链去中心化技术的分布式存储协定，它的理念是将一个数据别离存储在各个中央，这间接的保障了数据的平安，如果被入侵也只是一个小存储的数据，IPFS解决了HTTP当初空间适度冗余的问题。也就是说你想在IPFS上看一部电影，那么IPFS会问整个网络“有人有这个文件对应的哈希值吗？”在IPFS网络上就会有节点来返回文件，此时你就可能拜访到它。通俗易懂的说也就是同样一个文件只须要在网络上存储一次，而当前只有存储这颁布这个数据所有的IPFS用户只有有须要就能够应用。 因为IPFS是分布式存储，所以它也不会呈现HTTP那样的忽然打不开或者是加载迟缓，打个比方，HTTP是一条马路，那么IPFS就是无数条马路，这条走不通就走另一条。在数据 存储和替换过程中 IPFS 无疑是区块链的一场重大的反动 ，FIL矿机薇hbjky327作为有奉献有价值的网络，颠覆的便是如同亚马逊云这样的巨头 他是属于数据奉献型的我想在将来 更有价值的肯定是数据奉献型的 应用型根底的公链。 因为他们真正能做到大规模的数据共享。

分布式惟一ID应用RocketMQ时,须要应用到分布式惟一ID音讯可能会产生反复,所以要在生产端做幂等性,为了达到业务的幂等性,生产者必须要有一个惟一ID, 须要满足以下条件: 同一业务场景要全局惟一该ID必须是在音讯的发送方进行生成发送到MQ生产端依据该ID进行判断是否反复,确保幂等性在哪里产生以及生产端进行判断做幂等性与该ID无关,此ID须要保障的个性: 部分甚至全局惟一趋势递增 Snowflake算法Snowflake是Twitter开源的分布式ID生成算法, 后果是一个Long型的ID,核心思想是: 应用1位作为符号位,确定为0, 示意正应用41位作为毫秒数应用10位作为机器的ID : 高5位是数据中心ID, 低5位是机器ID应用12位作为毫秒内的序列号, 意味着每个节点每秒能够产生4096(2^12^) 个ID该算法通过二进制的操作进行实现,单机每秒内实践上最多能够生成1000*(2^12), 即409.6万个ID SnowflakeIdWorkerSnowflake算法Java实现SnowflakeIdWorker: /** * Twitter_Snowflake<br> * SnowFlake的构造如下(每局部用-离开):<br> * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br> * 1位标识，因为long根本类型在Java中是带符号的，最高位是符号位，负数是0，正数是1，所以id个别是负数，最高位是0<br> * 41位工夫截(毫秒级)，留神，41位工夫截不是存储以后工夫的工夫截，而是存储工夫截的差值（以后工夫截 - 开始工夫截) * 失去的值），这里的的开始工夫截，个别是咱们的id生成器开始应用的工夫，由咱们程序来指定的（如下上面程序IdWorker类的startTime属性）。41位的工夫截，能够应用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br> * 10位的数据机器位，能够部署在1024个节点，包含5位datacenterId和5位workerId<br> * 12位序列，毫秒内的计数，12位的计数顺序号反对每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号<br> * 加起来刚好64位，为一个Long型。<br> * SnowFlake的长处是，整体上依照工夫自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作辨别)，并且效率较高，经测试，SnowFlake每秒可能产生26万ID左右。 */public class SnowflakeIdWorker { // ==============================Fields=========================================== /** 开始工夫截 (2015-01-01) */ private final long twepoch = 1420041600000L; /** 机器id所占的位数 */ private final long workerIdBits = 5L; /** 数据标识id所占的位数 */ private final long datacenterIdBits = 5L; /** 反对的最大机器id，后果是31 (这个移位算法能够很快的计算出几位二进制数所能示意的最大十进制数) */ private final long maxWorkerId = -1L ^ (-1L << workerIdBits); /** 反对的最大数据标识id，后果是31 */ private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); /** 序列在id中占的位数 */ private final long sequenceBits = 12L; /** 机器ID向左移12位 */ private final long workerIdShift = sequenceBits; /** 数据标识id向左移17位(12+5) */ private final long datacenterIdShift = sequenceBits + workerIdBits; /** 工夫截向左移22位(5+5+12) */ private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; /** 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095) */ private final long sequenceMask = -1L ^ (-1L << sequenceBits); /** 工作机器ID(0~31) */ private long workerId; /** 数据中心ID(0~31) */ private long datacenterId; /** 毫秒内序列(0~4095) */ private long sequence = 0L; /** 上次生成ID的工夫截 */ private long lastTimestamp = -1L; //==============================Constructors===================================== /** * 构造函数 * @param workerId 工作ID (0~31) * @param datacenterId 数据中心ID (0~31) */ public SnowflakeIdWorker(long workerId, long datacenterId) { if (workerId > maxWorkerId || workerId < 0) { throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId)); } if (datacenterId > maxDatacenterId || datacenterId < 0) { throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId)); } this.workerId = workerId; this.datacenterId = datacenterId; } // ==============================Methods========================================== /** * 取得下一个ID (该办法是线程平安的) * @return SnowflakeId */ public synchronized long nextId() { long timestamp = timeGen(); //如果以后工夫小于上一次ID生成的工夫戳，阐明零碎时钟回退过这个时候该当抛出异样 if (timestamp < lastTimestamp) { throw new RuntimeException( String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp)); } //如果是同一时间生成的，则进行毫秒内序列 if (lastTimestamp == timestamp) { sequence = (sequence + 1) & sequenceMask; //毫秒内序列溢出 if (sequence == 0) { //阻塞到下一个毫秒,取得新的工夫戳 timestamp = tilNextMillis(lastTimestamp); } } //工夫戳扭转，毫秒内序列重置 else { sequence = 0L; } //上次生成ID的工夫截 lastTimestamp = timestamp; //移位并通过或运算拼到一起组成64位的ID return ((timestamp - twepoch) << timestampLeftShift) // | (datacenterId << datacenterIdShift) // | (workerId << workerIdShift) // | sequence; } /** * 阻塞到下一个毫秒，直到取得新的工夫戳 * @param lastTimestamp 上次生成ID的工夫截 * @return 以后工夫戳 */ protected long tilNextMillis(long lastTimestamp) { long timestamp = timeGen(); while (timestamp <= lastTimestamp) { timestamp = timeGen(); } return timestamp; } /** * 返回以毫秒为单位的以后工夫 * @return 以后工夫(毫秒) */ protected long timeGen() { return System.currentTimeMillis(); } //==============================Test============================================= /** 测试 */ public static void main(String[] args) { SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0); for (int i = 0; i < 1000; i++) { long id = idWorker.nextId(); System.out.println(Long.toBinaryString(id)); System.out.println(id); } }}长处: ...

Zookeeper概念Zookeeper是分布式协调服务,用于治理大型主机,在分布式环境中协调和治理服务是很简单的过程,Zookeeper通过简略的架构和API解决了这个问题 Zookeeper实现分布式锁分布式锁三要素: 加锁 解锁 锁超时Zookeeper数据结构相似树结构,由节点Znode组成Znode分为四种类型: 长久节点(PERSISTENT): 默认节点类型,创立节点的客户端与Zookeeper断开连接后,节点仍旧存在长久节点程序节点(PERSISTENT_SEQUENTIAL): 长久节点程序节点就是在创立长久节点时,Zookeeper依据创立节点的工夫程序给节点进行编号长期节点(EPHEMERAL): 创立节点的客户端与Zookeeper断开连接后,长期节点会被删除长期节点程序节点(EPHEMERAL_SEQUENTIAL): 长期节点程序节点就是在创立长期节点时,Zookeeper依据创立节点的工夫程序给节点进行编号利用Zookeeper的长期程序节点,实现分布式锁Zookeeper与Redis分布式锁比拟: 分布式锁ZookeeperRedis长处1.有封装好的框架,容易实现2.有期待锁队列,晋升抢锁的效率Set和Del指令性能高毛病增加和删除节点性能低1.实现简单,须要思考原子性,误删,锁超时问题2.没有期待锁的队列,只能客户端自旋来等锁,效率低Zookeeper的数据模型相似数据结构中的树,文件系统中的目录Zookeeper的数据存储基于节点ZnodeZnode的援用形式是门路援用,每一个Znode节点领有惟一的门路 Znode中的元素data: Znode存储的数据信息ACL: 记录Znode的拜访权限,即哪些过程和IP能够拜访本节点stat: Znode的各种元数据(数据的数据)child: 以后节点的子节点援用Zookeeper的利用场景是读多写少的利用场景:Znode不用来存储大规模的业务数据,用于存储大量的状态和配置信息(Znode存储数据不能超过1MB) Zookeeper基本操作创立节点:create删除节点:delete判断节点是否存在:exists取得一个节点的数据:getData设置一个节点的数据:setData获取节点下的所有子节点:getChildrenexists,getData,getChildren属于读操作,Zookeeper客户端在申请读操作时,能够抉择是否设置watch Zookeeper事件告诉Watch能够了解成注册在特定Znode上的触发器当Znode产生扭转的时候,调用create,delete,setData办法,将会触发Znode上注册的对应事件,申请的Watch的客户端会接管到异步告诉Zookeeper事件告诉的交互过程: 客户端调用getData办法,watch的参数是true,服务端接管到申请,返回节点数据,在对应的Hash表中插入被Watch的Znode门路以及Watcher列表当被Watch的Znode删除,服务端会查找Hash表,找到该Znode对应的所有Watcher,异步告诉客户端,并且删除Hash表中对应的key-value Zookeeper的一致性Zookeeper Service集群是一主多从构造在更新数据时,首先更新到主服务器,再同步到从服务器在读数据时,间接读取任意节点采纳ZAB协定,为了保障主从节点数据的一致性 ZAB协定ZAB(Zookeeper Automic Broadcast): 解决Zookeeper集群解体复原,主从数据同步问题ZAB三种节点状态: Looking:选举状态Following:Following节点(从节点)所处的状态Leading:Leading(主节点)所处的状态最大ZXID: 节点本地的最新事务编号,蕴含epoch和计数两局部 ZAB集群解体复原当Zookeeper的主节点服务器宕机后,集群就会进行解体复原,分成三个阶段: Leader election(选举阶段): 集群中的节点处于Looking状态,各自向其它节点发动投票,投票当中蕴含本人服务器的ID和最新事务ID(ZXID)节点用本身的ZXID和其它节点收到的ZXID作比拟,如果发现其它节点的ZXID比本身大,即数据比本人新,就从新发动投票,投票给目前已知最大ZXID所属节点每次投票后,服务器都会统计投票数量,判断是否某个节点失去半数以上的投票,这样的节点将会成为准Leader,状态变为Leading,其它节点状态变为FollowingDiscovery(发现阶段): 在从节点发现最新的ZXID和事务日志,目标是为了避免在意外状况,选举产生多个LeaderLeader接管所有Follower发送的最新的epoch值,Leader从中选出最大的epoch,基于此值+1,生成新的epoch分发给各个Follower各个Follower接管到最新的epoch,返回ACK(响应码)给Leader,带上各自最大的ZXID和历史事务日志,Leader选出最大的ZXID,并更新本身历史日志Synchronization(同步阶段): 将Leader收集失去的最新历史事务日志,同步给集群中的所有Follower,只有当半数Follower同步胜利,这个准Leader能力成为正式Leader.集群解体复原正式实现 ZAB主从数据同步BroadcastZookeeper惯例状况下更新数据的时候,由Leader播送到所有的Follower: 客户端收回写入数据申请给任意的FollowerFollower把写入数据申请转发给LeaderLeader采取二阶段提交形式:(先保留提交日志,再提交数据)先发送Propose播送给FollowerFollower接管到Propose音讯,写入日志胜利后,返回ACK音讯给LeaderLeader接管到半数以上的ACK音讯,返回胜利给客户端,并且播送commit申请给Follower 数据一致性: 强一致性 弱一致性 程序一致性:Zookeeper,依附事务ID和版本号,保证数据的更新和读取是有序的Zookeeper利用场景分布式锁: 利用Zookeeper的长期程序节点,实现分布式锁服务注册与发现: 利用Znode和Watcher,实现分布式服务注册与发现,如Dubbo共享配置和状态信息: Redis的分布式解决方案Codls,利用Zookeeper存放数据路由表和codls-proxy节点元信息,同时colds-config发动的命令都会通过Zookeeper同步到各个存活的codls-proxy高可用实现: Kafka,HBase,Hadoop都依附Zookeeper同步节点信息,实现高可用 基于Docker创立Zookeeper1.创立docker-compose.ymlzoo: image: zookeeper restart: always hostname: zoo ports: - 2181:2181 environment: - ZOO_MY_ID: 1 - ZOO_SERVER: server.1(id)=zoo(IP):2888:38882.执行docker-compose up -dZookeeper三种工作模式单机模式: 存在单点故障集群模式: 在多台服务器上部署Zookeeper集群伪集群模式: 在同一台服务器上运行多个Zookeeper实例,依然有单点故障问题,其中配置的端口号要错开 Zookeeper三种端口号2181: 客户端连贯Zookeeper集群应用的监听端口号3888: 选举Leader应用2888: 集群内机器通信应用(Leader和Follower之间数据同步应用的端口号,Leader监听此端口)

0. AbstractBigtable是一个存储pb量级结构化数据的分布式存储系统。google外部很多我的项目都在应用Bigtable，包含web indexing、Google Earth、Google Finance等，这些利用在数据大小、提早要求等方面对Bigtable的要求各不相同。Bigtable胜利的提供了一个灵便的、高性能的解决方案。本篇论文形容了Bigtable提供的数据模型，以及Bigtable的设计与实现。 1. Introduction次要是一些概括性的内容，以及对前面各节次要内容的详情。 2. Data ModelBigtable是一个稠密的、分布式的、长久化的多维度有序map。这个map被row key、column key和一个工夫戳索引，map的每个value是未解析的字节数组，即：（row:string, column:string, time:int64) -> stringrow key是任意的字符串（目前的下限是64KB，对于大部分使用者而言10-100 bytes够了）。单个row key下的单次读或者写是原子的（即便是不同的column），这样设计的起因是为了让客户分明并发更新雷同row时的零碎行为。Bigtable依照row key的字典序保留数据。表的row range动静分区，每个row range被称为tablet，是散布和负载平衡的单位。因而，对short row range的读取很高效，个别仅须要和少部分机器进行通信。客户能够利用这个性质，通过抉择适合的row keys达到对数据拜访良好的局部性。 column keys被组织为column families，是管制的根本单位。保留在同一个column family的所有数据往往领有雷同的类型，一个表中反对较少的column families（最多几百个），并且很少扭转。相同的，一个表能够领有的column没有下限（从设计上来说）。一个column key的名字应用如下语法：family:qualifier。column family的名字必须是可打印的，而qualifiers能够是任意字符串。 timestamps是一个64-bit的整数。Bigtable中能够保留一份数据的多个版本；这些版本通过timestamps索引。timestamps能够由Bigtable赋值（real time），也能够由客户利用显式指定。须要防止抵触的利用须要本人产生惟一的timestamps。不同版本的数据依照timestamp降序存储。为了更轻松的治理多个版本的数据，Bigtable反对两种垃圾回收策略（在单个column-family外部）。基于工夫的和基于数量的，在此不赘述，见论文原文。 3. APIBigtable提供了创立和删除table以及column families的函数，也提供了扭转集群、table和column family元数据的函数，比方访问控制权限。Bigtable反对单行事务，可用来执行原子的读-批改-写操作，但不反对跨行事。本节其余局部略过，见原文。 4. Building BlocksBigtable建设在Google其余的基础设施上，比方应用GFS存储日志和数据文件。Bigtable也依赖于集群管理系统来调度工作、治理机器和资源、存储机器谬误、监控机器状态等。Bigtable的数据应用Google SSTable文件格式存储。一个SSTable提供了长久的、有序的不可变kv map，并且key和value都是任意字符串。每个SSTable外部含有一系列block（每个block个别是64kb，当然这是可配置的）。SSTable的最初存储有block index，可用来定位block。Bigtable依赖于一个高可用的、长久化的分布式锁服务Chubby（应该是一个相似于zk的零碎，这里不赘述），Bigtable应用它确保master的唯一性；存储数据的bootstrap location（见5.1）；发现tablet服务和确定tablet服务death（见5.2）；存储Bigtable的架构信息（每个表的column family信息）；存储拜访权限列表。 5. ImplementationBigtable分为三个组件：一个master服务、多个tablet服务、和一个连贯客户端的library。tablet服务能够被动静增加以适应工作负载的变动。接着简要介绍了master服务和tablet服务的工作，见原文。 5.1 Tablet Location

HystrixHystrix是Netflix开源的高可用框架,可能完满解决分布式系统架构中高可用服务的问题 断路器服务降级服务熔断服务隔离机制服务雪崩效应Hystrix具备自我爱护能力 服务爱护概念在微服务高可用分布式系统中会呈现:服务间的调用超时,服务间的调用时失败问题 服务雪崩效应默认状况下,Tomcat只有一个线程池解决客户端发送的申请,这样在高并发的状况下客户端所有申请沉积在同一个服务接口,就会产生Tomcat所有线程池去解决服务接口,会导致其它服务接口无法访问,这样在其它接口拜访的时候就会产生提早和期待服务雪崩效应重大会造成连环雪崩效应,可能会导致所有微服务接口无法访问,导致整个服务瘫痪 Tomcat中有个线程池,每个线程去解决客户端发送的每次申请基于Hystrix解决服务雪崩效应的机制: 服务降级:服务熔断:服务隔离:服务降级在高并发的状况下,避免用户期待,服务调用fallBack办法,返回一个敌对提醒间接给客户端而不会去解决申请,目标是为了晋升用户体验 当Tomcat中没有线程解决客户端申请的时候,不应该让界面统一转圈,让用户期待如果服务在调用其它接口超时的时候(默认1秒),默认状况下,业务逻辑是能够执行的,如果服务没有响应间接执行的是服务降级办法服务熔断在高并发的状况下,设定服务的阈值,当流量过高超出给定的阈值,会主动开启爱护性能,应用服务降级形式返回一个敌对提醒给客户端熔断机制和服务降级是一起作用的服务熔断的目标是为了爱护服务 服务隔离服务隔离有两种:线程池隔离和信号量隔离线程池隔离: 每个服务接口都有本人独立的线程池,每个线程池互补影响因为线程池CPU占用率十分高,不是所有服务接口都采纳线程池隔离,只有外围要害的接口才会采纳线程池隔离 Hystrix环境搭建导入Hystrix依赖:spring-cloud-starter-netflix-hystrix在服务消费者(Consumer)我的项目中的配置文件中开启Hystrix断路器 feign.hystrix.enabled=true在配置文件中设置hystrix服务超时工夫,避免业务服务响应不及时,执行服务降级 hystrix.command.default.execution.isolation.thread. timeoutInMilliseconds=10000在主类上标注@EnableFeignClient开启Fegin的Hystrix性能在服务实现的办法上标注 @HystrixCommand注解应用Hystrix框架 @HystrixCommand默认开启了服务降级,服务熔断,服务隔离@HystrixCommand中的服务隔离默认开启线程池隔离形式@HystrixCommand(fallback="服务降级提醒办法名称"),其中的fallback用于服务降级fallback接口Hystrix应用类形式fallback进行服务降级的办法解决 1.新建fallback类2.类上标注@Component注解将类加载到容器中3.调用fallback类时,在@FeignClient正文中增加fallback参数@FeignClient(fallback=Fallback.class)

作业（Job）是DolphinDB中最根本的执行单位，能够简略了解为一段DolphinDB脚本代码在DolphinDB零碎中的一次执行。Job依据阻塞与否可分成同步作业和异步作业。 同步作业 同步作业也称为交互式作业（Interactive Job），它的次要起源有： Web notebookDolphinDB GUIDolphinDB命令行界面通过DolphinDB提供的各个编程语言API接口因为这种类型的作业对实时性要求较高，DolphinDB在执行过程中会主动给予较高的优先级，使其更快地失去计算资源。 异步作业 异步作业是在DolphinDB后盾执行的作业，包含： 通过submitJob或submitJobEx函数提交的批处理作业。通过scheduleJob函数提交的定时作业。Streaming 作业。这类工作个别对后果的实时反馈要求较低，且须要长期执行，DolphinDB个别会给予较低的优先级。 子工作 在DolphinDB中，若数据表数据量过大，个别都须要进行分区解决。如果一个Job A里含有分区表的查问计算工作（如SQL查问），将会分解成多个子工作并送到不同的节点上并行执行，期待子工作执行结束之后，再合并后果，持续Job A的执行。相似的，DolphinDB的分布式计算也会产生子工作。因而，Job也能够了解成一系列的子工作。 Worker与Executor DolphinDB是一个P2P架构的零碎，即每一个Data Node的角色都是雷同的，它们都能够执行来自用户提交的Job，而因为一个Job可能产生子工作，每个Data Node须要有负责Job外部执行的调度者，咱们称它为Worker，它负责解决用户提交的Job，简略计算工作的执行，并执行Job的工作合成，工作散发，并会集最终的执行后果。Job中合成进去的子工作将会被散发到集群中的Data Node上（也有可能是本地Data Node），并由Data Node上的Worker或Executor线程负责执行。 具体Worker与executor在执行job的时候次要有以下几种状况： 当一个表没有进行分区，对其查问的Job将会有Worker线程执行掉。当一个表被分区寄存在单机上时候，对其的查问Job可能会分解成多个子工作，并由该节点上的多个Executor线程执行，达到并行计算的成果。当一个表被分区存储在DFS时，对其查问的Job可能会被分解成多个子工作，这些子工作会被分发给其余Node的Worker上执行，达到分布式计算的成果。为了最大化性能，DolphinDB会将子工作发送到数据所在的Data Node上执行，以缩小网络传输开销。比方： 对于存储在DFS中的分区表，Worker将会依据分区模式以及分区以后所在Data Node来进行工作合成与散发。对于分布式计算，Worker将会依据数据源信息，发送子工作到相应的数据源Data Node执行。Job调度 Job优先级 在DolphinDB中，Job是依照优先级进行调度的，优先级的取值范畴为0-9，取值越高优先级则越高。对于优先级高的Job，零碎会更及时地给与计算资源。每个Job个别默认会有一个default priority，取值为4，而后依据Job的类型又会有所调整。 Job调度策略 基于Job的优先级，DolphinDB设计了多级反馈队列来调度Job的执行。具体来说，系统维护了10个队列，别离对应10个优先级，零碎总是调配线程资源给高优先级的Job，对于处于雷同优先级的Job，零碎会以round robin的形式调配线程资源给Job；当一个优先级队列为空的时候，才会解决低优先级的队列中的Job。 Job并行度 因为一个Job可能会分成多个并行子工作，DolphinDB的Job还领有一个并行度parallelism，示意在一个Data Node上，将会最多同时用多少个线程来执行Job产生的并行任务，默认取值为2，能够认为是一种工夫片单位。举个例子，若一个Job的并行度为2，Job产生了100个并行子工作，那么Job被调度的时候零碎只会调配2个线程用于子工作的计算，因而须要50轮调度能力实现整个Job的执行。 Job优先级的动态变化 为了避免处于低优先级的Job被长时间饥饿，DolphinDB会适当升高Job的优先级。具体的做法是，当一个job的工夫片被执行结束后，如果存在比其低优先级的Job，那么将会主动升高一级优先级。当优先级达到最低点后，又回到初始的优先级。因而低优先级的工作迟早会被调度到，解决了饥饿问题。 设置Job的优先级 DolphinDB的Job的优先级能够通过以下形式来设置： 对于console、web notebook以及API提交上来的都属于interactive job，其优先级取值为min(4，一个可调节的用户最高优先级)，因而能够通过扭转用户本身的优先级值来调整。对于通过submitJob提交上的batch job，零碎会给与default priority，即为4。用户也能够应用submitJobEx函数来指定优先级。定时工作的优先级无奈扭转，默认为4。计算容错 DolphinDB database 的分布式计算含有肯定的容错性，次要得益于分区正本冗余存储。当一个子工作被发送到一个分区正本节点上之后，若节点呈现故障或者分区正本产生了数据校验谬误(正本损坏），Job Scheduler(即某个Data Node的一个worke线程)将会发现这个故障，并且抉择该分区的另一个正本节点，从新执行子工作。用户能够通过设置dfsReplicationFactor参数来调整这种冗余度。 计算与存储耦合以及作业之间的数据共享 DolphinDB的计算是尽量凑近存储的。DolphinDB之所以不采纳计算存储拆散，次要有以下几个起因： 计算与存储拆散会呈现数据冗余。思考存储与计算拆散的Spark+Hive架构，Spark应用程序之间是不共享存储的。若N个Spark应用程序从Hive读取某个表T的数据，那么首先T要加载到N个Spark应用程序的内存中，存在N份，这将造成机器内存的的节约。在多用户场景下，比方一份tick数据可能会被多个剖析人员共享拜访，如果采取Spark那种模式，将会进步IT老本。拷贝带来的提早问题。尽管说当初数据中心逐步装备了RDMA，NVMe等新硬件，网络提早和吞吐曾经大大提高。然而这次要还是在数据中心，DolphinDB零碎的部署环境可能没有这么好的网络环境以及硬件设施，数据在网络之间的传输会成为重大的性能瓶颈。综上这些起因，DolphinDB采取了计算与存储耦合的架构。具体来说： 对于内存节约的问题，DolphinDB的解决方案是Job（对应Spark应用程序）之间共享数据。在数据通过分区存储到DolphinDB的DFS中之后，每个分区的正本都会有本人所属的节点，在一个节点上的分区正本将会在内存中只存在一份。当多个Job的子工作都波及到同一个分区正本时，该分区正本在内存中能够被共享地读取，缩小了内存的节约。对于拷贝带来的提早问题，DolphinDB的解决方案是将计算发送到数据所在的节点上。一个Job依据DFS的分区信息会被分解成多个子工作，发送到分区所在的节点上执行。因为发送计算到数据所在的节点上相当于只是发送一段代码，网络开销大大减少。

前言上一篇分布式锁的文章中，通过超市寄存物品的例子和大家简略分享了一下Java锁。本篇文章咱们就来深入探讨一下Java锁的品种，以及不同的锁应用的场景，当然本篇只介绍咱们罕用的锁。咱们分为两大类，别离是乐观锁和乐观锁，偏心锁和非偏心锁。 乐观锁和乐观锁乐观锁老猫置信，很多的技术人员首先接触到的就是乐观锁和乐观锁。老猫记得那时候是在大学的时候接触到，过后是上数据库课程的时候。过后的利用场景次要是在更新数据的时候，当然多年工作之后，其实咱们也晓得了更新数据也是应用锁十分次要的场景之一。咱们来回顾一下个别更新的步骤： 检索出须要更新的数据，提供给操作人查看。操作人员更改须要批改的数值。点击保留，更新数据。这个流程看似简略，然而如果一旦多个线程同时操作的时候，就会发现其中暗藏的问题。咱们具体看一下： A检索到数据；B检索到数据；B批改了数据；A批改了数据，是否可能批改胜利呢？上述第四点A是否可能批改胜利当然要看咱们的程序如何去实现。就从业务上来讲，当A保留数据的时候，最好的形式应该零碎给出提醒说“以后您操作的数据已被其他人批改，请从新查问确认”。这种其实是最正当的。 那么这种形式咱们该如何实现呢？咱们看一下步骤： 在检索数据的时候，咱们将相干的数据的版本号(version)或者最初的更新工夫一起检索进去。当操作人员更改数据之后，点击保留的时候在数据库执行update操作。当执行update操作的时候，用步骤1检索出的版本号或者最初的更新工夫和数据库中的记录做比拟；如果版本号或者最初更新工夫统一，那么就能够更新。如果不统一，咱们就抛出上述提醒。其实上述流程就是乐观锁的实现思路。在Java中乐观锁并没有确定的办法，或者关键字，它只是一个解决的流程、策略或者说是一种业务计划。看完这个之后咱们再看一下Java中的乐观锁。 乐观锁，它是假如一个线程在取数据的时候不会被其余线程更改数据。就像上述形容相似，然而只有在更新的时候才会去校验数据是否被批改过。其实这种就是咱们常常听到的CAS机制，英文全称（Compare And Swap）,这是一种比拟替换机制，一旦检测到有抵触。它就会进行重试。直到最初没有抵触为止。 乐观锁机制图示如下：上面咱们来举个例子，置信很多同学都是C语言入门的编程，老猫也是，大家应该都接触过i++，那么以下咱们就用i++做例子，看看i++是否是线程平安的，多个线程并发执行的时候会存在什么问题。咱们看一下上面的代码： /** * @author kdaddy@163.com * @date 2020/12/15 22:42 */public class NumCountTest { private int i=0; public static void main(String[] args) { NumCountTest test = new NumCountTest(); //线程池：50个线程 ExecutorService es = Executors.newFixedThreadPool(50); //闭锁 CountDownLatch cdl = new CountDownLatch(5000); for (int i = 0;i < 5000; i++){ es.execute(()->{ test.i++; cdl.countDown(); }); } es.shutdown(); try { //期待5000个工作执行实现后，打印出执行后果 cdl.await(); System.out.println("执行实现后，i="+test.i); } catch (InterruptedException e) { e.printStackTrace(); } }}下面的程序中，咱们用50个线程同时执行i++程序，总共执行5000次，依照惯例的了解，失去的应该是5000，然而咱们间断运行三次，失去的后果如下： ...

随着业务的扩大，数据量一直积攒，数据库系统的数据容量和计算能力会逐步不堪重负，因而优良的数据库系统必须具备良好的扩展性。DolphinDB集群中的数据节点是集计算和存储于一体的，所以要进步计算能力和数据容量，只需针对数据节点即可。DolphinDB既反对程度扩大，即减少节点，也反对垂直扩大，即减少节点的存储。 在扩大集群前，须要对DolphinDB集群有根本的概念。DolphinDB集群由3个角色组成：管制节点（Controller）、代理节点（Agent）和数据节点（Data Node）。每个角色任务分配如下： 管制节点负责管理元数据，提供Web集群管理工具。代理节点负责节点的启动和进行，每台服务器上必须有一个代理节点。数据节点负责计算和存储。与集群相干的配置文件，个别位于config目录下： controller.cfg：位于管制节点所在的服务器，负责定义管制节点的相干配置，如IP、端口号、管制节点连接数下限等。 cluster.cfg：位于管制节点所在的服务器，负责定义集群内每一个节点的个性化配置，如存储门路、连接数、内存限度等。 cluster.nodes：位于管制节点所在的服务器，集群的成员配置文件，蕴含节点的IP、端口、节点别名和角色。 agent.cfg：蕴含代理节点的IP、端口和管制节点的IP和端口。每个物理服务器必须有一个代理节点。 如果是程度扩大集群，须要批改集群的成员配置文件（cluster.nodes），如果数据节点位于新的物理服务器上，那么还须要部署一个新的代理节点（agent.cfg）来负责新物理机上节点的启停，而后重启管制节点来加载新的数据节点。当新的数据节点启动后，节点的计算能力会即时纳入集群的计算资源兼顾，然而曾经存储在集群中的数据不会调整到新的数据节点，零碎会将后续新进入的数据按策略调配到各个数据节点。 如果是垂直扩大集群，只须要批改数据节点的配置文件（cluster.cfg），为指定节点的volumes参数减少门路。 上面将具体介绍扩大集群的步骤。 1. 集群配置阐明集群部署能够参考教程多物理服务器集群部署。 示例集群有3个数据节点，每个数据节点位于一台物理服务器上，管制节点位于另外一台物理服务器上： 管制节点：172.18.0.10 数据节点1：172.18.0.11 数据节点2：172.18.0.12 数据节点3：172.18.0.13 各个配置文件的信息如下： controller.cfg localSite=172.18.0.10:8990:ctl8990cluster.nodes localSite,mode172.18.0.11:8701:agent1,agent172.18.0.12:8701:agent2,agent172.18.0.13:8701:agent3,agent172.18.0.11:8801:node1,datanode172.18.0.12:8802:node2,datanode172.18.0.13:8803:node3,datanode数据节点1所在物理服务器上的agent.cfg localSite=172.18.0.11:8701:agent1controllerSite=172.18.0.10:ctl8900为了体现扩大后的成果，咱们首先在集 群中创立一个分布式数据库，并写入数据： data = table(1..1000 as id,rand(`A`B`C,1000) as name)//分区时预留了1000的余量，准备后续写入测试用db = database("dfs://scaleout_test_db",RANGE,cutPoints(1..2000,10))tb = db.createPartitionedTable(data,"scaleoutTB",`id)tb.append!(data)执行完后通过Web的DFS Explorer察看数据的散布状况： 扩大集群后，咱们能够通过追加新的数据来察看新的节点或存储是否启用。 2. 程度扩大因为业务数据量增大，集群的存储和计算能力不能满足要求，现新增一台服务器，并把它退出原来的集群作为一个新的节点。新增的服务器IP地址为172.18.0.14，采纳8804端口号，别名为node4。新增服务器须要部署代理节点，采纳8701端口，别名为agent4. 步骤如下： （1）部署新的代理节点 把DolphinDB的安装包拷贝至新的服务器，并解压。在server文件夹下新增config文件夹，并创立agent.cfg，减少以下内容： #指定Agent自身的ip和端口localSite=172.18.0.14:8701:agent4#通知Agent本集群的controller地位controllerSite=172.18.0.10:8990:ctl8990mode=agent（2）批改集群成员配置 到管制节点所在的物理服务器，批改config/cluster.nodes，新增集群成员信息。批改后的文件内容为： localSite,mode172.18.0.11:8701:agent1,agent172.18.0.12:8701:agent2,agent172.18.0.13:8701:agent3,agent172.18.0.14:8701:agent4,agent172.18.0.11:8801:node1,datanode172.18.0.12:8802:node2,datanode172.18.0.13:8803:node3,datanode172.18.0.14:8804:node4,datanode（3）重启集群 Linux环境下，应用命令pkill dolphindb，敞开集群。期待端口资源开释后，重新启动controller和各个agent，命令如下： 启动controller： nohup ./dolphindb -console 0 -mode controller -script dolphindb.dos -config config/controller.cfg -logFile log/controller.log -nodesFile config/cluster.nodes &启动agent： ./dolphindb -mode agent -home data -script dolphindb.dos -config config/agent.cfg -logFile log/agent.log在浏览器地址栏中输出管制节点的IP和端口号，如172.18.0.10:8990，来拜访Web，咱们能够看到新减少的代理节点agent4曾经启动，数据节点node4处于关停状态。 ...

企业在应用大数据分析平台时，首先须要把海量数据从多个数据源迁徙到大数据平台中。 在导入数据前，咱们须要了解 DolphinDB database 的基本概念和特点。 DolphinDB数据表按存储介质分为3种类型： 内存表：数据只保留在本节点内存，存取速度最快，然而节点敞开后，数据将会失落。本地磁盘表：数据保留在本地磁盘上，即便节点重启，也能够不便地通过脚本把数据加载到内存中。分布式表：数据在物理上散布在不同的节点，通过DolphinDB的分布式计算引擎，逻辑上依然能够像本地表一样做对立查问。DolphinDB数据表按是否分区分为2种类型： 一般表分区表在传统的数据库中，分区是针对数据表的，即同一个数据库中的每个数据表能够有不同的分区计划；而DolphinDB的分区是针对数据库的，即一个数据库只能应用一种分区计划。如果两个表的分区计划不同，它们不能放在同一个数据库中。 DolphinDB提供了3种灵便的数据导入办法： 通过CSV文本文件导入通过HDF5文件导入通过ODBC导入1.通过CSV文本文件导入通过CSV文件进行数据直达是比拟通用的数据迁徙形式。DolphinDB提供了loadText、ploadText和loadTextEx三个函数来导入CSV文件。上面咱们通过一个示例CSV文件candle_201801.csv来阐明这3个函数的用法。 1.1 loadText 语法：loadText(filename, [delimiter=','], [schema]) 参数： _filename_是文件名。 _delimiter_和_schema_都是可选参数。 _delimiter_用于指定不同字段的分隔符，默认是“,”。 _schema_用于数据导入后每个字段的数据类型，它是一个table类型。DolphinDB提供了字段类型自动识别性能，然而某些状况下零碎自动识别的数据类型不合乎需要，比方咱们在导入示例CSVcandle_201801.csv时，volume字段会被辨认成INT类型，实际上咱们须要LONG类型，这时就须要应用schema参数。 创立schema table的脚本： nameCol = `symbol`exchange`cycle`tradingDay`date`time`open`high`low`close`volume`turnover`unixTimetypeCol = [SYMBOL,SYMBOL,INT,DATE,DATE,INT,DOUBLE,DOUBLE,DOUBLE,DOUBLE,INT,DOUBLE,LONG]schemaTb = table(nameCol as name,typeCol as type)当表的字段十分多时，创立schema table的脚本会非常简短。为了防止这个问题，DolphinDB提供了extractTextSchema函数，它能够从文本文件中提取表的构造，咱们只需批改须要指定的字段类型即可。 dataFilePath = "/home/data/candle_201801.csv"schemaTb=extractTextSchema(dataFilePath)update schemaTb set type=`LONG where name=`volume tt=loadText(dataFilePath,,schemaTb)1.2 ploadText ploadText把数据文件作为分区表并行加载到内存中，语法和loadText完全相同，然而ploadText的速度更快。ploadText次要用于疾速载入大文件，它在设计上充分利用了多个core来并行载入文件，并行水平取决于服务器自身core数量和节点的localExecutors配置。 上面咱们比照loadText和ploadText的性能。 首先，通过脚本生成一个4G左右的CSV文件： filePath = "/home/data/testFile.csv"appendRows = 100000000dateRange = 2010.01.01..2018.12.30ints = rand(100, appendRows)symbols = take(string('A'..'Z'), appendRows)dates = take(dateRange, appendRows)floats = rand(float(100), appendRows)times = 00:00:00.000 + rand(86400000, appendRows)t = table(ints as int, symbols as symbol, dates as date, floats as float, times as time)t.saveText(filePath)别离应用loadText和ploadText来导入文件，该节点是4核8线程的CPU。 ...

分布式思维分布式计算阐明: 一项工作由多个服务器共同完成的.例子: 假如一项工作独自实现须要10天,如果有10集体同时执行则一天实现. 大数据处理技术. 分布式系统阐明: 将我的项目依照特定的功能模块及层级进行拆分.从而升高整个零碎架构的耦合性问题. 分布式我的项目拆分外围:无论未来我的项目怎么拆分,都是同一个零碎. 口诀: 对外对立,对内互相独立 依照模块拆分因为单体架构中耦合性太高,所以采纳了分布式思维,将我的项目依照模块进行拆分,使得各个模块之间相互不影响.进步了整体的扩展性. 依照层级拆分阐明:因为某些我的项目性能实现起来比较复杂,须要多人协同单干,则须要将我的项目依照层级再次拆分. 分布式系统引发的问题1.分布式系统中jar包文件如何对立治理?2.分布式系统中工具API如何对立治理? 京淘我的项目后端搭建创立父级工程jt新建我的项目打包形式: pom 示意:该我的项目是一个聚合工程,里边蕴含了很多的小我的项目,并且该我的项目能够对立治理公共的jar包文件. 编辑POM.xml文件<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.jt</groupId> <artifactId>jt2007</artifactId> <version>1.0-SNAPSHOT</version> <!--1.设定打包形式 为聚合工程--> <packaging>pom</packaging> <!--2.对立治理jar包--> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.3.4.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <properties> <java.version>1.8</java.version> <skipTests>true</skipTests> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <exclusions> <exclusion> <groupId>org.junit.vintage</groupId> <artifactId>junit-vintage-engine</artifactId> </exclusion> </exclusions> </dependency> <!--spring整合mybatis-plus --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.2.0</version> </dependency> <!--springBoot整合JSP增加依赖 --> <!--servlet依赖 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> </dependency> <!--jstl依赖 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> </dependency> <!--使jsp页面失效 --> <dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-jasper</artifactId> </dependency> <!--增加httpClient jar包 --> <dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> </dependency> <!--引入dubbo配置 --> <!--<dependency> <groupId>com.alibaba.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>0.2.0</version> </dependency>--> <!--增加Quartz的反对 --> <!--<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency>--> <!-- 引入aop反对 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency> <!--spring整合redis --> <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> </dependency> <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-redis</artifactId> </dependency> </dependencies> <!-- 注意事项: 聚合工程自身不须要公布,所以不要增加 build标签 --></project>编辑工具API jt-common打包类型: jar ...

世界上最快的捷径，就是好高鹜远，本文已收录【架构技术专栏】关注这个喜爱分享的中央。在一些互联网公司的面试中，面试官往往会问这样一个问题： 如果禁用浏览器 cookie，如何实现用户追踪和认证？ 遗憾的是仍然有大量候选人答非所问，无奈搞清楚 cookie 和 session 之间的区别。 而在工作中也有让人诧异的实在案例： 把 user ID 存储到 local storage 中当做 token 应用，起因是他们宣称弃用了 cookie 这种落后的货色； 一个挪动端我的项目，服务器给出的 API 中须要客户端模仿一个 cookie，从而像浏览器中 ajax 那样生产 API。 互联网是基于 HTTP 协定构建的，而 HTTP 协定因为简略风行开来，然而 HTTP 协定是无状态（通信层面上虚电路比数据报低廉太多）的，为此人们为了追踪用户想出了各种方法，包含 cookie/session 机制、token、flash 跨浏览器 cookie 甚至浏览器指纹等。 把用户身份藏在每一个中央（浏览器指纹技术甚至不须要存储介质） 讲应用 spring security 等具体技术的材料曾经很多了，这篇文章不打算写框架和代码的具体实现。 咱们会探讨认证和受权的区别，而后会介绍一些被业界宽泛采纳的技术，最初会聊聊怎么为 API 构建抉择适合的认证形式。 认证、受权、凭证首先，认证和受权是两个不同的概念，为了让咱们的 API 更加平安和具备清晰的设计，了解认证和受权的不同就十分有必要了，它们在英文中也是不同的单词。 认证（ authentication） 指的是以后用户的身份，当用户登陆过后零碎便能追踪到他的身份做出合乎相应业务逻辑的操作。 即便用户没有登录，大多数零碎也会追踪他的身份，只是当做来宾或者匿名用户来解决。 认证技术解决的是 “我是谁？”的问题。 受权是 (authorization) 指的是什么样的身份被容许拜访某些资源，在获取到用户身份后持续检查用户的权限。 繁多的零碎受权往往是随同认证来实现的，然而在凋谢 API 的多系统结构下，受权能够由不同的零碎来实现，例如 OAuth。 受权技术是解决“我能做什么？”的问题。 ...

为防止单点瓶颈，进步存储的可用性及负载能力，零碎通常部署多个节点。但此时会呈现一些问题： 客户端写入数据胜利，零碎各内节点的数据是否也都写入胜利如果零碎内一个节点挂掉，零碎是否仍旧可用如果零碎内因为网络故障产生分区，零碎是否仍旧可用这些问题是多节点的分布式存储系统必须面对并解决的问题，即保证系统的数据统一，可用和分区容忍。 零碎的高可用有两种策略： 主从模式：分主从节点，主节点挂了从节点主动选主切换为主节点。只有主节点可进行写操作，从节点复制主节点数据，只可读以减轻负担。如：zookeeper，redis sentinel复制模式：节点角色平等，相互通信替换信息，一个节点挂掉会被踢出集群，不影响零碎的应用。如：Eureka，redis cluster（数据分片，元信息通过gossip保障统一）咱们心愿所有节点最终均保留残缺的数据，以便客户端可从任意节点读取数据，进步读取性能。零碎某一节点挂掉后也能复原数据。 为进步存储服务的写入性能，会对数据持续分片，每个分片服务要做到高可用，个别为主从部署。如Redis cluster，es，kafka。客户端读取或写入数据时，先路由到相应节点再读取或写入。三者不同的是，读取redis cluster须要客户端找到指定分片节点，如果cluster发现数据不在客户端申请的分片（slot产生迁徙），会返回客户端正确的分片地址，客户端再次发动申请。es不必客户端找到指定分片，它会在外部进行路由，客户端申请一次即可失去数据。 分布式一致性协定探讨了多个节点的数据如何达成统一，即不同节点如何替换数据，包含： 如何写入数据，数据如何同步到其余节点主/从节点挂了如何切换至从节点并使其余节点晓得集群状态感知，如新节点退出其余节点如何晓得或者不须要晓得按节点间的关系可分为两大类： 有主节点，即主从模式：raft zab paxos。集群的节点分主从，主节点负责写操作，而后同步到从节点，从节点负责读操作。当主节点挂了，一个从节点被选举晋升为主节点。无主节点，即复制模式：Gossip协定。节点的角色雷同，无主从之分，任何节点都可进行读写。如果一个节点写入数据，会随机同步至n个节点，这n个节点持续随机向n个节点同步，最终集群所有节点状态雷同。几个实践：CAP：分布式系统的个性，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。是NOSQL数据库的基石。 Consistency（一致性）：分布式系统中各节点在同一时刻，同一key的value雷同Availability（可用性）：集群中某一节点挂掉后依然可用Partition tolerance（分区容错性）：集群内如果网络分区，一些节点的数据不会被分区外的客户端拜访到，因而要求数据保留在所有的节点。Base：是Basically Available（根本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性衡量的后果。其核心思想是即便无奈做到强一致性（Strong consistency），但每个利用都能够依据本身的业务特点，采纳适当的形式来使零碎达到最终一致性（Eventual consistency）。 Basically Available(根本可用)：假如零碎，呈现了不可预知的故障，但还是能用，相比拟失常的零碎而言： 响应工夫上的损失：失常状况下的搜索引擎 0.5 秒即返回给用户后果，而根本可用的搜索引擎能够在 1 秒作用返回后果。性能上的损失：在一个电商网站上，失常状况下，用户能够顺利完成每一笔订单，然而到了大促期间，为了爱护购物零碎的稳定性，局部消费者可能会被疏导到一个降级页面。Soft state（软状态）：绝对于原子性而言，要求多个节点的数据正本都是统一的，这是一种 “硬状态”。 软状态指的是：容许零碎中的数据存在中间状态，最终并认为该状态不影响零碎的整体可用性，即容许零碎在多个不同节点的数据正本存在数据延时。如设置key为1，其中在A节点的值已设为1，但在B节点仍为2，但最终会为1.。容许一些节点的值不为1Eventually consistent（最终一致性）：不可能始终是软状态，必须有个工夫期限。在期限过后，该当保障所有正本保持数据一致性。从而达到数据的最终一致性。这个工夫期限取决于网络延时，零碎负载，数据复制方案设计等等因素。零碎可能保障在没有其余新的更新操作的状况下，数据最终肯定可能达到统一的状态，因而所有客户端对系统的数据拜访最终都可能获取到最新的值。Acid：atomic原子性，consistence一致性，isolation隔离性，duration持久性，保障事务的强一致性 分布式系统不会是一个完满的零碎，即数据写入时所有节点会立刻更新最新的数据且始终提供服务，如果零碎内某个节点挂掉，不影响读写操作整个零碎像是一个单体利用，满足acid。因为数据同步到各个节点须要肯定工夫，在客户端收到写入胜利的响应后，所有节点是否实现数据的变更，此时再申请，是否会失去最新数据。如果一个节点挂掉，零碎是否会响应客户端申请。多节点的存在使得它受CAP原理的限度。满足CP：ZK，AP：eureka

「分布式系统之美」知乎圆桌已上线一周， 局部问答引发了网友的热烈探讨，接下来就追随小编一起来盘点大家最关怀的问题吧！ 圆桌精选问答：1. 在什么状况下你须要思考换个数据库了？作者：kylin （伴鱼技术中台负责人） 业务零碎为了取得的良好程度扩大能力，都偏向于将业务服务无状态化，将状态存储到数据库中，这样数据库很多时候都是业务零碎最外围的局部，所以换数据库是一件须要审慎决策事件。 然而，产生换数据库这个念头，是不须要做一个审慎的决定，这还只是一个想法，能够先调研，小范畴试用，我感觉在上面两个状况下，能够动动换数据库的这个念头： 1、数据库技术上呈现重大的改革 一般来说，都是业务推动技术改革，那其实也就阐明了在呈现技术改革的公司，肯定是呈现了新的业务场景用当初的技术不能很好解决，这个新的业务场景可能目前公司还没有碰到，然而很可能在不久的未来会遇到。一个很好的例子，Google 在 2000 年前后碰到大数据的问题，而后推出了 GFS、MapReduce 和 Bigtable 技术创新（其实也不是严格意义上的技术创新）来解决这一问题，在 Google 遇到大数据问题的时候，大部分公司应该还感知不强烈，然而在明天看来，大数据的浪潮又放过了谁？ 所以，在技术呈现重大改革的时候，咱们须要去思考推动技术改革的业务需要是什么，咱们公司的业务当前会有呈现这个业务需要吗？ 如果答案是必定的，那么能够动一动这个念头，先调研，小范畴试用。这其实就是重要不紧急的事件，如果咱们把它变成了重要紧急的事件，这其实就是技术方向把控上的谬误。 对于数据库来说，更是如此，它的业务差异比拟小，个别都是比拟共性的业务需要，所以如果数据库技术呈现重大的改革的时候，先调研，小范畴试用，是凋谢的技术思维，防止将重要不紧急的事件变成重要紧急的事件。 2、业务场景上呈现重大的变动 ... 点击以下链接查看残缺答复 https://www.zhihu.com/question/413947496/answer/1406278473 2. 云数据库时代，将来 DBA 如何给本人升职加薪？作者：笨猫儿 （送外卖的资深互联网 DBA，酷爱 MySQL、分布式数据库） ... 咱们可能看到随着云技术的大规模应用，数据库逐渐走向云原生方向，云厂商承接了数据库的基础设施撑持，企业在逐渐缩减在基础架构的建设上投入。 将来，云厂商在挤压企业外部传统 DBA 的生存空间的同时，也带了新的机会，云厂商不足云上数据库管控平台研发工程师、云数据库的架构师/技术布道师、云厂商的技术售前、云数据库的运维 DBA 等。 DBA 将依靠于云平台从原来服务于一家企业转变为服务云上成千上万家企业，在取得更高的成就感和集体影响力，也能播种更高的职位和薪资 ... 点击以下链接查看残缺答复 https://www.zhihu.com/question/413947284/answer/1406992021 3. 如何系统性的学习分布式系统?作者：kylin （ 伴 鱼技术中台负责人 ） 学习一个常识之前，我感觉比拟好的形式是先了解它的前因后果：即这个常识产生的过程，它解决了什么问题，它是怎么样解决的并且它带来了哪些问题，这样咱们能力比拟好的抓到它的脉络和关键点，不会一开始就迷失在细节中。 所以，咱们要解决的第一个问题是：分布式系统解决了什么问题？ 第一个是单机性能瓶颈导致的老本问题，因为摩尔定律生效，便宜 PC 机性能的瓶颈无奈持续冲破，小型机和大型机能进步更高的单机性能，然而老本太大高，个别的公司很难接受； 第二个是用户量和数据量爆炸性的增大导致的老本问题，进入互联网时代，用户量爆炸性的增大，用户产生的数据量也在爆炸性的增大，然而单个用户或者单条数据的价值其实比软件时代（比方银行用户）的价值是只低不高，所以必须寻找更经济的计划； 第三个是业务高可用的要求，对于互联网的产品来说，都要求 7 * 24 小时提供服务，无奈容忍进行服务等故障，而要提供高可用的服务，惟一的形式就是减少冗余来实现，这样就算单机零碎能够撑持的服务，因为高可用的要求，也会变成一个分布式系统。 基于下面的三个起因能够看出，在互联网时代，单机零碎是无奈解决老本和高可用问题的，然而这两个问题对简直对所有的公司来说都是十分要害的问题，所以，从单机零碎到分布式系统是无奈防止的技术大潮流。 那么，分布式系统是怎么来解决单机零碎面临的老本和高可用问题呢？ 点击以下链接查看残缺答复 https://www.zhihu.com/question/320812569/answer/1386491563 4. 为什么简直所有的开源数据库中间件都是国内公司开源的？并且简直都进行了更新？作者：cx3ptr （ 伴 鱼基础架构负责人 ） ...

Gossip协议

作者介绍：徐嘉埥，Bigo DBA，TUG 华南区大使。Bigo 于 2014 年成立，是一家高速发展的科技公司。Bigo 基于强大的音视频处理技术、全球音视频实时传输技术、人工智能技术、CDN 技术，推出了一系列音视频类社交及内容产品，包括 Bigo Live、Likee、imo、Hello 语音等，在全球已拥有近 4 亿月活用户，产品及服务已覆盖超过 150 个国家和地区。 TiDB 4.0 在 Bigo 的使用情况我们在今年年初开始使用 TiDB 4.0 测试版本，在测试的时候搭建了一个测试环境的集群，它始终会跟随着 TiDB 的最新版本迭代，所以我们前不久也迅速升级到了 4.0 GA 版。 对于 TiDB 在生产环境的上线，我们非常勇敢，也是非常大胆的部署了 2 套生产环境集群，这两个集群规模不算非常大，更多的是偏分析类的业务。一套是网络监控的分析，特点是数据量增长大，且 SQL 偏分析类，同时对响应时间由一定要求；还有一套是做大数据的下游存储，大数据分析后的数据提供线上的实时服务来使用，单表数据量通常也不小，大多是运营类的后台汇总业务。我们使用了 TiUP 进行集群部署，这也是官方相对比较推荐的部署方式，简单来说 TiUP 这个部署的方式比之前的 TiDB Ansible 好很多，解决了我们一大部分的问题。 另外，我们使用 TiDB 4.0 更多的组件和功能，包括 Pump、TiFlash 等等。由于 Bigo 的业务覆盖全球，所以我们希望在全球各个大洲（或者说各个大区）都能够部署上自己的服务，而服务的跨大洲延迟，对于一部分业务来说是不可接受的，因此我们会通过 Pump 之类同步的方式，来进行各洲之间的数据同步。关于 TiFlash，稍后我会花更多篇幅分享实践经验，熟悉我的 TiDB 社区伙伴们应该都知道，我总在各个场合夸“TiFlash 是真的香”。 我们为什么会使用 TiDB 4.0？一方面业务上有新的需求，通常作为 DBA 我们会尽量去满足业务的需求。 比如 TiDB 4.0 支持通过字符集排序规则来控制大小写是否敏感，在此之前我们是没有办法控制的，所以说经常有业务同学向我们吐槽说你们 TiDB 的服务部署了之后，字符级的排序就跟“假”的一样，当然确实之前好像也是假的，因为没有办法控制。 ...