自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

走在前往架构师的路上

专注于分布式计算,大数据,数据挖掘,机器学习算法等领域的研究

  • 博客(426)
  • 论坛 (1)
  • 收藏
  • 关注

原创 HDFS精华文章汇总

前言自2015年下半年起,笔者开始写关于Hadoop的文章(主要集中在HDFS),包括源码分析类的,问题分析解决又或者是内部机制剖析。这些文章目前汇总数量已经达到70+篇。这些文章对于笔者来说是一个宝贵的资料,这些文章见证了笔者从一名Hadoop贡献者成长为Hadoop Committer的过程。同样笔者相信,这些文章对于那些对HDFS感兴趣的人同样是很好的学习资料。因此,笔者觉得是时候写一篇文章来

2017-12-03 11:45:14 5198 2

原创 18大经典数据挖掘算法小结

本文所有涉及到的数据挖掘代码的都放在了我的github上了:https://github.com/linyiqun/DataMiningAlgorithm大概花了将近2个月的时间,自己把18大数据挖掘的经典算法进行了学习并且进行了代码实现,涉及到了决策分类,聚类,链接挖掘,关联挖掘,模式挖掘等等方面。也算是对数据挖掘领域的小小入门了吧。下面就做个小小的总结,后面都是我自己相应算法的博文链接,希

2015-02-27 10:04:01 17608 17

原创 Redis源码分析(三十六)--- Redis中的11大优秀设计

坚持了一个月左右的时间,从最开始的对Redis的代码做分类,从struct结构体分析开始,到最后分析main主程序结束,中间,各大模块的代码逐个击破,学习,总之,收获了非常多,好久没有这么久的耐心把一个框架学透,学习一个框架,会用那只是小小的一部分,能把背后的原理吃透才是真功夫。在这个学习的最后阶段,是时候要来点干货了,我把这1个多月来的一些总结的一些比较好的代码,和设计思想总结出来了,原本想凑成

2014-11-08 10:16:37 20075 6

原创 Ozone OM Upgrade期间请求一致性处理的保证

前言之前笔者讲过一篇关于Ozone Upgrade相关的文章(HDFS数据In-place Upgrade到Ozone的原型方案),本文笔者继续围绕Ozone Upgrade这个主题,聊聊在Ozone Upgrade时,OM新旧版本之间,它是如何做到元数据的一致性的。倘若是Upgrade后的版本意为地执行了老版本留下的请求,亦或是老版本执行了新版本下发来的请求,这些都不是预期应该发生的情况。Ozone社区对这块的逻辑做了详细的设计。本文我们来聊聊这块的内容。Ozone OM Upgrade的预期目标

2020-11-29 13:02:48 10

原创 Ozone ReplicationManager工作原理

前言在中心化管理的存储系统中,当系统内的数据出现个别副本损坏的情况时,作为中心控制中心,它需要能够感知系统内的这个情况,并且能够快速的进行副本的拷贝恢复。我们姑且称此类服务为ReplicationManager,或者叫做类似于ReplicationMonitor的服务。此类服务在分布式存储系统中扮演的功能为定期检查系统内所有数据的副本情况,并进行必要的修复工作或者其它类似操作。本文笔者来聊聊Ozone系统中的这个服务,名称就叫做ReplicationManager。Ozone ReplicationM

2020-11-18 00:30:10 21

原创 Ozone Decommission原理过程

前言在大规模的分布式集群节点中,出现机器损坏的现象是十分常见的。但是为了保证数据的高可用性,系统在设计上往往采用多副本的形式来达到冗余的效果。对于那些“损坏”了的机器,正常的逻辑是要总正常下线过程,即decommission流程。Decommission最为核心的一点是,它要保证节点内的数据完好无恙的复制到其它健康的节点上,然后最后将此节点标记为Decommissioned状态,随后就可以从集群中移除了。Decommission过程能够减小因为坏节点下线对于集群产生的不利影响。在我们所熟知的HDFS里面

2020-11-15 23:21:23 22

原创 Ozone基于Block level的EC方案设计

