自定义博客皮肤VIP专享

*博客头图:

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

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

博客底图:

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

栏目图:

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

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

走在前往架构师的路上

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

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

原创 HDFS精华文章汇总

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

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

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

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

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

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

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

2014-11-08 10:16:37 20744 8

原创 HDFS Multiple Standby原理分析

文章目录前言HDFS Multiple Standby的实现要素Multiple Standby实现分析前言HDFS在早期实现HA时,是标准的一主一备的服务模式,主的叫Active NameNode,备的叫Standby NameNode。Standby/Active NN间可以互相切换以此达到服务高可用的目的。但是这种双节点的HA模式是否能够满足更高的高可用性的要求呢?在标准的HA模式下,其实只有1个Standby的NN作为bak来使用。假设在极端情况下,Active和Stanby同时出现crash

2021-05-05 14:23:45 20 1

原创 Ozone Upgrade模型框架分析

文章目录前言Ozone Upgrade相关要素关系Ozone Upgrade的过程执行前言最近Ozone社区刚刚发布了Ozone 1.1版本,这也是Ozone发布GA版本以来的第二个版本release了。当越来越多Ozone版本release后,这里就会有个版本升级的问题。可能有同学会好奇:目前Ozone支持版本Upgrade功能吗?据社区目前的进展,这个功能第一阶段实现已经基本完成,预计会在Ozone 1.2版本中和大家见面。在Ozone第一阶段Upgrade功能的实现里,一个基本的Upgrade框

2021-04-26 23:14:02 26

原创 Hadoop RPC Client工作原理分析

文章目录前言Hadoop Client的内部结构组成ClientId和CallIdClient Connection和Connection Call的组织关系Client RPC Call的处理流程相关链接前言对于Hadoop内的RPC处理(比如NameNode里的RPC请求处理),我们往往关注的是实际Server端的RPC处理,但是很少提起对应Client端的行为。Hadoop内部有自己专有的RPC Client实现,本文我们就来说说这个底层RPC Client是如何工作的。这有助于方便了解底层RP

2021-04-17 11:52:44 97

原创 HDFS RBF部署生产环境的难点和挑战

文章目录前言一. Router层面的潜在问题Router的性能测试,对请求延时的影响Router间如何做到本地状态的一致性Router对下游NN的统筹管理前言上篇文章笔者简单介绍了HDFS Federation新方案RBF里的connection管理。RBF虽说在功能上只是帮助client做请求转发的,在角色功能定位上相当于一个代理的角色。但RBF的这个“代理”远比我们平常说的代理服务要复杂许多。RBF的核心服务Router在设计实现上被赋予了远比普通代理服务更为全面,成熟的功能。因此集群维护者需要对

2021-03-27 11:19:22 377

原创 HDFS RBF的Connection管理

文章目录前言Connection管理的权衡问题RBF的Connection管理前言为了解决HDFS Federation下多集群的维护管理,Hadoop社区实现了Router-Based Federation(HDFS-10467)功能。此功能的强大之处在于它在client和集群NN服务之间新加了一层Router的服务。有了这个Router这个服务后,所有客户端的请求将会由这个Router负责转发给下游的NN节点。这样的话,客户端用户就不需要知道下游有哪些NN节点以及各个NN Namespace里分布

2021-03-16 00:22:25 10863 17

原创 Hadoop Security三板斧

文章目录前言Hadoop Security要解决的问题Hadoop Security三板斧参考资料前言在企业大规模量级的Hadoop集群中,数据的安全性是十分重要的,尤其当集群存储的是一些敏感数据的时候。Hadoop社区在早期release的版本中,并没有完善好其Security部分的功能。但是随着Hadoop系统的不断完善成熟,Security的功能也在不断的完善。那么问题来了,Hadoop的Security到底指的是什么呢?本文笔者来简单聊聊Hadoop Security的三板斧,了解了这三板斧的

2021-03-08 17:36:58 933

原创 Hadoop升级前需要考虑的一些事情

文章目录前言Hadoop升级的目标版本的选择Hadoop升级过程需要做的准备工作前言现今Hadoop版本已经release到了Hadoop 3.x版本了,社区迭代更新的速度还是很快的。新的版本相对旧版本来说,能够给我们带来很多益处,诸如新的功能feature,众多bug fix以及一些大的performance的改进。始终维护运行一个陈旧的系统,意味着后期可能会遇到许多许多社区已fix的bug,这个将会消耗掉系统管理员日常相当多的工作时间。尤其当我们维护的是一个具有庞大规模的分布式系统。所以对于复杂系

2021-02-27 18:07:50 914 1

原创 Ozone S3 Gateway:S3方式的适配存储

文章目录前言相关背景Ozone的S3方式的存储实现分析Ozone S3的Multipart Upload功能分析参考链接前言Ozone作为对象存储系统而言,在对于用户使用的方式上,我们难免会想到另外一个已经在业界十分成熟的对象存储系统:S3存储。不过本文笔者并不想比较二者系统孰优孰劣,从用户角度出发,在用户已经使用S3接口方式做对象存储时,我们是否有方式能够透明的将底层存储移到Ozone上。换言之来说,Ozone是否能够做到兼容S3接口方式的对象存储,这样客户端就不需要做大的改动了。Ozone在早期r

2021-02-15 18:01:01 731

原创 Ozone SCM HA模式下的请求处理过程

