Hadoop HDFS原理详解（系统性回顾）

2024-01-21 10:11:46

Hadoop

Apache™Hadoop®项目是为可靠的、可扩展的分布式计算而开发的一套开源软件。

Hadoop软件库是一个框架，该框架允许使用简单的编程模型跨计算机集群对大规模数据集进行分布式处理。

Hadoop旨在从单个服务器扩展到数千台机器，每台机器都提供本地计算和存储。

Hadoop框架本身的设计会在应用层去检测和处理各种故障，而不依赖于硬件层面的高可用，因此可以在计算机集群之上提供高可用服务，集群中的任何单个节点是容易出现故障的。

Hadoop项目包括以下模块：

Hadoop Common: 支持其他Hadoop模块的通用的公用程序。

Hadoop Distributed File System (HDFS™): 提供对应用程序数据的高吞吐量访问的分布式文件(管理)系统。

Hadoop YARN: 作业调度和群集资源管理的框架。

Hadoop MapReduce: 一个基于YARN的分布式系统，用于并行处理大规模数据集。

Hadoop Ozone: Hadoop的对象存储。

Apache的其他与Hadoop相关的项目包括：

HBase™: 可扩展的分布式NoSQL列存储数据库，支持大型表的结构化数据存储。

Hive™: 提供数据汇总和即席查询的数据仓库基础设施。

Cassandra™: 可扩展的多主数据库，没有单点故障。

Spark™: 用于Hadoop数据的快速通用计算引擎。Spark提供了一种简单而富有表现力的编程模型，该模型支持广泛的应用程序，包括ETL，机器学习，流处理和图计算。

ZooKeeper™: 面向分布式应用程序的高性能协调服务。

Hadoop源码结构图

HDFS概述

HDFS产生背景

随着数据量越来越大，在一个操作系统管辖的范围内存不下了，那么就需要将数据分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的数据文件，这就是分布式文件(管理)系统。HDFS只是分布式文件管理系统中的一个，其他有FastDFS等。

HDFS概念

首先，HDFS是一个文件系统，用于存储文件，通过目录树来定位文件；

其次，HDFS是分布式的，由多台服务器联合起来实现其功能，集群中服务器有各自的角色。

最后，HDFS的设计适合“一次写入，多次读取”的场景，支持追加，但不支持修改。适合用来做数据分析。

HDFS优缺点

优点

1）高容错性

（1）数据自动保存多个副本。它通过增加副本的形式，提高容错性；

（2）某一个副本丢失以后，它可以自动恢复。

2）适合大数据处理

（1）数据规模：能够处理数据规模达到GB、TB、甚至PB级别的数据；

（2）文件规模：能够处理百万规模以上的文件数量，数量相当之大。

3）流式数据访问，它能保证数据的一致性。

4）可构建在廉价机器上，通过多副本机制，提高可靠性。

缺点

1）不适合低延时数据访问，比如毫秒级的存储数据，是做不到的。

2）无法高效的对大量小文件进行存储。

（1）存储大量小文件的话，它会占用NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的；

（2）小文件存储的寻址时间会超过读取时间，它违反了HDFS的设计目标。

3）不支持并发写入、文件随机修改。

（1）一个文件只能有一个写，不允许多个线程同时写；多份小文件然后merge。

（2）仅支持数据append（追加），不支持文件的随机修改。

HDFS总体架构

HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。一个HDFS集群是由一个NameNode和一定数目的DataNode组成的。

NameNode是一个中心服务器，负责管理文件系统的名字空间 (Namespace )及客户端对文件的访问。

集群中的DataNode一般是一个节点运行一个DataNode进程，负责管理它所在节点上的存储。

HDFS架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。{Client(代表用户)通过与 NameNode和DataNode 交互访问HDFS中的文件。Client 提供了一个类似 POSIX 的文件系统接口供用户调用。在Hadoop生态各组件里，分别有其对应的Client。比如，在HDFS里，是HDFS Client。同理，在Mapreduce里，是Mapreduce Client。}

1）Client：客户端。