文章目录前言Ozone EC概述Ozone Container Group以及CGI前言在之前文章中,笔者写过一篇关于Ozone EC方案设计的文章(Ozone的Erasure Coding方案设计),不过当时那篇文章讨论的EC设计方案主要在Container级别以及Block级别做EC实现的方案对比,社区并没有敲定选用哪种最终的具体方案设计。最近社区更新了Ozone EC最新的设计方案,在Block级别做最终的实现方式,本文笔者聊聊此方案的实现细节。Ozone EC概述说到EC以及Ozone的

2020-11-05 22:41:18 41

原创 Ozone的S3语义和FS语义

文章目录前言Ozone的S3语义和FS语义Ozone S3语义和FS语义的联合使用引用前言在Ozone中,众所周知,它最开始设计仿照的原型即是S3语义的存储模式:基于volume, bucket, key三层的存储模型,底层的key是实际存储的对象文件。至于里面对于volume, bucket, key级别的API操作,基本也是实现了S3现有支持的API操作。不过Ozone作为同样Hadoop生态圈内的一个项目,它需要与现有别的系统框架能够很好地协调工作。因此,Ozone内部实现了Ozone FS的语

2020-10-12 00:10:11 232

原创 Ozone FS namespace下的全新metadata结构分析

文章目录前言OzoneFileSystem的不足之处Ozone FS namespace的metadata结构Ozone FS基于Dir cache的高效查找引用前言Ozone作为又一个全新的存储系统,它在底层存储结构上和HDFS有着不小的区别,用户往Ozone内读写数据的方式也有所不同。不过为了兼容目前Hadoop FileSystem的读写,Ozone实现了一个叫做OzoneFileSystem的功能。通过使用OzoneFileSystem,用户能够使用往常Hadoop FileSystem的通用

2020-10-04 22:08:25 91

原创 HDFS/Ozone对于存储策略的抽象化提取

文章目录前言存储类别(策略)抽象提炼的意义HDFS的Storage PolicyOzone的Storage Class定义引用前言Ozone作为正在快速迭代开发中的存储系统,相比于HDFS来说,其内部能支持更大规模量级的文件对象存储。不过作为存储系统来说,它同样面临一些数据如何来存储的问题,比如数据存几副本备份,数据replication的策略是什么,数据存储的载体介质是什么等等。本文我们来聊聊Ozone对于这块内容的抽象设计。为什么笔者提到的是抽象设计呢,因为这个功能设计还处在社区讨论中,还未开发完

2020-09-26 16:59:27 414

原创 HDFS千万级别文件数/PB规模量级的数据迁移实战总结

文章目录前言HDFS元数据快速膨胀带来的性能瓶颈问题超大规模数据迁移所面临的挑战和困难DistCp的全面优化提升前言前面时间笔者曾写过一篇关于利用HDFS fastcopy功能来加速DistCp数据拷贝效率的文章(Distcp结合HDFS Fastcopy的性能改造提升),以及提到了现有DistCp在数据切分时候的一些问题(聊聊Hadoop DistCp的数据切分处理方式),会导致长尾任务的出现等等。其实在后续的测试过程中,我们还发现并解决了许多大大小小的坑,使得我们整体数据拷贝的耗时达到一个相对短的

2020-09-13 16:00:36 8461 1

原创 聊聊Hadoop DistCp的数据切分处理方式

文章目录前言基于文件数/文件Size的数据切分方式前言在如今数据使用场景越来越多的环境下,如何对数据做到更准确,更高效的处理无疑是我们开发者所重点关注以及所期望达成的目标。说到数据的处理,在当今成熟的分布式系统下,我们已经能够达到比较高效的数据并行处理能力了。但是这并不意味着说对此我们没有别的改善空间的余地了。在数据的并行处理过程中,不是所有情况我们都能保证每个并行处理任务都能按照预期顺利执行,中间就可能出现长尾任务现象。这里笔者想抛出的一个关键词:数据切分。在数据切分不均匀的情况下,是极有可能出现任

2020-08-29 20:45:42 2242 7

原创 Distcp结合HDFS Fastcopy的性能改造提升

文章目录前言HDFS的fastcopyDistcp工具支持fastcopy的改造前言在HDFS中,我们经常会碰到跨集群数据拷贝的场景,例如某些任务数据结果计算生成,然后问你启动任务把结果数据导出到另外一个集群中以作后续的分析等这样的用途。Hadoop作为一套成熟完善的系统,也为我们提供了专门的拷贝工具,Distcp,全称Distributed copy,意为分布式的拷贝。说到Distcp工具本身,很多同学估计不会陌生,不过本文笔者来聊聊Distcp基于HDFS fastcopy原理下的性能提升改造。在

