「PostgreSQL架构」为啥RDBMS是分布式数据库的未来

Posted 2023-04-02

参考技术A 大约10年前，我加入了Amazon Web Services，在那里我第一次看到了在分布式系统中进行权衡的重要性。在大学里，我已经了解了一致性和可用性之间的权衡（CAP定理），但实际上，频谱要比这深得多。任何设计决策都可能涉及延迟，并发性，可伸缩性，耐用性，可维护性，功能性，操作简便性以及系统其他方面之间的权衡，而这些权衡会对应用程序的功能和用户体验产生有意义的影响，并且即使是业务本身的有效性。

也许在权衡需求最明显的分布式系统中最具挑战性的问题是构建分布式数据库。当应用程序开始需要可以在许多服务器上扩展的数据库时，数据库开发人员开始做出极端的权衡。为了在许多节点上实现可伸缩性，分布式键值存储（NoSQL）抛弃了传统关系数据库管理系统（RDBMS）提供的丰富功能集，包括SQL，联接，外键和ACID保证。由于每个人都想要可伸缩性，因此RDBMS消失只是时间问题，对吗？实际上，关系数据库继续主导着数据库领域。这就是为什么：

在分布式系统（或任何系统）中进行权衡时，要考虑的最重要方面是开发成本。

数据库软件所做出的权衡将对应用程序的开发成本产生重大影响。在高级应用程序中处理需要可用性，可靠性和性能的数据是一个固有地需要解决的问题。成功解决每个小问题所需的工时数量可能很大。幸运的是，数据库可以解决许多这些子问题，但是数据库开发人员也面临成本问题。实际上，要使数据库足以满足大多数应用程序的功能，保证和性能，就需要数十年的时间。那就是建立关系数据库如PostgreSQL和mysql的地方。

在Citus Data，我们从不同角度解决了数据库可伸缩性的需求。我和我的团队在过去的几年中花费了很多时间将已建立的RDBMS转换为分布式数据库，而又不会失去其强大功能或从基础项目中分叉。通过这样做，我们发现RDBMS是构建分布式数据库的理想基础。

使RDBMS对开发应用程序（尤其是开源RDBMS，尤其是云RDBMS）如此吸引人的原因在于，您可以有效地利用数十年来对RDBMS进行的工程投资，并利用这些RDBMS功能。您的应用，降低了开发成本。

RDBMS为您提供：

这些功能几乎对任何非平凡的应用都很重要，但是要花很长时间才能开发。另一方面，某些应用程序的工作量对于单台计算机来说太过苛刻，因此需要水平可伸缩性。

许多新的分布式数据库正在开发中，并且正在分布式键值存储（“ NewSQL”）之上实现RDBMS功能，例如SQL。尽管这些较新的数据库可以使用多台计算机的资源，但是在SQL支持，查询性能，并发性，索引，外键，事务，存储过程等方面，它们仍远未建立在关系数据库系统上。您遇到许多要在应用程序中解决的复杂问题。

许多大型互联网公司采用的替代方法是RDBMS的手动，应用程序层分片（通常是PostgreSQL或MySQL）。手动分片意味着有许多RDBMS节点，并且应用程序会根据某种条件（例如，用户ID）决定连接到哪个节点。应用程序本身负责如何处理数据放置，架构更改，查询多个节点，复制表等，因此，如果执行手动分片，最终将在应用程序中实现自己的分布式数据库，这可能甚至更多。昂贵。

幸运的是，有一种方法可以解决开发成本难题。

PostgreSQL已有数十年的发展 历史 ，其令人难以置信的重点是代码质量，模块化和可扩展性。这种可扩展性提供了一个独特的机会：无需分叉就可以将PostgreSQL转换为分布式数据库。这就是我们构建Citus的方式。

大约5年前，当我加入一家名为Citus Data的初创公司时，我为在竞争激烈的市场中建立高级分布式数据库而无任何现有基础架构，品牌知名度，进入市场，资本或大量工程师的挑战感到沮丧 。 仅开发成本就似乎是无法克服的。 但是，就像应用程序开发人员利用PostgreSQL来构建复杂的应用程序一样，我们利用PostgreSQL来构建……分布式PostgreSQL。

