盘点下常见 HDFS JournalNode 异常的问题原因和修复方法

盘点下常见 HDFS JournalNode 异常的问题原因和修复方法

最近在多个客户现场以及公司内部环境,都遇到了因为 JournalNode 异常导致 HDFS 服务不可用的问题,在此总结下相关知识。

1 HDFS HA 高可用和 JournalNode 概述

  • HDFS namenode 有 SPOF 单点故障,因为对客户端提供元数据读写服务的是单一的一个 NameNode,Secondary NameNode 仅仅提供了 HDFS 故障时的可恢复性,而没有提供整个HDFS服务的高可用性;
  • 之所以说 Secondary NameNode 仅仅提供了 HDFS 故障时的可恢复性而不是高可用性,是因为 HDFS 发生故障时,Secondary NameNode 并不会自动晋升为 nameNode, 运维管理员需要介入进行手动处理后才能恢复 HDFS 对外服务;
  • 在底层,Secondary NameNode 提供了 fsimage 和 editLog 的合并功能(old fsimage + edit logs = new fsimage),这一过程称为 checkpoint,是基于参数 dfs.namenode.checkpoint.period 和 dfs.namenode.checkpoint.txns,按照时间和事件共同触发的;
  • 为解决 HDFS NAMENODE 的 SPOF,可以配置启用 HDFS 的 HA 高可用,此时其架构如下,可以看到包括 active 与 standby 两个namenode 互为主备,包括奇数个 zkfc 基于zk 提供 nn 的故障检测和自动转移,包括奇数个 JournalNode 提供两个 nn 之间共享 editLogs;
  • Active Namenode 与 StandBy Namenode 为了同步 editLog 状态数据,会通过一组称作 JournalNodes 的独立进程进行相互通信: 当 active 状态的 NameNode 的命名空间有任何修改时,Active Namenode 会向 JournalNodes 中写 editlog 数据, 而 StandBy Namenode 会一直监控 JournalNodes 中 editLog 的变化,并把变化应用于自己的命名空间,从而确保两者命名空间状态的同步和一致,当 Active Namenode 故障出错时,standby Namenode 就可以不丢失数据地实时晋升为 Active Namenode 对外提供服务;
  • HDFS HA 的详细架构图如下:
  • HDFS NN 存储元数据信息的本地文件系统目录结构和关键文件如下:
  • HDFS JN 存储元数据信息的本地文件系统目录结构和关键文件如下:
- When the NameNode starts up, it reads the FsImage and EditLog from disk, applies all the transactions from the EditLog to the in-memory representation of the FsImage, and flushes out this new version into a new FsImage on disk. It can then truncate the old EditLog because its transactions have been applied to the persistent FsImage. This process is called a checkpoint;
- The secondary NameNode merges the fsimage and the edits log files periodically and keeps edits log size within a limit. It is usually run on a different machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode.
- In a typical HA cluster, two or more separate machines are configured as NameNodes. At any point in time, exactly one of the NameNodes is in an Active state, and the others are in a Standby state. The Active NameNode is responsible for all client operations in the cluster, while the Standbys are simply acting as workers, maintaining enough state to provide a fast failover if necessary. 
- In order for the Standby node to keep its state synchronized with the Active node, both nodes communicate with a group of separate daemons called “JournalNodes(JNs). When any namespace modification is performed by the Active node, it durably logs a record of the modification to a majority of these JNs. The Standby node is capable of reading the edits from the JNs, and is constantly watching them for changes to the edit log. As the Standby Node sees the edits, it applies them to its own namespace. In the event of a failover, the Standby will ensure that it has read all of the edits from the JournalNodes before promoting itself to the Active state. This ensures that the namespace state is fully synchronized before a failover occurs.
- In order to provide a fast failover, it is also necessary that the Standby node have up-to-date information regarding the location of blocks in the cluster. In order to achieve this, the DataNodes are configured with the location of all NameNodes, and send block location information and heartbeats to all.- It is vital for the correct operation of an HA cluster that only one of the NameNodes be Active at a time. Otherwise, the namespace state would quickly diverge between the two, risking data loss or other incorrect results. In order to ensure this property and prevent the so-called “split-brain scenario,” the JournalNodes will only ever allow a single NameNode to be a writer at a time. During a failover, the NameNode which is to become active will simply take over the role of writing to the JournalNodes, which will effectively prevent the other NameNode from continuing in the Active state, allowing the new Active to safely proceed with failover.
- There must be at least 3 JournalNode daemons, since edit log modifications must be written to a majority of JNs. This will allow the system to tolerate the failure of a single machine. You may also run more than 3 JournalNodes, but in order to actually increase the number of failures the system can tolerate, you should run an odd number of JNs, (i.e. 3, 5, 7, etc.). Note that when running with N JournalNodes, the system can tolerate at most (N - 1) / 2 failures and continue to function normally.