2020-08-19 23:57:23 337

原创 Alluxio与底层存储系统之间的元数据同步机制

文章目录前言Alluxio内部的元数据同步行为基于给定时间,Path粒度的UFS Status Cache前言Alluxio作为一套构建于底层存储系统之上的中间层,它必不可少的会涉及到于底层系统之间metadata之间的同步问题。外部client请求访问Alluxio系统,然后Alluxio再从底层系统中(为称呼方便,后面都简称为Underlying FileSystem, UFS)查询真实的元数据信息,然后再返回给client。当然为了减少对于UFS的压力,我们当然不会每次都去查UFS。本文我们来聊

2020-08-11 23:44:42 1200

原创 Hadoop服务配置热替换框架的设计实现

文章目录前言服务热替换更新需要解决的问题点前言在分布式系统中,根据不同的运行情况进行服务配置项的更新修改,重启是一件司空见惯的事情了。但是如果说需要重启的服务所需要的cost非常高的时候,配置更新可能就不能做出频繁非常高的操作行为了。比如某些分布式存储系统比如HDFS NameNode重启一次,要load元数据这样的过程,要花费小时级别的启动时间,当其内部存储了亿级别量级的文件数的时候。那很显然对于这种高cost重启的服务来说,我们不能每次依赖重启做快速的配置更新,使得系统服务能使用新的配置值进行服务

2020-08-08 17:11:39 466

原创 Scheme覆盖式的ViewFileSystem设计实现

文章目录前言Scheme覆盖式的ViewFileSystemViewFileSystemOverloadScheme的实现引用前言在多HDFS集群模式中,我们为了使得多集群对于client端的透明使用,一般可以采用的是ViewFs的方案。当然后来社区实现的HDFS RBF功能无疑是更佳的选择,但是在RBF出现,ViewFs实现的更早且方案更为简单,因此ViewFs是通过在client端实现的一个请求解析以及转发。但是本文我们来讨论一个ViewFs使用的痛点问题:ViewFs高成本的配置更新问题以及更为t

2020-08-02 17:40:30 332

原创 关于小概率锁碰撞的细粒度锁方案

文章目录前言锁的细粒度级别基于小概率锁碰撞的lock pool实现方案前言在分布式系统中,我们常常使用锁来保证操作的一致性控制。但是锁的存在则意味着必然存在着锁竞争的情况。而且这种竞争会随着外部请求量的激增而变得更为的激烈。因此我们改进的一个方向是改变锁的粗细力度,从较为简单的粗粒度锁变为更细粒度的锁。细粒度锁相较于粗粒度锁来说,毫无疑问,它能减缓激烈的锁竞争的情情况,但是它在实现上会增加额外的复杂度。这个很好理解,在server端原先只需要维护一把锁就行了,现在则要可能维护一定规模量的小锁。本文笔者

2020-07-23 00:11:24 497 1

原创 记录一次HDFS RPC返回Response过程慢导致的性能问题

文章目录前言NameNode请求处理慢的场景RPC返回response的Handler处理慢问题HDFS RPC call异步response改造前言众所周知,在HDFS NameNode中,一直都有一个老生常谈的难题就是其扩展性的问题,而很多时候我们说HDFS的扩展性问题时我们很多时候都在谈的点在于里面全局锁的问题。一个很通常的场景是NameNode在高并发请求处理下存在着激烈的锁竞争,进而使得用户感觉到他们的请求被处理的有点慢。不过本文笔者不聊关于全局锁优化的问题,最近笔者遇到了另外一种NameN

2020-07-18 11:21:24 955 1

原创 Alluxio基于冷热数据分离的元数据管理策略

文章目录前言Alluxio内部元数据管理架构Alluxio的支持异步写出功能的自定义Cache实现前言上篇文章末尾,笔者聊到了一种叫做分层元数据管理模式。它主张的思想是将元数据进行分级对待,比如Cache+Persist层2种,cache拿来用于热点数据的访问,而persist层即持久层则存储那些冷的访问不频繁的数据,以此达到元数据的强扩展性和一个较好的访问性能。当今存储系统Alluxio就是使用了这种分层级对待的元数据管理模式。本文我们就来简单聊聊Alluxio的tier layer的元数据管理。