文章目录前言SCM HA和OM HA的区别SCM HA基于InvocationHandler的请求处理SCM HA请求处理过程图参考链接前言在前面的文章中,笔者阐述过关于Ozone SCM HA的设计原理,目前这个功能社区还没有完全做完,但是大部分的主要功能已经完善。本文笔者来简单聊聊SCM HA模式下的请求处理过程,它和早期实现的Ozone OM HA的实现略有不同(OM HA实现原理可参考此文:Ozone OM服务HA原理分析)。Ozone在已有OM HA下,再实现SCM HA后,Ozone系统整

2021-02-13 12:07:45 273 1

原创 HDFS Standby NameNode Read功能剖析

文章目录前言HDFS Standby Read的背景及功能要求Standby NameNode一致性读的控制实现原理分析代码分析流程分析图参考链接前言HDFS有着一套十分成熟的HA的机制来保证其服务的高可用性。在HA模式下,分别对应有Active和Standby NameNode的服务。Active NameNode用于提供对外数据服务,而Standby NameNode则负责做checkpoint的工作以及随时准备接替变成Active NameNode的角色,假设说当前Active NameNode

2021-02-06 20:33:56 183

原创 一次HDFS Snapshot无法删除的问题排查

文章目录前言背景问题Snapshot的清理Snapshot NPE异常代码层面的分析线下Snapshot问题恢复失败HDFS内部代码改动的重新梳理分析setTimes忽略snapshot diff更新的改动总结参考资料前言众所周知,HDFS有一个十分有用的Snapshot的功能,可以用来保护数据被误删除的情况。可能有人会说了,数据被删除了,我难道不可以从trash目录里把数据再恢复回去吗?HDFS的Snapshot和我们平常说的数据删除进trash目录不太一样,HDFS删除操作进trash目录是一个延

2021-01-30 21:49:28 119

原创 一次HDFS JN lag延时问题的排查分析后续:RM陡增traffic的来源分析

前言在上篇文章(一次HDFS JournalNode transaction lag问题分析排查)中,笔者详细地讲述了一次HDFS JN lag延时问题的分析排查,在文中结尾笔者提到了问题的root cause是因为部署在JN同节点上的RM traffic陡增造成的JN lag影响。不过笔者当时只是发现了与RM traffic陡增的可能因素,并未进一步分析这些增加的RM traffic的真正来源。在后续的时间里,我们对这些RM traffic的组成部分以及为什么做了更加进一步的分析,最终真正找到了问题的

2021-01-25 19:02:45 147

原创 一次HDFS JournalNode transaction lag问题分析排查

文章目录前言背景问题追踪排查分析排查一:JN服务本身问题排查二:NN 服务问题排查三:JN机器硬件层面问题推论四:JN受所在机器其它服务的影响总结前言众所周知,在HDFS集群中,NameNode服务是其中的核心服务。NameNode的性能处理效率的高低直接影响着其对外提供的服务能力。鉴于过往笔者已经写过诸多NameNode优化系列的文章,本文笔者来聊聊另外与NameNode相关的服务JournalNode(简称JN)服务。JournalNode是在HDFS HA模式下用来做共享editlog的存储的。

2021-01-17 16:37:36 4649 6

原创 Alluxio的Raft HA实现

文章目录前言基于Raft实现的要点Alluxio Raft HA实现的相关角色类前言Alluxio在HA的实现上,早期实现的方式是基于ZK(用来做领导选举)+shared journal storage(状态同步)的方式来达到其服务高可用性的。这种方式和HDFS目前的HA实现十分类似,不过后来Alluxio社区实现了基于Raft协议的新的HA实现方式,Raft实现库依赖了Raft Java实现库Apache Ratis。作为全新的HA实现,本文笔者结合Alluxio相关代码来简单聊聊里面的一些实现细节

2020-12-30 12:39:51 662 1

原创 Ozone Streaming方式的写优化

文章目录前言Ozone Streaming的背景Ratis Streaming前言在Ozone目前数据写出的过程,是基于从对象文件的block,再从block到chunk粒度进行数据的写出的。每次Ozone写完一个chunk后,对应着会触发一次write chunk的RPC call。当我们写入的数据文件对象很大的时候,过程中将会涉及到很多次write chunk PRC的操作调用。这个RPC call的频繁调用意味着相应更多的transaction的发生。对于Ozone Datanode里使用Raf

2020-12-24 23:52:37 1644 5

原创 HDFS NameNode fsimage文件corrupt了,怎么办

文章目录前言NameNode fsimage corrupt场景NameNode fsimage corrupt解决办法NN fsimage corrupt的重新行为参考链接前言在如今很多用户使用HDFS做为大数据的底层存储时,我们除了关心HDFS的处理性能外,我们经常还需要关注其中数据高可用的情况,例如不能出现数据损坏的情况,比如missing block,或者文件block corrupt的情况。但是其中我们忽略掉了一种最为极端同时也是最为棘手的情况:HDFS NameNode fsimage文件

2020-12-19 23:06:18 767 1

原创 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 259

原创 Ozone ReplicationManager工作原理

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

2020-11-18 00:30:10 298

原创 Ozone Decommission原理过程

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

2020-11-15 23:21:23 123

原创 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 150

原创 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 400

原创 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 248

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

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

2020-09-26 16:59:27 545

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

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

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

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

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

2020-08-29 20:45:42 2594 8

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

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

2020-08-19 23:57:23 532

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

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

2020-08-11 23:44:42 1529

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

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

2020-08-08 17:11:39 581

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

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

2020-08-02 17:40:30 440

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

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

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

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

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

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

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

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

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

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

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

2020-07-02 23:48:25 548 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 857

原创 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 528

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

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

2020-06-13 11:04:49 953

原创 基于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 586 1

空空如也

Android路上的人的留言板

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

空空如也

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

TA关注的人 TA的粉丝

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