我们创建了Citus，这是开源的PostgreSQL扩展，而不是从头开始创建分布式数据库，它以提供水平扩展的方式透明地分发表和查询，但是应用程序开发人员需要具备所有PostgreSQL功能才能成功。

通过使用在计划查询时Postgres调用的内部挂钩，我们能够将分布式表的概念添加到Postgres。

分布式表的分片存储在具有所有现有功能的常规PostgreSQL节点中，Citus发送常规SQL命令以查询分片，然后合并结果。 我们还添加了参考表的概念，该参考表可在所有节点上复制，因此可以通过任何列与分布式表连接。 通过进一步增加对分布式事务，查询路由，分布式子查询和CTE，序列，更新等的支持，我们达到了最先进的PostgreSQL功能可以使用的规模，但现在已经可以大规模使用。

Citus相对来说还很年轻，但是已经建立在PostgreSQL之上，已经成为世界上最先进的分布式数据库之一。与PostgreSQL的完整功能集相比，这令人毛骨悚然，还有许多工作要做，Citus现在提供的功能及其扩展方式使其在分布式数据库环境中具有很大的独特性。许多当前的Citus用户最初使用Postgres中的许多高级功能在单节点PostgreSQL服务器上建立业务，然后仅用几周的开发工作就迁移到Citus，以将其数据库模式转换为分布式表和引用表。对于任何其他数据库，从单节点数据库到分布式数据库的这种迁移可能要花费数月甚至数年的时间。

像PostgreSQL这样的RDBMS具有几乎无限的功能和成熟的SQL引擎，可让您以多种方式查询数据。当然，这些功能只有在速度很快时才对应用程序有用。幸运的是，PostgreSQL很快，并且通过诸如实时查询编译之类的新功能不断提高，但是当您拥有大量数据或流量以至于一台机器速度太慢时，那些强大的功能就不再那么有用了……除非您可以结合许多计算机的计算能力。这就是功能成为超级大国的地方。

通过采用PostgreSQL功能并进行扩展，Citus具有许多超级功能，这些功能使用户可以将数据库扩展到任意大小，同时保持高性能及其所有功能。

尽管大多数这些功能对于开发需要扩展的复杂应用程序来说似乎都是必不可少的，但并不是所有分布式数据库都支持它们。下面我们根据公开提供的文档对一些流行的分布式数据库进行比较。

与在分布式数据库中拥有超级功能相比，更重要的是能够组合数据库超级功能来解决复杂的用例。

由于支持查询路由，参考表，索引，分布式事务和存储过程，因此即使最先进的多租户OLTP应用程序（例如Copper）也可以使用Citus扩展到单个PostgreSQL节点之外，而不会在应用程序中做出任何牺牲。

如果将子查询下推与并行的分布式DML结合使用，则可以在数据库内部转换大量数据。一个常见的示例是使用INSERT…SELECT构建汇总表，该表可以并行化以适应任何类型的数据量。结合通过COPY，索引，联接和分区进行的批量加载，您将拥有一个非常适合时间序列数据和实时分析应用程序（如Algolia仪表板）的数据库。

正如Microsoft的Min Wei在谈到Microsoft如何使用Citus和PostgreSQL分析Windows数据时指出的那样：Citus使您能够使用分布式OLTP解决大规模OLAP问题。

Citus与其他分布式数据库有些不同，后者通常是从头开始开发的。 Citus没有引入PostgreSQL中尚未提供的任何功能。 Citus数据库以满足需要扩展的用例的方式扩展了现有功能。重要的是，大多数PostgreSQL功能已经针对各种用例进行了数十年的开发和测试，而当今用例的功能要求最终并没有太大不同；主要是数据的规模和大小不同。因此，在构建现代应用程序时，基于世界上最先进的开源RDBMS（PostgreSQL！）构建的分布式数据库（如Citus）可以成为您的武器库中最强大的工具。

原文：https://www.citusdata.com/blog/2018/11/30/why-rdbms-is-the-future-of-distributed-databases/

本文：http://jiagoushi.pro/node/929

讨论：请加入知识星球或者微信圈子【首席架构师圈】

一文看懂分布式数据库原理和 PostgreSQL 分布式架构