2 HDFS JournalNode 异常的常见原因

  • 从上述分析可知,HDFS HA 的正常工作依赖于 JournalNode 的正常工作,当集群中半数以上的 JournalNode 节点发生异常后,HDFS HA 就无法正常工作了;
  • 由于 JournalNode 如此重要,绝大部分的大数据集群管理软件如 ClouderaManager/Ambari等,都会监控 JournalNode 并在其异常时发送告警通知;
  • 如下即是 ClouderaManager 对 JN 同步状态和磁盘空间常见的的监控报警信息:
- The health test result for JOURNAL_NODE_SYNC_STATUS has become bad: The active NameNode is out of sync with this JournalNode.
- This role's JournalNode Edits Directory is on a filesystem with less than 10.0 GiB of its space free. /dfs/jn (free: 4.0 GiB (2.68%), capacity: 149.9 GiB)
  • 造成 HDFS JournalNode 异常的常见原因有:
    • JournalNode 节点的本地磁盘故障或磁盘满,导致写入的 editLog 数据异常;
    • JournalNode 节点异常并重装了操作系统;
    • 出于扩展集群的需求,新增了JournalNode 节点;

3 HDFS JournalNode 异常的常规修复方法

HDFS JournalNode 异常,大体应该遵循如下逻辑进行修复:

  1. 准备工作:确定当前可以正常工作的 JournalNode 节点,其 editLog 文件的存放位置(即参数dfs.journalnode.edits.dir的值),以及当前最新的 editLog 文件 (各个节点各个 editLog 文件的文件名中都包含了递增的 sequence number 序列号,比如历史 editLog 文件 edits_0000000000056586378-0000000000056586407 和 当前 editLog 文件 edits_inprogress_0000000000056586408,序列号最大的即是最新的 editLog 文件);
  2. 停止 HDFS 集群;
  3. 删除 editLog 脏数据:如果是 JournalNode 节点的本地磁盘故障或磁盘满,则修复/更换磁盘或清理磁盘空间,并删除已经写入的异常的 editLog 文件(也可以删除 dfs.journalnode.edits.dir目录下的所有子目录和文件,包括 VERSION 文件, edits 文件等;删除前建议先备份);
  4. 恢复 editLog 数据:从当前可以正常工作的 JournalNode 节点,拷贝其正常的 editLog 数据文件,可以拷贝 dfs.journalnode.edits.dir目录下的所有子目录和文件,包括 VERSION 文件, edits 文件等 (事实上只拷贝 VERSION 文件和最新的 editLog 文件也可以,此时后续启动 JournalNode 后,会自动拷贝其它历史 editLog);
  5. 确保拷贝过来的所有文件的用户和用户组是HDFS:chown -R hdfs:hdfs ./*;
  6. 启动 HDFS 服务,查看日志,确保恢复正常;
  • 问题 journalnode 节点修复重启后,自动同步和滚动 editLog 的部分日志如下:
2023-11-08 14:19:03,112 INFO org.apache.hadoop.hdfs.qjournal.server.JournalNodeSyncer: Downloaded file edits_0000000000056292183-0000000000056292202 of size 2367 bytes.
2023-11-08 14:19:03,113 INFO org.apache.hadoop.hdfs.qjournal.server.JournalNodeSyncer: Downloading missing Edit Log from http://uf30-2:8480/getJournal?jid=ns1&segmentTxId=56292203&storageInfo=-64%3A1693184092%3A1603367087970%3Acluster12&inProgressOk=false to /dfs/jn/ns1
2023-11-08 14:19:03,159 INFO org.apache.hadoop.hdfs.server.common.Util: Combined time for file download and fsync to all disks took 0.00s. The file download took 0.00s at 4000.00 KB/s. Synchronous (fsync) write to disk of /dfs/jn/ns1/edits.sync/edits_0000000000056292203-0000000000056292232 took 0.00s.
2023-11-08 16:02:32,313 INFO org.apache.hadoop.hdfs.qjournal.server.JournalNodeSyncer: Syncing Journal /192.168.71.70:8485 with uf30-2/192.168.71.71:8485, journal id: ns1
2023-11-08 16:03:18,694 INFO org.apache.hadoop.hdfs.server.namenode.FileJournalManager: Finalizing edits file /dfs/jn/ns1/current/edits_inprogress_0000000000056587366 -> /dfs/jn/ns1/current/edits_0000000000056587366-0000000000056587395
2023-11-08 16:03:18,856 INFO org.apache.hadoop.hdfs.server.namenode.TransferFsImage: Sending fileName: /dfs/jn/ns1/current/edits_0000000000056587366-0000000000056587395, fileSize: 4142. Sent total: 4142 bytes. Size of last segment intended to send: -1 bytes.

4 HDFS JournalNode 异常修复时遇到的常见问题

  • JournalNotFormattedException:即 Journal 未格式化异常,这种错误经常出现在重装 Journal 节点操作系统时,或添加新 Journal 节点时,修复方法为从其它正常 Journal 节点拷贝 VERSION 文件即可,详细报错如下:
org.apache.hadoop.hdfs.qjournal.protocol.JournalNotFormattedException: journal storage directory /dfs/jn/nameservice1 not formatted
  • editLog 过期损坏异常:这种错误经常出现在某个 Journal节点因磁盘异常或其它原因,长期没有跟其它 Journal 节点同步 editLog 数据,导致其最新的 editLog 文件(即edits_inprogressxxx 文件)过期异常,修复方法为按照上述步骤,删除其异常的 edits_inprogressxxx 文件或全部的 editLog文件,然后重启 Journal 角色即可(重启后会自动从其它正常 Journal 节点拷贝 editLog 文件),详细报错如下:
FSImage	Caught exception after scanning through 0 ops from /dfs/jn/ns1/current/edits_inprogress_0000000000055367073 while determining its valid length. Position was 229376
java.io.IOException: Can't scan a pre-transactional edit log.at org.apache.hadoop.hdfs.server.namenode.FSEditLogOp$LegacyReader.scanOp(FSEditLogOp.java:5264)at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanNextOp(EditLogFileInputStream.java:243)at org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader.scanEditLog(FSEditLogLoader.java:1248)at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanEditLog(EditLogFileInputStream.java:327)at org.apache.hadoop.hdfs.server.namenode.FileJournalManager$EditLogFile.scanLog(FileJournalManager.java:566)at org.apache.hadoop.hdfs.qjournal.server.Journal.scanStorageForLatestEdits(Journal.java:210)at org.apache.hadoop.hdfs.qjournal.server.Journal.<init>(Journal.java:162)at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:99)at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:145)at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:216)at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.getEditLogManifest(QJournalProtocolServerSideTranslatorPB.java:228)at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:27411)at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:523)at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:991)at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:869)at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:815)at java.security.AccessController.doPrivileged(Native Method)at javax.security.auth.Subject.doAs(Subject.java:422)at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1875)at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2675)
  • /dfs/jn/ns1/in_use.lock 文件锁异常:这种错误经常出现在目录 /dfs/jn 或其子目录和文件的 owner/group 不是 JournalNode 进程的启动用户(一般是HDFS:HDFS),或者异常启动了多个 JournalNode 进程, 修复方法为更改 /dfs/jn 目录及其子目录和文件的 owner/group 为 JournalNode 进程的启动用户,(chown -R hdfs:hdfs /dfs/jn)并重启 JournalNode 服务进程,详细报错如下:
It appears that another node  165959@uf30-1 has already locked the storage directory: /dfs/jn/ns1
java.nio.channels.OverlappingFileLockExceptionat sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1107)at java.nio.channels.FileChannel.tryLock(FileChannel.java:1155)at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.tryLock(Storage.java:841)at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.lock(Storage.java:809)at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.analyzeStorage(Storage.java:622)at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.analyzeStorage(Storage.java:573)at org.apache.hadoop.hdfs.qjournal.server.JNStorage.analyzeAndRecoverStorage(JNStorage.java:253)at org.apache.hadoop.hdfs.qjournal.server.JNStorage.<init>(JNStorage.java:77)at org.apache.hadoop.hdfs.qjournal.server.Journal.<init>(Journal.java:153)at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:99)at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:145)at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:216)at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.getEditLogManifest(QJournalProtocolServerSideTranslatorPB.java:228)at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:27411)at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:523)at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:991)at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:869)at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:815)at java.security.AccessController.doPrivileged(Native Method)at javax.security.auth.Subject.doAs(Subject.java:422)at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1875)at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2675)
xxx 
IPC Server handler 4 on 8485, call Call#4204 Retry#0 org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocol.getEditLogManifest from 192.168.71.71:35892
java.io.IOException: Cannot lock storage /dfs/jn/ns1. The directory is already lockedat org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.lock(Storage.java:814)at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.analyzeStorage(Storage.java:622)at org.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.analyzeStorage(Storage.java:573)at org.apache.hadoop.hdfs.qjournal.server.JNStorage.analyzeAndRecoverStorage(JNStorage.java:253)at org.apache.hadoop.hdfs.qjournal.server.JNStorage.<init>(JNStorage.java:77)at org.apache.hadoop.hdfs.qjournal.server.Journal.<init>(Journal.java:153)at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:99)at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:145)at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:216)at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.getEditLogManifest(QJournalProtocolServerSideTranslatorPB.java:228)at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:27411)at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:523)at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:991)at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:869)at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:815)at java.security.AccessController.doPrivileged(Native Method)at javax.security.auth.Subject.doAs(Subject.java:422)at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1875)at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2675)

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/30668.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【尚庭公寓SpringBoot + Vue 项目实战】移动端项目初始化(十九)

【尚庭公寓SpringBoot Vue 项目实战】移动端项目初始化&#xff08;十九&#xff09; 文章目录 【尚庭公寓SpringBoot Vue 项目实战】移动端项目初始化&#xff08;十九&#xff09;1、 SpringBoot配置2、Mybatis-Plus配置3、Knife4j配置4、导入基础代码5、导入接口定义代码6…

上海中腾食品科学餐饮管理铸就企业食堂新模式

在当今企业运营中&#xff0c;食堂不仅是员工用餐的场所&#xff0c;更是企业文化和管理水平的体现。随着餐饮行业的不断发展&#xff0c;科学合理的餐饮管理模式成为了企业食堂成功的关键。上海中腾食品科技有限公司以其独特的餐饮管理模式&#xff0c;成功打造了企业食堂的新…

CSS3中鲜为人知但非常强大的 Clip-Path 属性

CSS3中鲜为人知但非常强大的 Clip-Path 属性 在CSS3中,clip-path属性可以让我们快速创建各种各样的不规则图形,而无需使用图片或者复杂的绘图工具。它可以帮助我们实现一些非常出色的视觉效果,但遗憾的是它并不是很常见。 clip-path属性可以接受多种不同的值,比如polygon()、…

静态网页发送基本请求

目录 一、 发送 GET 请求 1&#xff0e;不携带 url 参数的 GET 请求 2&#xff0e;携带 url 参数的 GET 请求 二、发送 POST 请求 三、处理响应 1&#xff0e;获取网页源代码 2&#xff0e;获取图片 一、 发送 GET 请求 当用户在浏览器的地址栏中直接输入某个 URL 地址…

海量数据处理利器 Roaring BitMap 原理介绍

作者&#xff1a;来自 vivo 互联网服务器团队- Zheng Rui 本文结合个人理解梳理了BitMap及Roaring BitMap的原理及使用&#xff0c;分别主要介绍了Roaring BitMap的存储方式及三种container类型及Java中Roaring BitMap相关API使用。 一、引言 在进行大数据开发时&#xff0c;…

公域+私域运营思路框架

本次分享公域私域运营思路框架&#xff0c;内容包括私域原则、公域引流、让利思维、价值体系等内容&#xff0c;让你的流量保持高留存、高活跃。

idea 创建properties文件,解决乱码

设置properties文件编码 点击file->Settings File Encodings->设置utf-8 重新创建.properties文件才生效

【Java学习笔记】异常处理

生活中我们在使用一些产品的时候&#xff0c;经常会碰到一些异常情况。例如&#xff0c;使用ATM机取钱的时&#xff0c;机器会突然出现故障导致无法完成正常的取钱业务&#xff0c;甚至吞卡&#xff1b;在乘坐地铁时&#xff0c;地铁出现异常无法按时启动和运行&#xff1b;使用…

本科且非专业学历|艺术自由职业者成功赴美国威斯康星大学麦迪逊分校自费访学

R老师只有本科学历且不是艺术专业&#xff0c;但有独创的艺术作品&#xff0c;其希望在一年的访问学者期间&#xff0c;拓宽艺术视野&#xff0c;同时学习艺术理论&#xff0c;以弥补学术背景薄弱的短板。最终我们为其落实了美国威斯康星大学麦迪逊分校访问学者职位。 R老师背景…

IAR stack usage

c - IAR Stack Usage for STM32 in the map File - Stack Overflow

SAP FICO 下载文件报错【调用数据提供商错误】

报错如下图所示&#xff1a; 解决办法&#xff1a; 当弹出保存文件的提示时&#xff0c;不要点击“记住我的决定”

【MATLAB】语法

MATLAB 基本语法(%{和%}) 赋值 函数名值&#xff1b;for for i1:10循环语句 end//while x0; sum0; while x<100sumsumx;x; end//if if x > 1f x^2 1; elsef 2 * x endswitch onum input(请输入一个数); switch num case -1 //注意case后面没有冒号disp(I am…

昇思25天学习打卡营第1天|基本介绍及快速入门

1.第一天学习总体复盘 1&#xff09;成功注册昇思大模型平台&#xff0c;并成功申请算力&#xff1b; 2)在jupyter环境下学习初学入门/初学教程的内容&#xff1b; 在基本介绍部分&#xff0c;快速撸了一边内容&#xff0c;有了一个基本的了解&#xff08;没理解到位的计划采用…

【尝鲜】SpringCloudAlibaba AI 配置使用教程

1、环境配置 maven依赖pom.xml 注意配置远程仓库&#xff0c;原因见&#xff1a;Unresolved dependency: ‘org.springframework.ai:spring-ai-core:jar:0.8.1’ <dependencies><!--Base--><dependency><groupId>org.springframework.boot</group…

用qq邮箱发送邮件验证码java

添加依赖 <dependency><groupId>com.sun.mail</groupId><artifactId>javax.mail</artifactId><version>1.6.2</version> </dependency>配置邮箱 实现代码 package com.example.demo.service; import org.springframework.st…

芜湖!恒驰大数据迁移案例荣幸亮相“东数西算”芜湖集群创新大会暨华为云华东(芜湖)数据中心全球开服活动

6月13日至14日&#xff0c;“东数西算”芜湖集群创新大会暨华为云华东&#xff08;芜湖&#xff09;数据中心全球开服活动在安徽芜湖隆重举办&#xff0c;标志着“东数西算”芜湖集群正式上线、华为云全国存算网的枢纽节点布局全面完成。 本次活动由华为技术有限公司主办、芜湖…

金属配件加工厂设备远程监控

随着科技的飞速发展&#xff0c;智能制造已成为制造业转型升级的重要方向。在金属配件加工领域&#xff0c;设备的稳定运行和高效管理对于提升产品质量、降低生产成本至关重要。HiWoo Cloud平台凭借其强大的远程监控功能&#xff0c;为金属配件加工厂提供了全新的解决方案&…

Android SurfaceFlinger——服务启动流程(二)

SurfaceFlinger 是 Android 系统中的一个核心服务&#xff0c;负责管理图形缓冲区的合成和屏幕显示&#xff0c;是 Android 图形系统的关键组件。 一、启动流程 SurfaceFlinger 作为一个系统服务&#xff0c;在 Android 启动早期由 init 进程通过 servicemanager 启动。它是作…

【黑马TS】学习资料Day4

五、在 React 中使用 TypeScript 现在&#xff0c;我们已经掌握了 TS 中基础类型、高级类型的使用了。但是&#xff0c;如果要在前端项目开发中使用 TS&#xff0c;还需要掌握 React、Vue、Angular 等这些库或框架中提供的 API 的类型&#xff0c;以及在 TS 中是如何使用的。 …

作为一名程序员,最大的成就感来自哪里?

说在前面 &#x1f388;作为一名程序员&#xff0c;我们的生活充满了挑战与创造。在成千上万行代码的背后&#xff0c;我们的成就感来源于何处&#xff1f;是解决问题的瞬间&#xff0c;是产品发布的一刻&#xff0c;还是用户的一声赞叹&#xff1f; 解决问题的瞬间 每当我们调…