共计 9456 个字符，预计需要花费 24 分钟才能阅读完成。
导语
随着信息技术的迅猛发展，各行各业产生的数据量呈爆炸式增长，传统集中式数据库的局限性在面对大规模数据处理中逐步露出，分布式数据库应运而生。
分布式数据库是在集中式数据库的根底上倒退起来的，是分布式系统与传统数据库技术联合的产物，可能冲破传统数据库的瓶颈，具备透明性、数据冗余性、易于扩展性等特点，还具备高牢靠、高可用、低成本等劣势。
分布式数据库目前已利用到金融、电信等大数据行业，将来将走向更广大的畛域。上月，InfoQ 与 OceanBase 合办的“数据库 Talk Show”圆桌直播邀请到了 国家工业平安倒退钻研核心软件所副所长李卫，OceanBase 产品和解决方案部高级总监王南，dbaplus 社群联结发起人、OracleACE、竞技世界资深 DBA 杨建荣，携程数据库总监刘博 四位专家，围绕分布式数据库技术路线和产业现状，剖析分布式数据库的技术特点以及面临的问题与挑战，对企业如何进行数据库选型以及行业热议的十个问题开展了精彩的互动探讨，以下为互动的 10 个问题。
- 我国分布式数据库的产业现状如何？
- 分布式数据库最外围解决的问题是什么？
- 用户如何判断哪种技术路线更适宜本人？
- 为什么近些年分布式数据库逐步成为支流商业数据库的抉择？
- 分布式数据库有哪些平安计划能够聊聊？
- 在国内，HTAP 被很多人提及，海内更多是 OLTP 或 OLAP，那么真正的 HTAP 到底是怎么的？
- Hadoop 等于 HDFS 和 MapReduce，分布式数据库里边的 MapReduce 可能是什么样子？
- 分布式数据库的学习门槛如何？
- 分布式数据库选型能够从哪几个方面进行思考？
- 分布式数据库的迁徙过程中应该留神哪些问题？
我国分布式数据库的产业现状如何？
▍李卫：最近几年，分布式数据库在国内倒退较快。一方面，丰盛的数据库利用场景，新一代信息技术与实体经济的深度交融，各行各业的数字化转型，社会全面进入数字经济时代，这些变动都给数据处理和存储的次要核心技术带来了十分好的倒退时机，尤其是随着数据规模的减少，数据应用复杂程度的晋升，原有的集中式数据库曾经慢慢不能满足当初很多场景的须要，分布式数据库成为很多企业必然的抉择。另一方面，分布式数据库因为倒退工夫不是很长，落地实际层面还存在有余。
目前来说，国内次要有三种技术路线可供选择：一是分布式中间件 + 单机数据库，通过在单机数据库系统上进行革新，次要解决了扩展性的问题；二是构建分布式共享存储实现扩大，采纳非对称计算节点，大部分私有云数据库是这条路线；三是原生分布式数据库，从底层设计就采纳分布式架构，是将来很重要的趋势。
当下，国内从事分布式数据库的厂商十分多，这三种技术路线各自存在利用场景，将来随着利用更宽泛的深刻和推广，路线还会进一步收敛，必定会向着第三种路线推动。整体来说，国内的环境和技术需要还是给分布式数据库带来了十分好的机会，甚至将来在分布式数据库畛域，国内在世界上处于引领位置。
▍杨建荣：晚期，分布式数据库对业务的侵入性比拟高，可能须要将一个业务拆分成多个业务模式，而后逐渐演进到绝对一体化的模式，呈现了分布式中间件这种架构模式，现在又呈现了越来越多的原生分布式数据库，技术体系上产生了很大变动，也面临着更多技术挑战，包含技术生态构建以及技术体系迭代层面。
▍王南：如果从数据库厂商和用户，也就是供应端和生产端的角度来讲，分布式数据库的倒退两端并不同步。从数据库厂商的角度来说，分布式数据库曾经走了很长时间，但用户对分布式数据库的认知、承受、应用及运维是有滞后的，当然这是一项技术或者产品倒退的失常过程。随着数字经济的飞速发展，用户对分布式的诉求将越来越强烈，数据库厂商还须要在产品成熟化、产品能力、技术体系的残缺易用以及生态建设层面破费更多工夫。
▍刘博：技术的倒退最终还是业务驱动的。以携程为例，现在的数据量与 2003 年刚上市时相比增长了上百倍甚至上千倍。携程 2018 年就开始尝试分布式数据库，倒退路线也从最后的非核心业务逐步过渡到外围业务。在过渡到外围业务时，咱们也做了一些备份伎俩，比方数据双写等。依据 2019 年的数据统计，国内守业的数据库厂商有 160 多家，数据库产品可能有两百多个，其中分布式产品大略占 40%，处于横蛮成长的阶段。但依据 IDC 的考察，目前真正在外围零碎中部署分布式数据库的比例不是太高。
分布式数据库外围要解决什么？
▍李卫：第一，分布式数据库解决了传统集中式单机数据库期间的问题，单机数据库面对海量数据在解决能力、存储能力、性能等方面都存在瓶颈；第二，分布式数据库须要解决数据一致性的问题，数据跨的节点越多，危险就越高；第三，分布式数据库的高可用能力保障不会因为单点故障而影响整体的可用性，这保障了金融、电信等对高可用需要较高业务的连续性；第四，利用存在波峰波谷，分布式数据库通过灵便扩大的设计做到了老本优化。
▍杨建荣：随着互联网场景快速增长的数据量，咱们须要数据库系统反对程度扩大，这种反对可能是两个方面：数据存储和数据计算。在这个层面上来说，更多的是让数据存储实现程度扩大。实现此的前提则是保障整个分布式数据库的性能、可靠性等有更好的体现。从我理论接触的场景来看，更侧重于解决程度扩大的问题，让扩大形式更优雅。
▍王南：首先，分布式数据库的实质还是数据库，所以也会具备传统数据库的要害特色；其次，分布式数据库须要解决的外围问题之一是扩大，解决研发团队按需扩容、不须要依照业务波峰额定筹备硬件资源的问题；而后是高可用问题，集中式数据库的零碎可用性很大水平构建在牢靠硬件的根底上，分布式架构将高可用问题转变为软件解决；最初在上述问题根底上，如何低成本地将现有利用平滑迁徙至分布式数据库，整个过程须要一些方法论。
相较于其余原生分布式数据库，OceanBase 立足于 TP 畛域，一直强化 AP 能力，去走向更全面的场景，这是一个要害的立足点，也是咱们保持的设计理念，尽量把复杂性从用户侧向数据库侧转移，对外出现的是 OceanBase 对用户的利用兼容，包含语法、语义以及存储过程等高级能力的兼容，让用户疾速、通明迁徙到 OceanBase。
▍刘博：从定义来看，分布式数据库首要解决区域间数据的一致性，映射到互联网行业次要是如下两点：
一是分布式数据库内置 HA 性能。以携程为例，过来次要采纳商业数据库联合存储的模式，靠高端硬件解决 HA 问题，起初这套架构逐步在支流互联网公司中隐没，取而代之的是一些 MySQL 的高可用计划，但这与分布式原生数据库提供的能力差异很大，切换时的中断是业务能够感知到的，分布式数据库自身就能够提供多机房或者异地机房等部署形式，晋升了高可用性及数据安全性，切换过程能够做到业务无感知，携程曾经将 OceanBase 部署在了生产环境，采纳了同城三机房的部署形式，能够抵挡同城单机房的故障，且三个机房对等，业务可就近拜访，故障时的切换不再须要人工参加，免去了简单的切换逻辑和人工操作流程。
二是横向扩大问题。尽管携程的业务峰值可能不如几大支流电商平台大促期间那么高，但也是存在显著的波峰波谷，例如寒假和春运火车票抢票。相似 K8s 这样的技术曾经很好地补救了利用的弹性诉求，但数据库层面的弹性始终是欠缺的，分布式数据库提供的动静伸缩性能，解决了数据库层的弹性问题。
如何判断哪种技术路线更适宜本人？
▍李卫：以后这个阶段，我感觉三种路线都存在事实需要，事实需要导致每个利用方要依据本人的业务特点和事实的资源环境决定采纳哪种路线，每一种路线都有劣势和劣势。分布式中间件路线最大的劣势是代码层级的革新量很大，因为两头加了一层分布式中间件；分布式存储依赖于存储的扩大，在扩大能力上存在局限，尤其是跨地区等较长距离的扩大难度比拟大，劣势是代码简直不须要革新；原生分布式的将来趋势非常明显，但因为倒退工夫绝对较短，相较于前两者在稳定性、生态等层面还存在短板，企业须要联合本人的业务进行抉择。
▍杨建荣：我提炼了六个维度对技术栈进行比照：
事务管理。绝对传统模式，原生数据库的事务管理有人造的优越性，因为业务都在一起。中间件的模式可能会放大事务危险或者隐患，原生模式因为是全新的体系，在事务管理层面有较大差别。
倒退周期。原生分布式数据库的周期相对来说更短一些，也是这些年十分风行的。中间件的模式，尤其银行等企业，晚期在方向上的积淀，包含这样的落地场景也会更多一点。
迁徙降级。原生模式的迁徙绝对平滑，其余模式还须要配合做一些架构设计和拓扑扩大。
高可用。原生模式依赖云平台的能力在高可用层面具备人造劣势，但其余模式依赖底层的标准化模式会有一些短板。
扩缩容。中间件的模式是一个域定义的模式，在做 N+1 的扩大上存在诸多限度，云原生分布式数据库相对来说更加弹性和灵便。
性能。云原生分布式数据库推出晚期也经验了大量验证，与其余模式相比，可能会有更多的老本耗费，但性能也有比拟大的晋升。
▍王南：我从场景的角度来聊，首先是中间件计划，当集中式数据库无奈满足诉求，大家很天然地抉择用分库分表的形式解决问题，将流量负载平衡到每个节点，该计划实用一些特定场景，比方对跨节点的分布式事务和一致性没有强诉求，但也有很多问题无奈解决，比方领取类场景或者其余须要跨节点事务的场景。
其次是分布式共享存储，不同场景的存储和计算负载要求不同，很可能存在扩大进去的计算和存储资源有一个被节约掉，该计划的存在很好地解决了这一问题，并且能够充沛协同和施展云存储的劣势，这也是私有云厂商踊跃推动该计划的起因，厂商在私有云存储根底上做了一层封装，能够提供不同类型、不同老本和价格的云存储计划，这种计划须要用户思考的因素较多，比方数据库架构设计层面如何与这种模式更好地交融。
最初是云原生分布式数据库计划，这对用户来讲是最简略的，因为对用户而言，其与集中式数据库的应用体验没有差别，数据分布、负载平衡以及故障主动复原等数据库都能够搞定，还免去了集中式场景下了解、学习及对利用革新的老本，然而产品成熟度以及以后积攒的场景实际案例是否能够很好地解决问题是企业比拟放心的，用户能够场景的不同来抉择更适合的计划。
▍刘博：三种路线与时代倒退有很强的关系。
第一种中间件的形式对代码侵入性比拟强，须要在单机版数据库的根底上减少分片规定。以携程为例，能够从用户的维度进行分片，但有些数据无奈找到适合的分片规定，例如：酒店信息很难找到适合的维度，如果以城市为维度划分，一线城市的酒店资源和三四线城市的酒店资源无奈对等分片，这是该种形式的局限性。该形式的益处是运维绝对简略，没有引入新技术给根底运维带来累赘，但压力就给到了业务侧，代码须要做较大的革新。
第二种是私有云厂商提供的形式。益处是存储资源根本做到有限裁减，用户按量付费即可，毛病是计算资源无限，如果业务没有显著的读写拆散场景，写的计算节点资源受限于私有云的计算规格，这种门路更适宜读的场景偏多的业务。
第三种，从技术、架构层面来说是目前最好的抉择，且对业务没有侵入性，扩缩容都比拟弹性。但目前察看到的落地案例还不是特地多，咱们比拟期待这种形式更加成熟，因为对业务比拟敌对。
分布式数据库逐步成为支流商业数据库抉择的起因？
▍李卫：一是上文提到的用户需要的扭转催生了分布式数据库的倒退；二是数字经济时代，数据成为了最外围的生产因素，要想施展数据价值，底层的核心技术使用也十分要害。现在的很多企业都在做数字化转型，技术架构从集中式向分布式转化，分布式数据库的反对成果显然更好。
▍杨建荣：我次要从四个方面答复该问题：
分布式数据库相较商业数据库倒退更快次要得益于其余解决方案更耗老本，通过更高配的硬件或者高端存储解决问题长期来看，老本是不容忽视的一个因素。
从应用体验来看，分布式数据库能够让整个过程更加平滑。从研发模式来看，历史债权较多的企业迁徙到分布式是一个很大瓶颈。传统的研发模式与以后越来越轻量化的形式是不相符的，分布式数据库在这个方向上是能够做到相辅相成的。
性能，并不是说这种模式的性能肯定比单机要好，但具备更强的扩展性，能够通过分布式平滑实现倍数的性能晋升。
技术生态，国内的分布式数据库厂商提供了欠缺的工具、文档包含配套的迁徙工具，能够帮忙企业实现无感迁徙。
▍王南：这个话题的争议度在几年前还是比拟大的，包含分布式是否是正确的方向都有比拟大的争议，当然这几年好很多了。大家对分布式的接受度和诉求越来越强，但不代表曾经成为支流，国内外也是有差别的，因而我不会轻易对这件事件下结论，但任何技术的倒退都是需要驱动的，没有广泛需要，这个观点必定是不成立的。
不论是市场占有率还是用户接受度来说，分布式数据库目前间隔支流必定还有差距，但越来越多的场景对分布式是有强烈诉求的。在云化的大趋势下，咱们置信这会是将来的支流方向之一。
▍刘博：目前业内很多守业公司和新型的数据库产品都是以分布式的状态呈现，这能够了解为时代的产物。从市场需求来看，业务的增长速度更快，对计算和存储资源的要求更高。携程的倒退过程经验了单机数据库、单机数据库加高端硬件、分库分表（前文提到的第一种中间件的形式）时代，尽管分库分表模式外表看起来没有减少新的技术，但运维复杂度升高很多，因为分库分表后，DB 规模和表规模越来越大。
分布式的引入对业务更加敌对，以保护窗口为例，原来凌晨三四点的时候，业务量很低，能够在这个窗口进行保护降级，现在的携程业务逐渐国际化，很难找到保护窗口，须要在不须要宕机的状况下进行保护降级，这也是携程自 2018 年开始应用分布式数据库解决的问题之一。原来须要熬到凌晨三四点才能够做的保护，当初能够抉择白天任何一个业务低峰时段进行，这也算是分布式的红利之一。
分布式数据库有哪些平安计划能够聊一聊？
▍王南：从平安角度来看，我想到了几个方面：一是分布式数据库与集中式数据库场景下的平安体系根本能力，如用户决策权限是一样的，这些仍然存在很强的诉求；二是分布式可能会带来更多挑战，毕竟波及多节点及更简单的底层基础设施，OceanBase 目前能够同时物理机、虚拟化、公有云和私有云四种部署形式，将来也会反对多云。除传统的平安伎俩之外，分布式数据库可能会须要解决数据全链路的平安、数据存储加密等问题，目前也会通过云平台提供一些加解密的形式，平安不是欲速不达的，将来会逐步将这些产品能力补齐。
▍刘博：作为一款商业产品来说，OceanBase 也会遵循国内通用的平安规范，用户能够从三个维度来对待平安问题：存储、审计和传输。比方 OceanBase 能够开启 SSL 性能，实现客户端和服务器之间数据的平安传输。也能够开启通明加密，实现存储的加密。OceanBase 提供的审计表，记录了所有的 SQL 拜访。这里提一下，携程依据审计表做了一些性能开发，咱们将审计表中的数据全副抽取进去，做了 SQL 的实时剖析，用于拜访异样检测和性能剖析。
真正的 HTAP 到底是怎么的？
▍李卫：HTAP 这两年的探讨热度较高，当企业外部对 TP 和 AP 同时有需要的时候，联合必定是性价比最高的形式，否则面临着人力、资源等各方面的节约，至多目前来看这种形式是存在理论需要的，但须要与场景相结合。
▍杨建荣：从存储角度来看，AP 自身的存储会占用一部分老本，这须要从老本层面做出取舍，无论是底层压缩还是针对性的热点数据，尽量在不影响原有 TP 业务的状况下让业务更加平滑。
从计算层面来说，能够做扩大或者说插件模式，整个的 AP 计算不是放在一个大池子里，还是须要做出一些取舍。久远来看，HTAP 的形式能够解决大部分诉求，但必定有一些更业余的方向或者更长历史周期的数据须要专门的 OLAP 实现。
▍王南：HTAP 严格来说并没有特地明确的定义，这是 Gartner 首次提出的概念，大家的了解或者有所差别。目前有一类实现形式是同一个产品部署 AP 和 TP 零碎，尽管是两个零碎，然而同一个产品解决了两类场景问题。这就进一步分化为两套引擎（一套解决 TP，一套解决 AP）和一套引擎（既能够解决 AP，又能够解决 TP）两种形式。
如果回到用户的原始诉求上来，HTAP 对用户来讲就是既要解决业务交易负载，也要解决简单查问、报批、报表这样剖析类负载问题，无非是用一个零碎还是建两个零碎来跑的问题。数据量较小的状况下，Oracle 或者就能够；数据量较大的状况下，目前广泛抉择通过两套零碎来解决问题。随着分布式的倒退，这个问题又呈现了新的解决方案，OceanBase 目前的路线是一个零碎、一套引擎能够同时解决 TP 和 AP 两类问题，包含数据存储层面的优化，咱们正在尝试运行几十 TB 量级 TPC-DS 的负载，心愿通过技术手段解决这个问题。
▍刘博：在理论的场景中，TP 和 AP 的边界可能没有那么清晰，很多业务的响应可能是 TP 级的，资源耗费又是 AP 级的，这个边界越来越含糊，咱们很难定义。而且国内的生态根本还是基于 Hadoop 的生态来构建的 AP 零碎，这就有可能呈现数据提早、数据反复存储、运维成本上升（须要两个团队各自运维两个零碎）等问题，HTAP 能够很好地解决这些问题。
分布式数据库里的 MapReduce 可能是什么样？
▍王南：这可能还不太一样。OceanBase 将问题拆分为不同的维度：分布式的问题、计算模型的问题和存储的问题。OceanBase 之所以抉择用一个存储引擎来解决问题，次要是充分利用了闪存等硬件 + 新架构来解决海量数据的并发更新问题。尽管从概念上来看，分布式和存储是两层，但理论是放在一起解决的，通过分布式的协定解决节点间的数据复制和存储问题，同时保证数据强一致性和多核高可用。只有做好优化器和语法层，计算引擎和模型是能够比拟疾速地满足业务诉求的。在不同的档次解决不同的问题，存储层解决效率问题，分布式解决高可用和扩大问题，计算层解决并行、兼容性和生态问题。
分布式数据库的学习门槛如何？
▍刘博：学习老本可能分两个层面：语法层面罕用的 SQL 语句都是兼容的，在 OceanBase 的测试中，携程仅发现了极个别无奈反对的语句，也是应用频度较低的；运维层面复杂度的确高出几个数量级，因为数据拜访波及的门路变多了。当然，学习路径也变多了，社区有文档、视频等很多材料都能够翻阅。数据库学习最重要的是须要实操，先把 OceanBase 的开源版本运行起来看看，自行编译看看。
分布式数据库选型能够从哪几个方面进行思考？
▍李卫：分布式数据库选型须要与业务场景相结合。在国内，金融、电信等畛域曾经在分布式数据库层面有了大量实际。咱们从上述两大行业抽离出了一些与数据库高度相干的零碎，比方计费零碎、客户零碎等，通过试验证实分布式数据库的确曾经可能很好地撑持起相干业务的运行，但与老牌商用数据库的能力相比还存在差距，此外还须要关注将来的继续稳固运行能力。
▍杨建荣：数据库选型的这个问题能够通过 BATD 模型来看。其中，B 指的是业务驱动；A 指的是架构演进的视角对待技术选型，比方中间件就是这样一种技术；T 指的是技术生态，是否在某些场景中有足够的积淀；D 指的是多元化，数据库选型不要做大一统，而是更多思考多元化，从技术栈演进的层面做出取舍。
▍王南：用户对数据库选型是最有发言权，从咱们这些年来和泛滥曾经上线外围业务的客户在选型关怀维度的反馈上，用户冀望在满足以下根本要求再去谈产品的各种个性：
首先，数据是企业的外围命根子，不论抉择什么样的数据库，保障数据不丢、不错、不乱是最根本的要求。
其次，如果抉择分布式架构的数据库，如何确保永远可信赖的数据一致性，包含集群和集群之间、正本和正本之间，分区和分区之间，索引和索引之间甚至是宏块和宏块之间的数据一致性链式校验，从而避免因磁盘静默谬误或者因为硬件故障导致的数据不统一。
再次，是否可能对于异构芯片、操作系统等能够实现混合部署、灰度部署，造成逃生机制，确保在数据库革新降级时实现业务逃生。
而后，是否反对 DB-Mesh 的数据中心的部署和建设以满足业务的弹性，能够实现单元化、云原生、全密态的部署。
最初，有业余的团队和撑持能够兜底。
基于上述的根本要求，从性能上能够演绎为四大方向：
第一，刚性能力和指标满足度。这可能波及到很多问题，包含性能、性能、平安、牢靠，兼容、资质等，这是最根底的。
第二，产品成熟度。是否曾经在足够多的不同行业进行了落地实际，在不同的用户量、不同的业务负载下进行了验证，产品是否只有一个内核，还是上下游产品生态兼具。
第三，数据库的厂商。也就是背地团队的技术能力，以及这家公司对数据库策略的定力和稳定性，也是影响微小的，特地是对于中大型企业而言，这关系到零碎后续是否能够稳固继续运行。
第四，老本和性价比。这不仅仅是外表的价格，还包含稳定性的老本、迁徙老本、服务老本、运维老本等各方面，甚至有些用户思考一旦呈现问题，兜底计划的老本有多大。
从市场来看，现在的数据库市场的确是百花齐放，益处是提供了更多样化的能力，防止被繁多供应商绑定；害处是抉择的老本很高，也可能呈现反复造轮子的景象。这就须要行业监管和标准化组织的疏导，让行业衰弱倒退。
▍刘博：我也批准三位老师对于选型必定须要与场景联合的认识。携程在抉择分布式数据库时次要思考了性能齐备度、与现有数据库的兼容性以及性能和反对等方面。OceanBase 目前也有社区版本，咱们可能也会思考社区的 star 数量、PR 数量、issue 数量等。
分布式数据库的迁徙过程中应该留神哪些问题？
▍刘博：迁徙可能须要思考是否平滑、兼容性和性能等。咱们之前针对 OceanBase 做过一些测试，比方同样的语句在 MySQL 和 OceanBase 上等比例放上，看两边的响应水平等，也包含一些兼容性测试。
此外，企业还须要思考迁徙过程的稳定性，对新的数据库是否具备足够的掌控力，一旦产生问题，是否有回退计划。以 OceanBase 为例，咱们通过 OceanBase 本身提供的 OMS 性能，搭了一条反向链路到 MySQL，一旦遇到紧急情况，能够平滑再切到 MySQL。
▍王南：从横向来看，能够分为迁徙前、迁徙中和迁徙后三个阶段。事先，咱们提供了 OMA 这样的工具，能够对业务负载进行剖析，包含可视化的报表告知用户兼容水平、倡议应用的迁徙计划和可能存在的危险。
事中，提供一个工具实现整个自动化迁徙过程，这个前面具体开展。
预先，须要测验迁徙是否真的实现以及数据是否统一，这也不意味着高枕无忧了，还须要筹备一些预案以应答运行后可能的突发状况。
从纵向的角度来看也就是上述提到的事中阶段，这外面有几个外围问题须要思考：一是原数据如何迁徙，假如兼容度极高，各种高级能力都能够间接使用，这是比拟省心的。假如兼容度不高，这可能须要大量的手工 SQL 转换，甚至须要进行应用层的改写，老本极高，OceanBase 自身的 OMS 中提供了大量工具可供选择，比方动态的全量数据迁徙、增量的数据迁徙，自定义过滤条件，甚至一些算子转换等。
此外，对于丰盛的数据源和指标端的反对，因为数据迁徙不仅仅是从原来的集中式数据库迁徙到分布式数据库，不同的用户可能会有不同的诉求，比方对一些流、缓存进行迁徙等，这须要云端反对的指标类型足够丰盛。
▍杨建荣：我在上述两位的答复上补充一些细节，迁徙过程中罕用的一种形式是双写，通过这种模式验证，相对来说整个迁徙过程更平滑可控。另外，咱们可能会在一些场景做数据同步，比方 A 到 B 的切换过程继续做数据同步，须要一直地思考数据的一些基础训练，包含 SQL 回放、性能验证等。当然，从整个切换模式来说，业务方简直是无感知或者闪断。