【作者】魏波，中国PostgreSQL分会培训认证总监。十多年的数据库运维从业经验，掌握DB2/PostgreSQL，关注开源技术，目前主要负责完善培训认证体系、运营推广，PG社区技术内容组织等工作。

一、 什么是分布式数据库

分布式系统数据库系统原理（第三版）中的描述：“我们把分布式数据库定义为一群分布在计算机网络上、逻辑上相互关联的数据库。分布式数据库管理系统（分布式DBMS）则是支持管理分布式数据库的软件系统，它使得分布对于用户变得透明。有时，分布式数据库系统（Distributed Database System,DDBS）用于表示分布式数据库和分布式DBMS这两者。”

在以上表述中，“一群分布在网络上、逻辑上相互关联”是其要义。在物理上一群逻辑上相互关联的数据库可以分布式在一个或多个物理节点上。当然，主要还是应用在多个物理节点。这一方面是X86服务器性价比的提升有关，另一方面是因为互联网的发展带来了高并发和海量数据处理的需求，原来的单物理服务器节点不足以满足这个需求。

分布式不只是体现在数据库领域，也与分布式存储、分布式中间件、分布式网络有着很多关联。最终目的都是为了更好的服务于业务需求的变更。从哲学意义上理解是一种生产力的提升。

二、 分布式数据库理论基础

1． CAP理论

首先，分布式数据库的技术理论是基于单节点关系数据库的基本特性的继承，主要涉及事务的ACID特性、事务日志的容灾恢复性、数据冗余的高可用性几个要点。

其次，分布式数据的设计要遵循CAP定理，即：一个分布式系统不可能同时满足 一致性（ Consistency ） 、可用性 （ Availability ） 、分区容 忍 性 （ Partition tolerance ） 这三个基本需求，最 多只能同时满足其中的两项， 分区容错性 是不能放弃的，因此架构师通常是在可用性和一致性之间权衡。这里的权衡不是简单的完全抛弃，而是考虑业务情况作出的牺牲，或者用互联网的一个术语“降级”来描述。

针对CAP理论，查阅了国外的相关文档表述，CAP理论来源于2002年麻省理工学院的Seth Gilbert和Nancy Lynch发表的关于Brewer猜想的正式证明。

CAP 三个特性描述如下 ：

一致性：确保分布式群集中的每个节点都返回相同的 、 最近 更新的数据 。一致性是指每个客户端具有相同的数据视图。有多种类型的一致性模型 ， CAP中的一致性是指线性化或顺序一致性，是强一致性。

可用性：每个非失败节点在合理的时间内返回所有读取和写入请求的响应。为了可用，网络分区两侧的每个节点必须能够在合理的时间内做出响应。

分区容忍性：尽管存在网络分区，系统仍可继续运行并 保证 一致性。网络分区已成事实。保证分区容忍度的分布式系统可以在分区修复后从分区进行适当的恢复。

原文主要观点有在强调CAP理论不能简单的理解为三选二。

在分布式数据库管理系统中，分区容忍性是必须的。网络分区和丢弃的消息已成事实，必须进行适当的处理。因此，系统设计人员必须在一致性和可用性之间进行权衡 。简单地说，网络分区迫使设计人员选择完美的一致性或完美的可用性。在给定情况下， 优秀 的分布式系统会根据业务对一致性和可用性需求的重要等级提供最佳的答案，但通常一致性需求等级会更高，也是最有挑战的 。

2． BASE理论

基于CAP定理的权衡，演进出了 BASE理论 ，BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

BA：Basically Available 基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

S：Soft State 软状态，允许系统存在中间状态，而该中间状态不会影响系统整体可用性。

E：Consistency 最终一致性，系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

BASE 理论本质上是对 CAP 理论的延伸，是对 CAP 中 AP 方案的一个补充。

这里补充说明一下什么是强一致性：

Strict Consistency （ 强一致性 ） 也称为Atomic Consistency （ 原子一致性） 或 Linearizable Consistency（线性一致性） ，必须满足以下 两个要求：

1、任何一次读都能读到某个数据的最近一次写的数据。

2、系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。

对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。简言之，在任意时刻，所有节点中的数据是一样的。

BASE 理论的最终一致性属于弱一致性。

