文章目录Hadoop1.:elephant:Hadoop集群配置2.集群崩溃处理方案3.配置历史服务器4.配置日志聚集功能2.HDFS的Shell相关操作（开发）1.基础命令2.HDFS的API参数优先级3.JavaAPI操作HDFS编程 Hadoop#基本命令
scp基本语法：
发送：scp -r 要拷贝的文件 用户@主机:路径/
拖过来：scp -r 用户@主机名:路径(文件名) 拖哪里
转载
2023-07-24 09:09:54
98阅读
一、背景：我们都知道，RPC本质是一个代理模式，是在HTTP或HTTPS请求上面做的封装，那么别人封装好了，拿过来用就好了。这样带来了极大的遍历，但也就导致了另外的问题，有的时候就是不够灵活。在python项目X山中，有的地方用了xmlrpc.client , 但又缺少超时机制。二、分析直接上代码了import xmlrpc.client
url = 'http://{}:{}'.format(
转载
2024-05-16 22:28:44
254阅读
为什么要采用异步？影响到性能和吞吐量的根本原因是什么呢？ 其实就是RPC请求的整体耗时，如果采用同步调用， CPU 大部分的时间都在等待而没有去计算，从而导致 CPU 的利用率不够。这就好比工地里面搬砖，砌墙，捣水泥都由一个人干，其他人旁观， 那效率就十分低下。RPC 请求比较耗时的原因主要是在哪里？在大多数情况下，RPC 本身处理请求的效率是在毫秒级的。RPC 请求的耗时大部分都是业务耗时，比如
转载
2024-10-13 19:24:26
94阅读
上面这张监控图，对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中，『服务超时』应该属于监控报警最多的一类问题。 尤其在微服务架构下，一次请求可能要经过一条很长的链路，跨多个服务调用后才能返回结果。当服务超时发生时，研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能，这也是为什么服务超时相对于服务出错和服务调用量异常更难调查的原因。 这篇文章将通过一个真实的线
转载
2024-07-03 18:00:43
66阅读
hadoop自己实现了一个简单的rpc机制，用于在服务器之间进行数据传输，大体的结构如下：主要分为三个部分Server 使用java.nio包发布服务
Server.Connection
保存与客户端的连接，存放对应的Socket、SocketChannel与UserGroupInformation使用UserGroupInformation控制当前操作的权限readAndProc
Windows服务程序 ［ 作者：ldc311 转贴自：本站原创 点击数：639 更新时间：2004-4-28 文章录入：ade99 ］有那么一类应用程序，是能够为各种用户（包括本地用户和远程用户）所用的，拥有用户授权级进行管理的能力，并且不论用户是否物理
一.概述什么是RPC？远程服务调用官方：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想通俗一点：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。市面上常见的rpc框架：dobbo，springCloud，gRPC...那为什么要有 RPC，HTTP 不好么？因为 RPC 和 HTTP 就不是一个层级的东西，所以严格意义上这
转载
2024-10-22 21:52:32
95阅读
梳理spark rpc相关的东西，记录一下1、如果把分布式系统（HBASE,HDFS,SPAKR）比作一个人，那么RPC可以认为是人体的血液循环系统。它将系统中各个不同的组件（如Hbase中的 master,RegionServer,client）联系了起来。同样，在spark中，不同组件像driver,executor,worker,master(standalone模式)之间的通信也是基于RP
转载
2024-04-16 15:30:51
118阅读
同步RPC 的调用通常为了方便使用，会被伪装成普通方法调用的形式。但实际二者之间存在巨大的差异，进程内的方法调用的时间量级是 ns（纳秒），而进程间的 RPC 方法调用时间量级通常是 ms（毫秒），它们之间差着 10 的六次方呢。RPC 的冰山底部透视图如下：但在目前流行的微服务架构模式下，跨服务的同步调用隐藏着巨大的风险。一般微服务化架构下，通常一个业务的调用会跨 N（N 一般大于 2） 个服务
1.RPC接口http请求
客户端向服务器端发送http请求，http请求基于请求与响应的，如果服务器端没有及时的响应请求给客户端的情况下，有可能会造成客户端会一直阻塞等待。客户端调用服务器端接口的时候，会设置一个超时时间5s-10s 30s 如果服务器端处理客户端业务逻辑非常耗时的情况下，应该改成mq异步执行。2.接口超时与接口调用不通区别？
接口响应超时：服务器端实际上已经接受到客户端请求，服
转载
2024-02-03 03:57:39
259阅读
1、RPC(Remote Procedure Call)定义RPC(Remote Procedure Call)—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。RPC
转载
2024-04-26 14:28:10
103阅读
最近线上碰到一点小问题，分析其原因发现是出在对 RPC 使用上的一些细节掌握不够清晰导致。很多时候我们做业务开发会把 RPC 当作黑盒机制来使用，但若不对黑盒的工作原理有个基本掌握，也容易犯一些误用的微妙错误。虽然曾经已经写过一篇《RPC 的概念模型与实现解析》 从概念模型和实现细节上讲述了 RPC 的原理，这一篇就从使用上的一些注意点来捋一捋吧。同步RPC 的调用通常为了方便使用，会被伪装
转载
2024-09-09 10:23:15
91阅读
一. 微服务架构1.1 什么是分布式不同模块部署在不同服务器上
作用：分布式解决网站高并发带来问题1.2 什么是集群多台服务器部署相同应用构成一个集群
作用：通过负载均衡设备共同对外提供服务1.3 什么是RPCRPC 的全称是 Remote Procedure Call 是一种进程间通信方式。
它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程
目录1、Consumer方法级别2、Consumer服务级别3、Provider服务级别4、全局设置级别 1、Consumer方法级别Consumer方法级中设置的参数。目前3.4.2的sofaboot版本该参数只能通过XML方式进行配置，暂时不支持注解方式进行配置，具体配置如下所示，表示com.example.demoSampleService服务方法中的hello方法的超时时间设置为2000
转载
2024-05-07 07:57:00
71阅读
1. RPC概述 1.1 RPC简介 RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。R
转载
2023-07-20 20:38:56
683阅读
1、Hadoop RPC使用 在正式介绍Hadoop RPC基本框架之前，先介绍怎么样使用它。Hadoop RPC主要对外提供了两种接口。 public static VersionedProtocol getProxy/waitForProxy()：构造一个客户端代理对象（该对象实现了某个协议），用于向服务器端发送RPC请求。public static Server getServer()：
转载
2024-09-05 10:46:00
40阅读
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。 降级预案 在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案： 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级； 警告：有些服务在一段时间内成功率有波动（如在95~100
上面这张监控图，对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中，『服务超时』应该属于监控报警最多的一类问题。尤其在微服务架构下，一次请求可能要经过一条很长的链路，跨多个服务调用后才能返回结果。当服务超时发生时，研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能，这也是为什么服务超时相对于服务出错和服务调用量异常更难调查的原因。这篇文章将通过一个真实的线
转载
2024-03-27 07:38:29
25阅读
昨天NFS用的好好的，今天一直不能用。 当我打开NFS服务的时候，就发现有点不正常，NFS服务打开的很慢，记得昨天./nfs start一下 就打开了，而今天得等几分钟，NFS服务启动之后，不但ARM开发板不能挂载NFS文件系统，连虚 拟机本身也不能挂 载，提示 RPC 超时，在网上找了很多资料： 启动慢是因为上次NFS正常挂 载的客户机没有正常卸载，挂载信息残存 在/var/lib/nfs/r
转载
2024-02-21 13:21:53
49阅读
上面这张监控图，对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中，『服务超时』应该属于监控报警最多的一类问题。 尤其在微服务架构下，一次请求可能要经过一条很长的链路，跨多个服务调用后才能返回结果。当服务超时发生时，研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能，这也是为什么服务超时相对于服务出错和服务调用量异常更难调查的原因。 这篇文章将通过
转载
2024-05-16 09:48:42
304阅读