2020-07-05 15:10:25 993 1

原创 存储系统元数据管理演变升级

文章目录前言初代元数据管理内存式元数据管理分区元数据管理分层级元数据管理引用前言我们知道在一个存储系统中,不光光只有它所存储的数据文件重要,它的存储系统的元数据管理同样十分的重要。因为涉及到存储系统数据访问操作时,会经过存储系统元数据的查询或更新操作,如果元数据这边的操作出现性能瓶颈,同样会导致用户访问数据的行为出现缓慢的情况。本文我们来聊聊存储系统一般是如何做高效的元数据管理的,这里面会涉及到多种不同的元数据管理方式。初代元数据管理首先我们来看最简单原始的初代存储系统元数据管理方式,此时元数据

2020-07-02 23:48:25 449 1

原创 HDFS Rolling Upgrade的实现要点分析

文章目录前言HDFS NameNode端针对Rolling Upgrade的调整HDFS DataNode端针对Rolling Upgrade的调整引用前言我们知道HDFS Rolling Upgrade功能在几年前比较早的时间早已实现,但是我们往往只注意怎么去做HDFS Rolling Upgrade这个事情本身,但是对于HDFS如何实现Rolling Upgrade这个功能可能了解的会比较少。本文笔者来聊聊其中部分要点的设计实现,为了做到Rolling Upgrade的快速和安全性,社区在这块实现

2020-06-28 17:31:02 718

原创 Ozone的Erasure Coding方案设计

文章目录前言EC技术以及EC下的存储效率的提升Ozone下的EC方案设计Container Level的EC实现Block Level的EC实现引用前言众所周知,在当下存储系统中为了存储效率的提升,Erasure Coding(纠删码)技术在扮演着一个越来越重要的角色。比如说目前Hadoop HDFS中,它就已经能够支持EC功能了。在EC模式下,HDFS 可以不必存储多打3份这样的冗余副本数来为了容灾保护。存储效率的提高意味着存储海量数据所需要的存储节点资源的减少。不过本文并不是聊HDFS的EC实现的

2020-06-25 16:10:45 398

原创 关于分布式系统升级,你需要了解的几点

文章目录前言分布式系统升级的状态转化关于Upgrade需要注意的点关于Downgrade需要注意的点引用前言对于一个系统来说,进行定期的升级维护是一件比较常见的事情。但是对于复杂分布式系统的升级,系统管理员系统考虑更多的因素来做升级这个事情。同时对于分布式系统开发者来说,他们也要考虑系统升级的前后兼容性,避免升级后部分老的功能无法使用或是升级回退后之前写出的数据无法使用等等类似的情况。本文笔者来简单聊聊关于分布式系统的升级,你需要了解和注意的那些事。分布式系统升级的状态转化在介绍本文主要内容前,

2020-06-13 11:04:49 730

原创 基于RPC Call延时返回的HDFS异步editlog原理

文章目录前言现有HDFS的RPC正常请求处理前言前面文章笔者介绍过Hadoop社区为了增加内部RPC的throughput,通过延时返回response的调整来提早释放Server端的Handler资源,以此尽可能的把Handler的处理能力用在真正的RPC请求上。HDFS目前所使用的异步editlog机制正是使用了这个优化改进。这里所说的HDFS异步editlog写出并不是大家所简单的认为NameNode完全异步化写出editlog到其JournalNode服务中,然后直接返回结果给client。那

2020-06-04 23:43:07 436

原创 HDFS和Ozone的数据删除原理对比思考

文章目录前言现有HDFS删除操作的性能问题HDFS删除操作的brainstorm改进想法相关设计:Ozone系统内的删除操作处理前言前段时间笔者一直在折腾HDFS大目录删除的性能问题,也尝试了很多不同的方案来降低大目录删除所带来的性能影响,包括改INodeDirectly内部child list结构,或者是在Snapshot层面做改进优化等等(详见此文章:HDFS大目录文件删除方案的实践思考)。不过后续笔者在对比HDFS的删除操作和新一代存储Ozone系统内部的删除操作时,发现二者还是存在不少区别的,