接下来介绍另一个分布式数据库重要的概念：分布式事务。浏览了几篇介绍分布式事务的文章，发现会有不同的描述，但大致含义是相同的。分布式事务首先是事务， 需要满足事务的ACID的特性。主要考虑业务访问处理的数据分散在网络间的多节点上，对于分布式数据库系统而言， 在保证数据一致性的要求下，进行事务的分发、协同多节点完成业务请求。

多节点能否正常、顺利的协同作业完成事务是关键，它直接决定了访问数据的一致性和对请求响应的及时性。从而就需要科学有效的一致性算法来支撑。

3． 一致性算法

目前主要的 一致性算法 包括 ：2PC 、 3PC 、 Paxos 、 Raft 。

2PC ：Two-Phase Commit （ 二阶段提交 ） 也被认为是一种一致性协议，用来保证分布式系统数据的一致性。绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理。

主要包括以下两个阶段：

第一阶段：提交事务请求（投票阶段）

第二阶段：执行事务提交（执行阶段）

优点：原理简单、实现方便

缺点：同步阻塞、单点问题、数据不一致、太过保守

3PC ：Three- Phase Commi （ 三阶段提交 ）包括 CanCommit、PreCommit、doCommit 三个阶段。

为了避免在通知所有参与者提交事务时，其中一个参与者 crash 不一致时，就出现了三阶段提交的方式。

三阶段提交在两阶段提交的基础上增加了一个 preCommit 的过程，当所有参与者收到 preCommit 后，并不执行动作，直到收到 commit 或超过一定时间后才完成操作。

优点：降低参与者阻塞范围，并能够在出现单点故障后继续达成一致 缺点：引入 preCommit 阶段，在这个阶段如果出现网络分区，协调者无法与参与者正常通信，参与者依然会进行事务提交，造成数据不一致。

2PC / 3PC 协议用于保证属于多个数据分片上操作的原子性。

这些数据分片可能分布在不同的服务器上，2PC / 3PC 协议保证多台服务器上的操作要么全部成功，要么全部失败。

Paxos 、 Raft 、 Zab 算法用于保证同一个数据分片的多个副本之间的数据一致性 。以下是三种算法的概要描述 。

Paxos 算法主要解决数据分片的单点问题 ， 目的是让整个集群的结点对某个值的变更达成一致。Paxos （强一致性） 属于多数派算法 。任何一个点都可以提出要修改某个数据的提案，是否通过这个提案取决于这个集群中是否有超过半数的结点同意，所以 Paxos 算法需要集群中的结点是单数 。

Raft 算法是简化版的Paxos， Raft 划分成三个子问题：一是Leader Election；二是 Log Replication；三是Safety。Raft 定义了三种角色 Leader、Follower、Candidate，最开始大家都是Follower，当Follower监听不到Leader，就可以自己成为Candidate，发起投票 ，选出新的leader 。

其有两个基本过程：

① Leader选举：每个 C andidate随机经过一定时间都会提出选举方案，最近阶段中 得 票最多者被选为 L eader。

② 同步log：L eader会找到系统中log（各种事件的发生记录）最新的记录，并强制所有的follow来刷新到这个记录。

Raft一致性算法是通过选出一个leader来简化日志副本的管理，例如，日志项（log entry）只允许从leader流向follower。ZAB基本与 raft 相同。

三、PostgreSQL 分布式架构一览

PostgreSQL发展时间线及分支图

1． 基于内核分布式方案 Postgres-XL

（1） 什么是Postgres-XL

Postgres-XL是一款开源的PG集群软件，XL代表eXtensible Lattice，即可扩展的PG“格子”之意，以下简称PGXL。

官方称其既适合写操作压力较大的OLTP应用，又适合读操作为主的大数据应用。它的前身是Postgres-XC（简称PGXC），PGXC是在PG的基础上加入了集群功能，主要适用于OLTP应用。PGXL是在PGXC的基础上的升级产品，加入了一些适用于OLAP应用的特性，如 Massively Parallel Processing (MPP) 特性。

通俗的说PGXL的代码是包含PG代码，使用PGXL安装PG集群并不需要单独安装PG。这样带来的一个问题是无法随意选择任意版本的PG，好在PGXL跟进PG较及时，目前最新版本Postgres-XL 10R1，基于PG 10。