（1）负责文件切分。文件上传HDFS的时候，Client将文件切分成一个个的Block（128Mb），然后进行存储；

（2）与NameNode交互，获取文件的位置信息；

（3）与DataNode交互，读取或者写入数据；

（4）Client提供一些命令来管理HDFS，比如启动或者关闭HDFS；

（5）Client可以通过一些命令来访问HDFS；

2）NameNode：就是Master，它是一个管理者。

（1）管理HDFS的名字空间-NameSpace；

（2）管理数据块（Block）映射信息；

（3）配置副本策略；

（4）处理客户端读写请求。

3） DataNode：就是Slave。NameNode下达命令，DataNode执行实际的操作。

（1）存储实际的数据块；

（2）执行数据块的读/写操作。

4） Secondary NameNode：不是NameNode的热备。当NameNode挂掉时，它并不能马上替换NameNode并提供服务。而且NameNode和Secondary NameNode是一台机器上，机器挂了就全都挂了。

（1）辅助NameNode，分担其工作量；

（2）定期合并镜像-Fsimage和编辑日志-Edits，并推送给NameNode；

（3）在紧急情况下，可辅助恢复NameNode。

HDFS文件块大小

HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数(dfs.blocksize)来设置，默认大小在hadoop2.x版本中是128M。HDFS的block比磁盘的block大，其目的是为了最小化寻址开销。如果block设置得足够大，从磁盘传输数据的时间会明显大于定位这个block开始位置所需的时间。因而，传输一个由多个block组成的文件的时间取决于磁盘传输速率。如果寻址时间约为10ms，而传输速率为100MB/s，为了使寻址时间仅占传输时间的1%，我们要将块大小设置约为100MB (10ms*100*100M/s=10ms/0.01*100M/s)。HDFS默认的block大小128MB。

HFDS的Shell操作

基本语法

$ bin/hadoop fs orders

$ hadoop fs可以用于其他文件系统，不止是hdfs文件系统内，使用范围更广。

$ hadoop dfs专门针对hdfs分布式文件系统。

hdfs dfs和hadoop dfs命令作用相同，相比于上面的命令更为推荐，并且当使用hadoop dfs时内部会被转为hdfs dfs命令。

……………………………………………….

HDFS的数据流

HDFS写数据流程(文件写入)

1）Client通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。

2）NameNode返回是否可以上传。

3）Client请求第一个 block上传到哪几个DataNode服务器上。

4）NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。

5）Client通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将整个通信管道建立完成。

6）dn1、dn2、dn3逐级应答Client。

7）Client开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。

8）当一个block传输完成之后，Client再次请求NameNode上传第二个block的服务器。（重复执行3-7步）。

Hadoop副本节点选择

第一个副本在Client所处的节点上。如果Client在集群外，随机选一个。

第二个副本和第一个副本位于相同机架，随机节点。

第三个副本位于不同机架，随机节点。

HDFS读数据流程

1）Client通过Distributed FileSystem模块向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。

2）挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。

3）DataNode开始传输数据给Client（从磁盘里面读取数据输入流，以packet为单位来做校验）。

4）Client以packet为单位接收，先在本地缓存，然后写入目标文件。

NameNode和SecondaryNameNode

NameNode和SecondaryNameNode工作机制

1）第一阶段：NameNode启动

（1）第一次启动NameNode格式化后，创建镜像文件-fsimage和编辑日志-edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。

（2）Client对元数据进行增删改的请求。

（3）NameNode记录操作日志，滚动更新日志。

（4）NameNode在内存中对数据进行增删改查。

2）第二阶段：Secondary NameNode工作

（1）Secondary NameNode询问NameNode是否需要checkpoint。直接返回NameNode是否checkpoint的结果。

（2）Secondary NameNode请求执行checkpoint。

（3）NameNode滚动正在写的edits日志。

（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。

（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。

（6）生成新的镜像文件fsimage.chkpoint。

（7）拷贝fsimage.chkpoint到NameNode。

（8）NameNode将fsimage.chkpoint重新命名成fsimage。

