简介面向 PostgreSQL 运维与架构人员的高可用部署文档围绕流复制实现主备 WAL 日志实时同步并结合 pgpool-II 完成连接池、负载均衡、读写分离与故障切换适合需要搭建主从架构或补强数据库容灾能力的读者参考。压缩包仅含 1 个 docx约 773KB正文按方案说明、实践环境、客户环境准备与配置步骤组织便于逐章查阅。内容从方案综述和同步、异步复制取舍讲起说明二者在数据一致性与写性能之间的权衡覆盖主库参数配置、备库初始化、pgpool-II 健康监控与切换策略、pg_rman 备份以及软件版本、postgres 用户权限、安装目录、防火墙、SELinux、hosts、时钟同步和系统资源限制等部署细节并给出启动与故障模拟测试思路。已有471人学习可作为从原理到落地配置、排查部署细节的完整参考方案。1. 一次主备搭好却连不上的翻车让我重写了整套安装顺序去年帮一个做报表系统的团队搭 PostgreSQL 高可用主从流复制跑得好好的pg_stat_replication里state是streaming看着一切正常。结果应用连上 pgpool 之后一半查询报all backend nodes are down另一半读到的是旧数据。排查了大半天问题不在 SQL不在网络而在于我图省事先装 pgpool 后配流复制pgpool 启动时后端节点还没进入可识别状态pool_nodes里两个节点全是down。这类翻车在 PostgreSQL 主从加 pgpool-II 的组合里非常典型。单机 PostgreSQL 装完能连上就算完事但一旦上了双节点加中间件链路就变成「客户端 → pgpool → 主库/备库」任何一环的版本、标识文件、认证配置、心跳地址错一点整个集群就装成半瘫。这份方案文档覆盖的正是这条完整链路PostgreSQL 流复制、pgpool-II 连接池与读写分离、pg_rman 离线备份环境以 RHEL/CentOS 为主新老版本给了 10.3 配 pgpool-II 3.6.14、12.2 配 pgpool-II 4.1.1 两套对照。适合谁看手上有一台主库、准备加备库并且要读写分离的开发者正在被 recovery.conf 到底该不该存在折磨的人以及接手一套「能连但不知道能不能切」的老集群、需要重新验证的运维。后面按装什么、怎么装、坏了怎么救的顺序走一遍。2. 环境先对齐版本组合与操作系统前置配置这套环境最常见的失败不是命令敲错是版本组合没对齐。PostgreSQL 12 是一次硬分水岭——recovery.conf从这一版开始彻底消失备库标识改由postgresql.conf里的standby_mode相关项和standby.signal文件共同决定。你拿一份 10.x 的教程去装 12.x第一步复制实例就卡住因为备库目录里根本不该有那个文件。2.1 PostgreSQL 与 pgpool-II 的版本对照表文档给了两套环境我把它整理成能直接照着选的表。核心原则只有一条主库、备库的 PostgreSQL 版本必须完全一致pgpool-II 选对应大版本线别混搭。组件旧版本方案新版本方案选择建议操作系统CentOS 6.5CentOS 7.5新部署直接上 7.x6.x 的 systemd 与依赖源都难搞PostgreSQL10.312.212 及以上不再有 recovery.conf配置思路要换pgpool-II3.6.144.1.1跟 PostgreSQL 大版本匹配配置文件项差异很大pg_rman与数据库版本对应与数据库版本对应版本不匹配会直接初始化失败备库标识recovery.confstandby.signal postgresql.conf决定第六章走哪条分支pg_rman 的版本选择是另一个高频坑。它不是独立工具而是深度绑定 PostgreSQL 内部结构的备份工具主库是 12.2 就必须用支持 12 的 pg_rman用错版本初始化备份目录时直接报错退出且错误信息很含糊。常见做法是先去确认数据库的pg_config --version再挑对应分支。2.2 关闭防火墙、SELinux 与网络参数装之前先把系统层的拦路虎清掉。流复制要走 TCP 传 WALpgpool 还要额外的心跳和虚拟 IP 检测端口防火墙和 SELinux 不关现象就是主库能连、备库起不来、pgpool 后端全 down而且日志里往往只有一句模糊的认证失败。# 关闭防火墙并禁止开机自启 systemctl stop firewalld systemctl disable firewalld # 临时关闭 SELinux同时改配置文件防止重启后恢复 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 确认状态enforcing 变成 permissive/disabled 才算生效 getenforce这里setenforce 0只管当前运行态重启就回到 enforcing所以必须同时改/etc/selinux/config。生产环境如果你坚持保留 SELinux那就得为 PostgreSQL 数据目录、pgpool 运行时目录单独打策略标签工作量不小文档方案直接选择关闭我一般也照这个来先把集群跑通再谈加固。接着是网络与主机名解析。两个节点必须能互相用主机名 ping 通因为后续pg_hba.conf、primary_conninfo、pgpool 的backend_hostname全都要写主机名或固定 IP写错了就是连接被拒。# 两台节点分别设置示例用 node1 / node2 hostnamectl set-hostname node1 # /etc/hosts 追加两行主备都要加保证双向解析 cat /etc/hosts EOF 192.168.10.11 node1 192.168.10.12 node2 EOF # 验证两个方向都要通 ping -c 2 node2/etc/hosts这一项看着琐碎但它是后面 SSH 免密、流复制连接、pgpool 健康检查的共同基础。地址一旦和实际网卡不一致主库pg_hba.conf里写的网段就对不上报错会跑到认证那一层去非常容易被误判成密码问题。2.3 时钟同步、sysctl 与 limit 资源分配主备时钟不同步会让 WAL 时间戳、日志排查、pg_rman 备份恢复点全都乱套出故障时你根本对不齐两边发生了什么。文档要求配置节点间时钟同步最省事的做法是两边都对准同一个时间源或者内网起一个时间服务互相校时。# 安装并启用时间同步服务指向内网时间服务器 yum install -y chrony sed -i s/^server .*/server 192.168.10.1 iburst/ /etc/chrony.conf systemctl enable --now chronyd # 查看同步状态确认已和源对上 chronyc sources -viburst让首次同步更快避免刚开机时几十秒的偏差。接下来是内核参数流复制和连接池对共享内存、信号量、最大文件描述符都有要求sysctl不改典型现象是备库启动报could not create shared memory segment或者 pgpool 连接一多就too many open files。# /etc/sysctl.d/99-pgsql.conf 追加关键参数 cat /etc/sysctl.d/99-pgsql.conf EOF kernel.shmmax 68719476736 kernel.shmall 4294967296 kernel.sem 4096 2147483647 2147483646 512000 fs.file-max 7672460 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 EOF sysctl -p /etc/sysctl.d/99-pgsql.confkernel.shmmax决定单块共享内存上限PostgreSQL 的shared_buffers调大后如果超过它实例直接起不来kernel.sem四个值分别是信号量单组上限、系统上限、单次操作上限、信号量总数设小了并行查询和大量连接会互相抢资源。最后是用户级资源限制在/etc/security/limits.conf里给 postgres 用户放开文件句柄和进程数。# /etc/security/limits.conf 追加限定 postgres 用户 cat /etc/security/limits.conf EOF postgres soft nofile 65535 postgres hard nofile 65535 postgres soft nproc 16384 postgres hard nproc 16384 EOFnofile决定单进程能开多少文件描述符每个数据库连接、每个 WAL 段都是一次文件打开连接池时代这个值给低了会在压测时突然爆掉。改完 limits 要重新登录才生效用su - postgres进去ulimit -n确认别只改不验。3. 装 PostgreSQL建用户、解压与初始化主备实例前置清理干净之后PostgreSQL 本身的安装其实不复杂麻烦的是主备两台的用户、目录、权限、环境变量必须一模一样任何一边手抖后面复制实例就会失败在权限上。3.1 创建 postgres 用户与统一安装目录数据库不能用 root 跑这是硬规矩。文档要求在主备两台都创建 postgres 用户并设密码然后把下载的 PostgreSQL、pgpool-II、pg_rman 安装文件放到固定目录。# 主备两台都执行创建用户、设置密码 useradd postgres echo postgres | passwd --stdin postgres # 建立统一的软件目录与数据目录 mkdir -p /opt/soft /opt/pgsql /data/pgdata chown -R postgres:postgres /opt/soft /opt/pgsql /data/pgdata chmod -R 755 /opt/soft # 确认属主两台的输出必须一致 ls -ld /opt/pgsql /data/pgdata这里/opt/soft放安装包、/opt/pgsql是安装目标路径、/data/pgdata是数据目录三者分开的好处是将来升级或重建实例时数据不受影响。权限上我一般把软件目录设 755、数据目录 700数据目录里全是 WAL 和表文件不能让其他用户随便进。两台的目录结构必须完全对称否则备库pg_basebackup时的路径会和主库primary_conninfo里写的归档路径对不上。接着装依赖包。PostgreSQL 编译或运行时依赖 readline、zlib、gcc 等CentOS 7 下一条 yum 解决。# 主备都装编译与运行依赖 yum install -y gcc gcc-c make readline-devel zlib-devel \ openssl-devel pam-devel libxml2-devel libcurl-devel # 解压源码包到软件目录 cd /opt/soft tar -zxvf postgresql-12.2.tar.gz依赖装不全的典型报错是configure: error: readline library not found看着像缺库实际是缺-devel包。文档给的是源码安装路线好处是路径可控、pg_rman 编译时也能直接找到pg_config。3.2 编译安装与环境变量配置编译参数不用堆太多关键是--prefix要和后面环境变量里写的一致。cd /opt/soft/postgresql-12.2 ./configure --prefix/opt/pgsql --with-pgport5432 --with-openssl make -j4 make install # 确认安装产物 ls /opt/pgsql/bin | head--prefix是安装根路径--with-pgport定默认端口--with-openssl供后续加密连接使用。make -j4按核数并行编机器核少就减到-j2编到一半 OOM 反而是更高频的翻车。装完把环境变量写进 postgres 用户的.bash_profile两台节点内容保持一致。# 切到 postgres 用户写入环境变量 su - postgres cat ~/.bash_profile EOF export PGHOME/opt/pgsql export PGDATA/data/pgdata export PATH$PGHOME/bin:$PATH export LD_LIBRARY_PATH$PGHOME/lib:$LD_LIBRARY_PATH export MANPATH$PGHOME/share/man:$MANPATH EOF source ~/.bash_profile which psqlPGDATA必须显式导出pg_ctl、pg_basebackup、pg_rman都靠它定位实例。LD_LIBRARY_PATH少了会在运行 pgpool 时找不到libpq报error while loading shared libraries这类错误信息完全没提 PostgreSQL新手很容易往系统库方向查错。3.3 主库初始化与启动验证主库先初始化。initdb的参数决定字符集和校验方式初始化之后再改代价极大这两项在装之前就要定好。# 主库执行初始化指定编码与本地化 initdb -D /data/pgdata -E UTF8 --localeC -U postgres # 启动主库实例 pg_ctl -D /data/pgdata -l /data/pgdata/startup.log start # 验证是否真的起来了 psql -c select version();-E UTF8是编码--localeC避免排序规则在不同节点上出现差异这一点在主备环境里很重要——排序规则不一致同一个查询在两台可能返回不同顺序读写分离时应用会以为数据错乱。启动日志我习惯单独落到startup.log出问题第一眼看它比翻系统日志快。psql能返回版本号主库这半边就算立住了。4. 配置流复制主库参数、备库克隆与 12.x 的标识变更这一章是整篇文章最容易翻车的地方也是最值得慢下来的地方。流复制的本质是主库把 WAL 通过 TCP 推给备库备库的walreceiver收下来写本地startup进程再重放。配置上要打通三件事主库允许备库连、主库愿意发 WAL、备库知道自己是备库。4.1 主库 postgresql.conf 与 pg_hba.conf先配 SSH 免密后面pg_basebackup和运维脚本都要用早配早省事。# postgres 用户下执行两台互信 ssh-keygen -t rsa -N -f ~/.ssh/id_rsa ssh-copy-id postgresnode2 ssh postgresnode2 hostname-N 表示空密码方便脚本调用最后一条命令能打印出 node2 的主机名说明免密通了。不通就是authorized_keys权限问题.ssh目录必须 700、authorized_keys必须 600。接下来改主库配置。以下是 12.x 的关键项10.x 大部分相同差在备库标识。# 主库 postgresql.conf 需要调整的项 wal_level replica max_wal_senders 10 wal_keep_segments 512 hot_standby on synchronous_commit on synchronous_standby_names node2 listen_addresses *wal_level replica是流复制的最低要求它保证 WAL 里包含备库重放所需的信息max_wal_senders是并发发送 WAL 的连接数给 10 够用压测场景可以再高wal_keep_segments决定主库保留多少旧 WAL 段备库短暂断连时靠它续上设太小会直接导致备库落后太多无法追平只能重做基础备份synchronous_commit on配合synchronous_standby_names就打开了同步复制。这里有个取舍改成同步复制后每次事务提交都要等备库确认写延迟会明显上升如果业务对写入延迟敏感就保持异步接受主库崩溃时可能丢最后几秒数据。访问控制文件同样必须改不然备库连过来直接被拒。# 主库 pg_hba.conf 追加允许备库与本地连接 host replication all 192.168.10.0/24 md5 host all all 192.168.10.0/24 md5 local all all trust第一行专给复制连接第二行给普通业务连接网段要和你实际网卡一致。改完pg_ctl reload让配置生效然后建一个复制专用账号。-- 主库执行创建复制用户 CREATE ROLE repl WITH REPLICATION LOGIN PASSWORD repl_pass;REPLICATION是专用权限比给超级用户安全得多。常见错误是建了普通账号然后pg_basebackup报权限不足错误信息只说连接被拒看不出是权限类型不对。4.2 用 pg_basebackup 克隆备库并区分版本标识备库不需要initdb直接从主库拉一份基础备份这是最稳的做法。差别就在版本分支上。# 12.x 备库执行直接克隆-R 自动写 standby.signal 和 primary_conninfo pg_basebackup -h node1 -D /data/pgdata -U repl -F p -X stream -P -R # 10.x 备库执行克隆后手工准备 recovery.conf pg_basebackup -h node1 -D /data/pgdata -U repl -F p -X stream -P-F p是普通文件格式-X stream表示 WAL 随备份流一起传-P显示进度-R是 12.x 的关键参数它会自动生成standby.signal并把primary_conninfo写进postgresql.conf。10.x 没有-R要自己写recovery.conf# 仅 10.x在备库数据目录创建 recovery.conf cat /data/pgdata/recovery.conf EOF standby_mode on primary_conninfo hostnode1 port5432 userrepl passwordrepl_pass trigger_file /data/pgdata/trigger EOF chown postgres:postgres /data/pgdata/recovery.confprimary_conninfo里的账号密码和主机名必须和主库实际一致trigger_file是手动提升备库用的标记文件。12.x 用户完全不需要这个文件反而要注意如果备库目录里残留了recovery.conf实例启动会直接报错拒绝这是版本迁移时最隐蔽的坑。4.3 启动备库并检查复制状态启动顺序别搞反先主后备等主库pg_isready返回正常再动备库。# 备库启动实例 pg_ctl -D /data/pgdata -l /data/pgdata/standby.log start # 主库查看复制状态 psql -c select client_addr, state, sync_state, sent_lsn, replay_lsn from pg_stat_replication;这条查询是判断流复制成没成的唯一标准。state必须是streamingsync_state在同步模式下是sync异步是async。如果查不到任何行说明备库根本没连上去备库看日志最常见的是primary_conninfo里密码错或pg_hba.conf没放行。如果state是catchup说明正在追 WAL等一会儿就会转streaming只要replay_lsn在往前推进就正常。再在备库验证一下只读和延迟# 备库执行确认可读且处于恢复状态 psql -c select pg_is_in_recovery(); psql -c select now() - pg_last_xact_replay_timestamp() as delay;pg_is_in_recovery()返回t才是备库返回f说明它已经变成独立主库了。delay是回放延迟通常几毫秒到一两秒如果持续变大多半是网络或备库 IO 跟不上。5. pgpool-II 安装配置连接池、读写分离与健康检查流复制通了之后pgpool-II 才登场。它夹在客户端和数据库之间负责连接池复用、把 SELECT 分发到备库、探测后端节点健康状态以及在主库挂掉时配合脚本做故障转移。它的配置文件项多但真正决定能不能跑通的就那几组。5.1 安装 pgpool-II 与注册 SQL 函数pgpool-II 依赖 PostgreSQL 的客户端库编译时要用--with-pgsql指向 PostgreSQL 安装路径。cd /opt/soft/pgpool-II-4.1.1 ./configure --prefix/opt/pgpool --with-pgsql/opt/pgsql make -j4 make install--with-pgsql是关键指错了会编出连不上数据库的二进制。装完要把 pgpool 的库路径加进环境变量并且要把它的扩展函数注册到主库。# postgres 用户环境变量追加主备都加 export PGHOME_POOL/opt/pgpool export PATH$PGHOME_POOL/bin:$PATH export LD_LIBRARY_PATH$PGHOME_POOL/lib:$LD_LIBRARY_PATH # 在主库注册 pgpool 需要的函数 psql -f /opt/pgpool/share/pgpool-II-4.1.1/health_check_2nd.sql5.2 pgpool.conf 的三个核心区段配置文件分三块看连接池与后端节点、读写分离、健康检查与故障转移。以下是新版本的关键项。# pgpool.conf 关键项 listen_addresses * port 9999 backend_hostname0 node1 backend_port0 5432 backend_weight0 1 backend_flag0 ALWAYS_PRIMARY backend_hostname1 node2 backend_port1 5432 backend_weight1 1 backend_flag1 DISALLOW_TO_FAILOVERbackend_flag决定故障转移行为。ALWAYS_PRIMARY告诉 pgpool 这个节点固定当主库DISALLOW_TO_FAILOVER表示备库不做提升规避保证主备角色稳定不乱。backend_weight是读请求权重两台都设 1 就是均分。# 读写分离与健康检查 load_balance_mode on master_slave_mode on master_slave_sub_mode stream health_check_period 10 health_check_timeout 20 health_check_user pgpool_check health_check_password check_pass failover_command /opt/pgpool/bin/failover.sh %d %Hload_balance_mode on打开读写分离pgpool 会把不在事务里的 SELECT 发到备库写和事务内的查询走主库。master_slave_sub_mode stream明确告诉它底层是流复制这决定它判断主备身份的方式。health_check_period是健康检查间隔秒数10 秒一次比较均衡health_check_timeout给 20 秒避免网络抖动误判。健康检查账号要在两台数据库都建好否则节点会被误标为 down。failover_command里%d是失效节点编号%H是新主库主机名。5.3 认证文件与运行时目录pgpool 有自己的认证层pool_hba.conf管客户端怎么连它pool_passwd管数据库密码怎么存。# 生成 pool_passwd为 postgres 用户写入密码 pg_md5 --md5auth -u postgres -p # 按提示输入密码自动写入 pool_passwd # pool_hba.conf 放行客户端网段 echo host all all 192.168.10.0/24 md5 /etc/pgpool/pool_hba.conf # 创建运行时目录pgpool 的 pid 和状态文件都放这 mkdir -p /var/run/pgpool chown -R postgres:postgres /var/run/pgpoolpool_passwd里存的是 MD5 后的密码客户端连 pgpool 时由它做第一道认证认证过了再用配置里的账号连后端。运行时目录不建pgpool 启动会报could not create pid file这个错误跟数据库一点关系都没有却很常见。5.4 启动 pgpool 并连接测试启动顺序是先数据库后 pgpoolpgpool 起来后要立刻验证节点状态。# 主备两台分别启动 pgpool pgpool -n -D /var/log/pgpool/pgpool.log 21 # 查看节点状态 psql -h node1 -p 9999 -c show pool_nodes;show pool_nodes输出里每个节点有status、role两列status必须是uprole一台primary一台standby。如果显示down先看 pgpool 日志里健康检查的报错九成是健康检查账号密码不对或者后端节点的pg_hba.conf没放行 pgpool 所在地址。psql -h node1 -p 9999走的才是 pgpool 的 9999 端口直接连 5432 测不出问题。6. 避坑记录这套组合最常见的五个翻车点下面几条是我和同行在这套环境里真实踩过的每条按现象、原因、解决写对号入座比查文档快。第一个备库启动直接失败日志一句recovery.conf相关报错。现象是 12.x 备库pg_ctl start立刻退出。原因是升级或沿用了旧教程备库目录里留了recovery.conf12.x 已废弃该文件存在即报错。解决是先删掉它确认standby.signal存在并且postgresql.conf里有正确的primary_conninfo。第二个show pool_nodes两个节点全 down。现象是客户端报all backend nodes are down。原因通常有两个健康检查账号没建或密码错或者 pgpool 启动时后端还没就绪配置又不允许自动重连。解决是先确认health_check_user能在两台库上正常登录再重启 pgpool 观察日志而不是反复重启数据库。第三个no pg_hba.conf entry for host。现象是备库或 pgpool 连数据库被拒。原因是pg_hba.conf里写的网段和实际地址不符或者只加了普通连接忘了复制专用行。解决是对照实际 IP 逐一补齐host replication那行单独检查改完reload而不是restart。第四个同步复制打开后写入变慢压测直接超时。现象是事务提交响应时间翻倍。原因是synchronous_commit on且备库回放跟不上主库的每次提交都在等确认。解决是评估业务能否接受异步能接受就把synchronous_commit改回off或者只保留remote_write级别不能接受就先把备库 IO 和网络调好。第五个故障切换测试时虚拟 IP 没漂移。现象是主库进程停了pgpool 检测到但客户端连的还是旧地址。原因是 watchdog 和虚拟 IP 相关配置不完整或者failover_command脚本没有执行权限。解决是按日志顺序检查 watchdog 状态、脚本权限和 ip 漂移命令的实际执行结果别只看 pgpool 有没有报错。7. 装完怎么验证从模拟宕机到备份恢复的收尾动作环境跑起来不等于高可用成立。我的习惯是装完必须走一遍验证清单验证不通过就当没装完。下面这套动作覆盖主从、pgpool 负载、故障切换和备份恢复四层。第一步确认复制是活的而不是假活# 主库写一条立即到备库查 psql -h node1 -p 5432 -c create table if not exists t_verify(id int, ts timestamp); insert into t_verify values(1, now()); psql -h node2 -p 5432 -c select * from t_verify; # 主库看复制状态 psql -h node1 -p 5432 -c select state, sync_state, replay_lsn from pg_stat_replication;备库能查到刚插入的行且state为streaming说明数据链路是通的。这一步不要省略有时候备库能查表只是因为基础备份里有旧数据实际复制早就断了。第二步确认读写分离真的在分发# 连续多次走 pgpool 执行读观察是否落到备库 for i in $(seq 1 20); do psql -h node1 -p 9999 -c select inet_server_addr(); -t done | sort | uniq -cinet_server_addr()返回的是实际处理查询的数据库地址正常情况下应该看到主库和备库的地址都出现。如果全是同一个地址检查load_balance_mode是否打开、查询是否被包在事务里——事务内的 SELECT 一律走主库。第三步模拟主库宕机验证切换# 停掉主库数据库进程 pg_ctl -D /data/pgdata stop -m fast # 观察 pgpool 日志与节点状态 psql -h node1 -p 9999 -c show pool_nodes;停主库进程后pgpool 的健康检查会在一个周期内发现异常并触发failover_command。show pool_nodes里原主库变成down备库角色应被提升。这里要提醒一句切换成功只代表探测和脚本有效应用端连接串必须能容忍重连否则数据库切换了应用还在用旧连接池。第四步验证 pg_rman 备份能恢复。备份不是有文件就算数要能恢复到某个时间点。# 初始化备份目录并做一次全备 pg_rman init -B /data/pgrman -D /data/pgdata pg_rman backup -B /data/pgrman -D /data/pgdata -b full pg_rman validate -B /data/pgrman # 查看备份列表 pg_rman show -B /data/pgrman-b full是全量备份validate校验备份文件完整性show列出可用备份。pg_rman依赖归档模式在postgresql.conf里要打开archive_mode on并配好archive_command否则备份出来的东西没法做时间点恢复。备份做完了挑一台恢复环境实际restore一次能起来、数据在才算这层验证过关。验证层级检查命令通过标准流复制select state from pg_stat_replication返回 streaming只读查询备库select * from t_verify能查到主库新写入数据读写分离inet_server_addr()多次采样主备地址都出现故障切换停主库后show pool_nodes原主库 down备库提升备份恢复pg_rman show与恢复演练备份可校验、能恢复启动这套清单我每次部署完都强制走一遍尤其是最后一项恢复演练很多人备了半年从没恢复过真出事才发现归档断了。从那以后我每次上这套组合都把「停一次主库、恢复一次备份」写进交付步骤里不跑完不算交。希望帮到你。本文还有配套的精品资源点击获取