社区发展史：

2004~2008 年， NTT Data 构建了模型 Rita-DB

2009 年， NTT Data 与 EnterpriseDB 合作进行社区化开发

2012 年， Postgres-XC 1.0 正式发布

2012 年， StormDB 在 XC 基础上增加 MPP 功能 .

2013 年， XC 1.1 发布 ；TransLattice 收购 StormDB

2014 年， XC 1.2 发布 ；StormDB 开源为 Postgres-XL.

2015 年，两个社区合并为 Postgres-X2

2016 年 2 月， Postgres-XL 9.5 R1

2017年7月 ， Postgres-XL 9.5 R1.6

2018年10月 ， Postgres-XL 10R1

2019 年 2 月 ， 宣布推出Postgres-XL 10R1 .1

PostgreSQL与PGXC对比图（浙江移动谭峰分享）

（2） 技术架构

架构图1
架构图2

从上图可以看出Coordinator和datanode节点可以配置为多个，并且可以位于不同的主机上。只有Coordinator节点直接对应用服务，Coordinator节点将数据分配存储在多个数据节点datanode上。

Postgres-XC主要组件有gtm（Global Transaction Manager） ， gtm_standby ， gtm_proxy, Coordinator 和Datanode。

全局事务节点 ( GTM )， 是Postgres-XC的核心组件，用于全局事务控制以及tuple的可见性控制。gtm 为分配GXID和管理PGXC MVCC的模块 ， 在一个CLUSTER中只能有一台主的gtm。gtm_standby 为gtm的备机 。

主要作用：

– 生成全局唯一的事务ID

– 全局的事务的状态

– 序列等全局信息

gtm_proxy为降低gtm压力而诞生的, 用于对coordinator节点提交的任务进行分组等操作. 机器中可以存在多个gtm_proxy。

协调节点 (Coordinator) 是数据节点 (Datanode) 与应用之间的接口， 负责接收用户请求、生成并执行分布式查询、 把 SQL 语句发给相应的数据节点。

Coordinator 节点并不物理上存储表数据，表数据以分片或者复制的方式分布式存储，表数据存储在数据节点上。当应用发起SQL时，会先到达 Coordinator 节点，然后 Coordinator节点将 SQL分发到各个数据节点，汇总数据，这一系统过程是通过GXID 和Global Snapshot 再 来控制的。

数据节点（datanode）物理上存储表数据，表数据存储方式分为分片（distributed）和完全复制（replicated）两种。数据节点只存储本地的数据。

数据分布

• replicated table 复制表

– 表在多个节点复制

• distributed table 分布式表

– Hash

– Round robin

注释：Round robin 轮流放置是最简单的划分方法：即每条元组都会被依次放置在下一个节点上，如下图所示，以此进行循环。

（3） 主要站点

https://www.postgres-xl.org/overview/
https://wiki.postgresql.org/wiki/Postgres-XC

2． 扩展分布式方案Citus

（1） 什么是Citus

Citus是一款基于PostgreSQL的开源分布式数据库 ， 自动继承了PostgreSQL强大的SQL支持能力和应用生态（不仅是客户端协议的兼容还包括服务端扩展和管理工具的完全兼容）。Citus是PostgreSQL的扩展（not a fork），采用shared nothing架构，节点之间无共享数据，由协调器节点和Work节点构成一个数据库集群。专注于高性能HTAP分布式数据库 。

相比单机PostgreSQL，Citus可以使用更多的CPU核心，更多的内存数量，保存更多的数据。通过向集群添加节点，可以轻松的扩展数据库。

与其他类似的基于PostgreSQL的分布式方案，比如GreenPlum，PostgreSQL-XL相比，Citus最大的不同在于它是一个PostgreSQL扩展而不是一个独立的代码分支。Citus可以用很小的代价和更快的速度紧跟PostgreSQL的版本演进；同时又能最大程度的保证数据库的稳定性和兼容性。

Citus支持新版本PostgreSQL的特性，并保持与现有工具的兼容 。Citus使用分片和复制在多台机器上横向扩展PostgreSQL。它的查询引擎将在这些服务器上执行SQL进行并行化查询，以便在大型数据集上实现实时（不到一秒）的响应。