Fsimage和Edits解析

1）概念

namenode被格式化之后，将在/.../data/tmp/dfs/name/current目录中产生如下文件

edits_0000000000000000000

edits_inprogress_909090909090

fsimage_0000000000000000000

fsimage_0000000000000000000.md5

seen_txid(343706233-edits_inprogress_)

VERSION

（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。

（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。

（3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字

（4）每次NameNode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将fsimage和edits文件进行了合并。

2）oiv查看fsimage文件

（1）查看oiv和oev命令

offline fsimage viewer

offline edits viewer

$ hdfs

oiv apply the offline fsimage viewer to an fsimage

oev apply the offline edits viewer to an edits file

（2）基本语法

hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

$ hdfs oiv

Usage: bin/hdfs oiv [OPTIONS] -i INPUTFILE -o OUTPUTFILE

Offline Image Viewer

View a Hadoop fsimage INPUTFILE using the specified PROCESSOR,

saving the results in OUTPUTFILE.

3）oev查看edits文件

（1）基本语法

hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

$ hdfs oev

Usage: bin/hdfs oev [OPTIONS] -i INPUT_FILE -o OUTPUT_FILE

Offline edits viewer

Parse a Hadoop edits log file INPUT_FILE and save results

in OUTPUT_FILE.

checkpoint时间设置

（1）通常情况下，SecondaryNameNode每隔一小时执行一次：3600秒。

[hdfs-default.xml]

<name>dfs.namenode.checkpoint.period</name>

</property>

（2）一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。

<name>dfs.namenode.checkpoint.txns</name>

<description>操作动作次数</description>

</property>

<name>dfs.namenode.checkpoint.check.period</name>

<description> 1分钟检查一次操作次数</description>

</property>

NameNode故障处理

NameNode故障后，可以采用如下两种方法恢复数据。

方法一：将SecondaryNameNode中数据拷贝到NameNode存储数据的目录；

1）kill -9 namenode进程

2）删除NameNode存储的数据（/.../data/tmp/dfs/name）