2020-05-31 17:17:59 423

原创 提高RPC Server throughput的请求延时回复处理

文章目录前言前言在一套完整的分布式系统中,client端向server端发起一个请求,然后client等待此请求被server端处理完毕,然后接受到serve的返回结果。自此一个请求就算作是被处理完了。这种block等待处理结果的请求处理行为在我们日常的系统中十分的常见。但是这种处理方式的一个明显弊端是,未处理完成的请求势必会占住server端的处理资源。因此一般常见的改进做法是提高server端的Handler数量,来提高服务端的请求并发处理能力,这种做法是比较简单直接的。但其实这里还有另外一个方向

2020-05-24 23:40:18 373

原创 分布式系统内部RetryCache机制

前言在分布式系统的运行过程中,出现网络不稳定(例如网络超时)导致的client请求回复超时是时有发生的事。在这种低概率发生的情况下时,client端其实是无法感知它的请求是不是真正的被处理了,它只能是基于坏的情况(即请求没被server处理的情况),然后执行重试操作。问题就出现在这里,对于某些非幂的操作而言,操作重试是会返回不同的结果的。这个时候,其实server端不应该执行client端发起的第二次请求的,假设server已经成功处理了client的第一次请求。本文我们就来聊聊针对非幂等操作处理的Re

2020-05-17 10:28:15 472

原创 HDFS federation集群间的数据Balance工具方案

文章目录前言粗粒度的federation Balance方案系统化的federation Balance工具方案引用前言在目前单一大HDFS集群越来越无法支撑我们的业务场景时,越来越多的公司开始考虑采用HDFS federation方案来做。这里就自然会衍生出一个问题:新federation出来的Namespace,我如何将数据从原集群(NameNode)同步出来呢?而且在这个过程中,还会有每天增量数据的写入在老集群内。假若只是静态的数据,我们启动一个distcp任务就可以做这部分跨namespace

2020-05-09 11:49:24 421

原创 Hadoop ViewFs的多Replication模式:Nfly link模式

文章目录前言Nfly link模式的由来前言在多集群模式下,为了保证数据的一定冗余性要求,我们有时会跨集群或跨data center去备份一些重要的数据。这样可以避免某天一旦一个cluster或者data center处于不可用状态时,从而影响集群正常的数据服务。如果在不额外实现此功能代码的情况下,我们可以采用简单直接的Distcp工具来做集群间的数据拷贝。不过这种方式无法做到实时的数据re...

2020-05-04 15:46:12 311

原创 Hadoop ViewFs允许hdfs schema的重载

文章目录前言Hadoop ViewFs的问题痛点Hadoop ViewFs的重载hdfs schema方式ViewFs的mount point中心化管理问题引用前言在大数据时代,随着业务的迅速扩张,很多大公司往往内部会有多cluster模式来支撑其内部的数据体量。在这期间就会涉及到一个多集群管理协调的问题,比如典型的HDFS的多集群管理。社区在早期实现的ViewFs以及后来的Router-b...

2020-05-03 11:53:07 287

原创 Apache Ratis中的multi-raft实现原理

文章目录前言Single-Raft模式Multi-raft改进引用前言在之前笔者写过一篇关于Ozone利用Apache Ratis multi-raft功能来提升其系统的throughput的文章(Ozone Multi-Raft机制对于更大throughput处理量的支持),不过那篇博文只是简单介绍了下在multi-raft的支持下,一个Ozone Datanode节点可以允许成为多个Pi...

2020-05-01 12:02:53 721

原创 HDFS大目录文件删除方案的实践思考

文章目录前言HDFS的大目录删除行为HDFS大目录删除实现方案思考引用前言前面几篇文章笔者讲述了2篇关于文件目录删除的相关文章,也提到了一些相对应的解决方案和思路。不过笔者本文想再谈谈对于这个问题的一些思考,主要关注在HDFS下大目录的删除性能影响方面。不敢说是谈论的是HDFS大目录删除的最佳实践方案,但是在某些点上,在实际环境中还是有一定的可应用性的。本文部分内容会引入笔者前段时间写的两篇...

2020-04-26 23:34:07 333

原创 Ozone SCM HA设计浅谈