Citus目前主要分为以下几个版本：

• Citus社区版

• Citus商业版

• Cloud [AWS，citus cloud]

本截图引用2020年3月苏宁陈华军Citus的实践分享

（2） 技术架构

本截图引用2020年3月苏宁陈华军Citus的实践分享

Citus集群由一个中心的协调节点(CN)和若干个工作节点(Worker)构成。

CN只存储和数据分布相关的元数据，实际的表数据被分成M个分片，打散到N个Worker上。这样的表被叫做“分片表”，可以为“分片表”的每一个分片创建多个副本，实现高可用和负载均衡。

架构图1（引用2019年苏宁Citus实践分享）

Citus官方文档更建议使用PostgreSQL原生的流复制做HA，基于多副本的HA也许只适用于append only的分片。

应用将查询发送到协调器节点，协调器处理后发送至work节点。对于每个查询协调器将其路由到单个work节点，或者并行化执行，这取决于数据是否在单个节点上还是在多个节点上。Citus MX模式允许直接对work节点进行访问，进行更快的读取和写入速度。

架构图2（引用2019年苏宁Citus实践分享）

Citus有三种类型表

• 分片表（最常用）

• 参考表

• 本地表

分片表主要解决的是大表的水平扩容问题，对数据量不是特别大又经常需要和分片表Join的维表可以采用一种特殊的分片策略，只分1个片且每个Worker上部署1个副本，这样的表叫做“参考表”。

除了分片表和参考表，还剩下一种没有经过分片的PostgreSQL原生的表，被称为“本地表”。“本地表”适用于一些特殊的场景，比如高并发的小表查询。

本截图引用2020年3月苏宁陈华军Citus的实践分享

客户端应用访问数据时只和CN节点交互。CN收到SQL请求后，生成分布式执行计划，并将各个子任务下发到相 应的Worker节点，之后收集Worker的结果，经过处理后返回最终结果给客户端。

本截图引用2020年3月苏宁陈华军Citus的实践分享

（3） 主要站点

http://citusdb.cn/
https://docs.citusdata.com/en/v8.2/

四、 总结

应对大数据量、高并发混合业务数据访问，数据管理需要分布式数据库架构的有效支撑，以下总结了几个主要关键词：

1． 业务融合——TP/AP业务自动识别，职能调度运算节点；实时流处理；关系与非关系数据访问、转换；

2． 节点协同——多个计算节点协同作业；数据多副本；同城、异地多活；

3． 冷热分离——定期定时统计，自动标记冷热数据，根据存储速度存储不同冷热程度的数据；

4． 架构解耦——微服务、计算存储分离；

5． 弹性伸缩——在线伸缩；自动平衡数据；

6． 智能运维——自动调优；自动升降级；运行可视化，自动告警。

参考资料：

分布式数据库概念：

·《分布式系统数据库系统原理》（第三版）

CAP理论 ：

·《Understanding the CAP Theorem》/ Akhil Mehra

·《CAP和BASE理论》/ ~信~仰~ 

Base理论：

·《终于有人把“分布式事务”说清楚了！》/ 陈明羽

·《强一致性、顺序一致性、弱一致性和共识》/ chao2016

一致性算法：

·《分布式理论系列（二）一致性算法：2PC 到 3PC 到 Paxos 到 Raft 到 Zab》/ binarylei

·《Paxos和Raft快速理解》/ 建怀

PGXL

·《初识Postgres-XL》/ joyeu

Citus

· 博客“小桥河西 ”

·《PostgreSQL中的分库分表解决方案》/ 唐成

（链接请点击阅读原文）

原题：分布式数据库原理及 PostgreSQL 分布式解读

如有任何问题，可点击文末阅读原文，到社区原文下评论交流

觉得本文有用，请转发或点击“在看”，让更多同行看到

社区正在进行“PostgreSQL、Redis等分布式数据库日常运维使用在线答疑”，欢迎参与！

点击以下地址或复制地址到浏览器即可

 资料/文章推荐：

下载 twt 社区客户端 APP

或到应用商店搜索“twt”

长按二维码关注公众号