$ rm -rf /.../data/tmp/dfs/name/*

3）拷贝SecondaryNameNode中数据到原NameNode存储数据目录

$ scp -r hdfs@hadoop1:/.../data/tmp/dfs/namesecondary/* ./name/

4）重新启动namenode

$ sbin/hadoop-daemon.sh start namenode

方法二：使用-importCheckpoint选项启动NameNode守护进程，从而将SecondaryNameNode中数据拷贝到NameNode目录中。

1）修改hdfs-site.xml中的

<name>dfs.namenode.checkpoint.period</name>

</property>

<name>dfs.namenode.name.dir</name>

</property>

2）kill -9 namenode进程

3）删除NameNode存储的数据（/.../data/tmp/dfs/name）

$ rm -rf /.../data/tmp/dfs/name/*

4）如果SecondaryNameNode不和NameNode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到NameNode存储数据的平级目录，并删除in_use.lock文件。

$ scp -r hdfs@hadoop1:/.../data/tmp/dfs/namesecondary ./

$ rm -rf in_use.lock

$ pwd

/.../data/tmp/dfs

$ ls

data name namesecondary

5）导入检查点数据（等待一会ctrl+c结束掉）

$ bin/hdfs namenode -importCheckpoint

6）启动namenode

$ sbin/hadoop-daemon.sh start namenode

集群安全模式

1）概述

NameNode启动时，首先将镜像文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作。一旦在内存中成功建立文件系统元数据镜像，则创建一个新的fsimage文件和一个空的编辑日志。此时，NameNode开始监听DataNode请求。

但是此刻，NameNode运行在安全模式，即NameNode的文件系统对于客户端来说是只读的。系统中的数据块的位置并不是由NameNode维护的，而是以块列表的形式存储在DataNode中。

在系统的正常操作期间，NameNode会在内存中保留所有块位置的映射信息。

在安全模式下，各个DataNode会向NameNode发送最新的块列表信息，NameNode了解到足够多的块位置信息之后，即可高效运行文件系统。如果满足“最小副本条件”，NameNode会在30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）。在启动一个刚刚格式化的HDFS集群时，因为系统中还没有任何块，所以NameNode不会进入安全模式。

2）基本语法

集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。

（1）bin/hdfs dfsadmin -safemode get （功能描述：查看安全模式状态）

（2）bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）

（3）bin/hdfs dfsadmin -safemode leave （功能描述：离开安全模式状态）

（4）bin/hdfs dfsadmin -safemode wait （功能描述：等待安全模式状态）

3）案例

模拟等待安全模式

（1）先进入安全模式

$ bin/hdfs dfsadmin -safemode enter

（2）执行下面的脚本

编辑一个脚本

#!/bin/bash

bin/hdfs dfsadmin -safemode wait

bin/hdfs dfs -put ~/hello.txt /root/hello.txt

（3）再打开一个窗口，执行

$ bin/hdfs dfsadmin -safemode leave

NameNode多目录配置

1）NameNode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。

2）具体配置如下：

（1）在hdfs-site.xml文件中增加如下内容

<name>dfs.namenode.name.dir</name>

<value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value>

</property>

（2）停止集群，删除data和logs中所有数据。

$ rm -rf data/ logs/

（3）格式化集群并启动。

$ bin/hdfs namenode –format

$ sbin/start-dfs.sh

（4）查看结果

$ ll

DataNode

DataNode工作机制

1）一个数据块在DataNode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。

2）DataNode启动后，向NameNode注册，通过后，周期性（1小时）的向NameNode上报所有的块信息。

3）心跳是每3秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用。

4）集群运行中可以安全加入和退出一些机器。

数据完整性

1）当DataNode读取block的时候，它会计算checksum。

2）如果计算后的checksum，与block创建时值不一样，说明block已经损坏。

3）Client读取其他DataNode上的block。

4）datanode在其文件创建后周期验证checksum。

掉线时限参数设置

DataNode进程死亡或者网络故障造成DataNode无法与NameNode通信，NameNode不会立即把该节点判定为死亡，要经过一段时间，这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。

如果定义超时时间为timeout，则超时时长的计算公式为：

timeout = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval。

而默认的dfs.namenode.heartbeat.recheck-interval 大小为5分钟，dfs.heartbeat.interval默认为3秒。

需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒，dfs.heartbeat.interval的单位为秒。

<name>dfs.namenode.heartbeat.recheck-interval</name>

</property>

<name> dfs.heartbeat.interval </name>

</property>

其他、快照管理

快照相当于对目录做一个备份。

并不会立即复制所有文件，而是指向同一个文件。

当写入发生时，才会产生新文件。

基本语法

（1）hdfs dfsadmin -allowSnapshot 路径（功能描述：开启指定目录的快照功能）

（2）hdfs dfsadmin -disallowSnapshot 路径（功能描述：禁用指定目录的快照功能，默认是禁用）

（3）hdfs dfs -createSnapshot 路径（功能描述：对目录创建快照）

（4）hdfs dfs -createSnapshot 路径名称（功能描述：指定名称创建快照）

（5）hdfs dfs -renameSnapshot 路径旧名称新名称（功能描述：重命名快照）

（6）hdfs lsSnapshottableDir （功能描述：列出当前用户所有可快照目录）

（7）hdfs snapshotDiff 路径1 路径2 （功能描述：比较两个快照目录的不同之处）

（8）hdfs dfs -deleteSnapshot （功能描述：删除快照）

其他、回收站

1）默认回收站

默认值fs.trash.interval=0，0表示禁用回收站，可以设置删除文件的存活时间。

默认值fs.trash.checkpoint.interval=0，检查回收站的间隔时间。如果该值为0，则该值设置和fs.trash.interval的参数值相等。

要求fs.trash.checkpoint.interval<=fs.trash.interval。

2）启用回收站

修改core-site.xml，配置垃圾回收时间为1分钟。

<name>fs.trash.interval</name>

</property>

3）查看回收站

回收站在集群中的；路径：/user/hdfs/.Trash/….

4）修改访问垃圾回收站用户名称

进入垃圾回收站用户名称，默认是dr.who，修改为hdfs用户

[core-site.xml]

<name>hadoop.http.staticuser.user</name>

</property>

5）通过程序删除的文件不会经过回收站，需要调用moveToTrash()才进入回收站

Trash trash = New Trash(conf);

trash.moveToTrash(path);

6）恢复回收站数据

$ hadoop fs -mv /user/hdfs/.Trash/Current/user/hdfs/input /user/hdfs/input

7）清空回收站

$ hadoop fs -expunge

HDFS HA高可用

HA概述

1）所谓HA（high available），即高可用（7*24小时不中断服务）。

2）实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。

3）Hadoop2.0之前，在HDFS集群中NameNode存在单点故障（SPOF）。

4）NameNode主要在以下两个方面影响HDFS集群

NameNode机器发生意外，如宕机，集群将无法使用，直到管理员重启。

NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用。

HDFS HA功能通过配置Active/Standby两个nameNodes实现在集群中对NameNode的热备来解决上述问题。

如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

HDFS-HA工作机制

通过双NameNode消除单点故障

HDFS-HA工作要点

1）元数据管理方式需要改变：

内存中各自保存一份元数据；

Edits日志只有Active状态的NameNode节点可以做写操作；

两个NameNode都可以读取edits；

共享的edits放在一个共享存储中管理（qjournal和NFS两个主流实现）。

2）需要一个状态管理功能模块

实现了一个zkfailover，常驻在每一个NameNode所在的节点，每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生。

3）必须保证两个NameNode之间能够ssh无密码登录。

4）隔离（Fence），即同一时刻仅仅有一个NameNode对外提供服务

HDFS-HA自动故障转移工作机制

使用命令hdfs haadmin -failover手动进行故障转移，在该模式下，即使Active状态的NameNode已经失效，系统也不会自动从Active状态的NameNode转移到Standby状态的NameNode，下面通过配置部署HA自动进行故障转移。

自动故障转移为HDFS部署增加了两个新组件：

ZooKeeper和ZKFailoverController（ZKFC）进程。

ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务。

HA的自动故障转移依赖于ZooKeeper的以下功能：

1）故障检测：

集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。

2）Active NameNode选择：

ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为Active状态。如果目前Active的NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排它锁以表明它应该成为Active的NameNode。

ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。

每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：

1）健康监测：

ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。ZKFC相当于NameNode的监视器。

如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。

2）ZooKeeper会话管理：

当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。

如果本地NameNode处于Active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对临时节点的支持，如果会话终止，锁节点将自动删除。

3）Active 选举：

如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地NameNode为Active。

1. 一台NameNode假死了

2. 假死NameNode所在机器的zkfc检测到假死

3. 通知另外一台NameNode的zkfc

4. 另外一台zkfc就会强行ssh kill -9杀死假死的NameNode

5. 如果ssh失败则调用用户自定义脚本程序，比如poweroff直接关机或者重启服务器

6. 正常NameNode的zkfc获取命令运行结果

7. 激活本台NameNode 切换为Active

HDFS 联邦架构设计

1）NameNode架构的局限性

（1）Namespace（命名空间）的限制

由于NameNode在内存中存储所有的元数据（metadata），因此单个NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。

50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个datanode，12PB的存储（假设文件平均大小为40MB）。随着数据的飞速增长，存储的需求也随之增长。

单个datanode从4T增长到36T，集群的尺寸增长到8000个datanode。

存储的需求从12PB增长到大于100PB。

（2）隔离问题

由于HDFS仅有一个NameNode，无法隔离各个程序，因此HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序。

（3）性能的瓶颈

由于是单个NameNode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。

2）HDFS Federation架构设计

能不能有多个NameNode，分别负责不同的业务数据？

3）HDFS 联邦应用思考

不同应用可以使用不同NameNode进行数据管理；

图片业务、爬虫业务、日志审计业务；

Hadoop生态系统中，不同的框架使用不同的NameNode进行管理NameSpace。

码农公寓

相关文章