文章目录前言SCM HA相较于OM HA的区别点SCM HA服务内存状态数据一致性的控制Follower SCM内部管理服务的“失效”处理SCM HA failover行为处理SCM HA的整体架构图引用前言在前面的文章中,笔者写过关于Ozone OM HA实现的相关文章(Ozone OM服务HA原理分析),里面谈论了目前OM HA的一些实现细节以及OM HA如何搭建这类的说明性文章。但是一...

2020-04-21 23:17:31 519

原创 文件系统大目录下的操作性能效率提升

文章目录前言现有HDFS大目录文件操作效率基于哈希分区的多List目录存储结构HashedArrayList的element的索引查找HashedArrayList的代码实现HashedArrayList性能测试引用前言在文件系统的存储中,我们一般不建议是一个目录下存放过多的文件或子目录。因为这会造成后续在此目录下文件或子目录的操作效率。我们宁愿用分散存储的方式,也比用集中在一个目录下的方式...

2020-04-11 18:08:21 853

原创 一个SkipList简单跳表的实现

文章目录前言SkipList样例结构SkipList样例代码简单实现前言上一篇文章笔者写了关于HDFS使用SkipList跳表的结构来加速Snapshot的diff比较过程,然后加速HDFS大Snapshot删除的过程(此部分文章可阅读上篇博文:聊聊HDFS删除Snapshot行为导致的NameNode crash)。本文笔者想继续聊聊这个跳表结构,简单说就是构造多链表层级结构,利用(数据存...

2020-04-04 11:44:15 252

原创 聊聊HDFS删除Snapshot行为导致的NameNode crash

文章目录前言HDFS的Snapshot以及delete Snapshot行为基于SkipList的Snapshot diff预先合并引用前言关于HDFS的快照,使用过的同学对于这个功能还是持正面评价居多的吧。这个特性所能带给我们最大的好处就是防止用户误删数据导致数据丢失的问题了。从数据保护层面而言,HDFS Snapshot确实起到了十分关键的作用。但是话虽然是这么说,那么如果我们想确保集群...

2020-04-01 22:45:16 342

原创 Ozone基于Resource的细粒度化锁管理器实现

文章目录前言全局锁的细粒度拆分化Ozone内部基于Resource的锁管理器模型Ozone内部锁管理器实现前言众所周知在HDFS中,为了保证元数据更新的一致性,它所使用的是全局锁的模式。不过这在一定模式下会导致激烈的锁竞争的情况发生,尤其当集群规模日趋膨胀的时候,获取锁的这种代价就会变得越来越高。如果在不降低集群请求吞吐量的情况下,我们如何优化这一点呢?一种很自然的想法是将锁的粒度变细,锁粒...

2020-03-23 22:37:26 338

原创 Ozone Block Chunk文件的layout方式

文章目录前言Ozone Datanode Chunk文件原有layoutOzone Datanode Chunk Layout:FILE_PER_CHUNK和FILE_PER_BLOCK引用前言在Ozone中,Ozone的文件对象数据是以Block的形式进行组织的,和HDFS想类似。不过Ozone对Block进行实际存储的时候,是以更细粒度的chunk文件的形式进行物理存储的。简单来说,Bl...

2020-03-15 13:29:38 367

原创 增量capacity分配的ByteBuffer实现

文章目录前言Ozone内部的增量ByteBuffer实现引用前言对于Java nio ByteBuffer,我们常常会拿来做缓冲数据的处理。如果我们就为了图方便,每次数据读写操作专门allocate一个比较大capacity的ByteBuffer,这样会造成不必要的JVM heap的浪费。但是如果我们转而变为多个小ByteBuffer的动态申请,又会加大ByteBuffer的管理协调 操作。...

2020-03-11 23:36:24 340

原创 Ozone BlockCommitSequenceId在Container上的运用

文章目录前言Ozone Container自增型TransactionId:BlockCommitSequenceId前言在Ozone中,Container以Pipeline节点组织的方式通过StateMachine的形式进行状态一致性的更新。不过这里面对可能存在的一些边缘情况,例如Pipeline节点的突然重启,Container目录的意外删除,我们需要有别的手段来表明Container当...

2020-03-08 23:31:22 286

空空如也

Android路上的人的留言板

发表于 2020-01-02 最后回复 2020-02-18

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人 TA的粉丝

提示
确定要删除当前文章?
取消 删除