哔哩哔哩

弹幕视频平台是一种视频分享平台的分支，观看者可以在观看视频的过程中发表自己的评论，并即时在所有观看者观看此视频的该时间点以滑动字幕显示，增加了观看者之间的互动性。

2006年，世界上最早拥有即时评论功能的，主要用户由御宅族构成的视频平台niconico在日本开始运营。这类视频平台在播放视频时，允许文字评论从视频画框的一端飘向另一端，或在画框的固定位置悬停。这种文字评论叠加在视频画面之上，并且呈运动状态的奇异视觉效果，十分类似炮弹齐发的“弹幕”。“由于弹幕比普通视频平台中附加在视频下方或边栏的评论区更具有即时性、交互性和视觉效果，并能很好地和二次元宅的同好交流结合起来，因此迅速流行开来。不仅影响到日本的大众流行文化，还辐射到东亚地区乃至全世界。

在中国大陆，最著名的弹幕视频平台是AcFun和哔哩哔哩Bilibili，它们都可以被视作niconico平台的翻版。不仅复制了弹幕评论功能，主要用户也都是二次元宅。其中，AcFun简称A站，2007年成立，最初主要是连载动画，2008年3月开始模仿niconico，建立即时评论系统。此后A站越发倾向于鼓励原创作品，题材也不仅仅局限于ACG，在弹幕功能的催化下，很快形成了独特的平台生态和平台文化。哔哩哔哩Bilibili简称B站，其前身为视频分享平台Mikufans，2010年正式更名哔哩哔哩。B站拥有比其他弹幕平台更为复杂的弹幕系统和权限设置，最初以搬运日本动画和各国电视剧、纪录片为主，后来也出现大量原创视频。近年来网络视频版权管理越发严格，B站也积极购买了一些正版动画、电视剧版权，继续发挥其弹幕文化的优势。

随后，B站于2018年在美国纳斯达克上市，市值达到342亿美元。2021年3月29日，B站在港交所主板二次上市，市值达到3045亿港元（约2565亿元）。B站的营收在过去三年持续上升，且一直维持着较高的同比增速，活跃用户、付费用户、整体付费率等关键指标也在快速增长。根据艾瑞咨询的数据，2020年中国在线视频市场的用户规模达到9.6亿，同比增长5.7%；市场收入规模达到2090亿元，同比增长32.9%。预计到2025年，中国在线视频市场的用户规模将达到11.4亿，市场收入规模将达到5000亿元。Bilibili在这个市场中占有一定的份额和影响力。根据Bilibili的2020年度报告，Bilibili的月活跃用户数达到2.02亿，同比增长55%；年度收入达到119亿元，同比增长77%。Bilibili的用户规模占中国在线视频市场的21%，收入规模占市场的5.7%。其从一个小众社区发展成为了一家综合性影视平台，涵盖了大量的其他内容类型，包括热门影视剧、综艺节目、美食、旅游等多个领域。

本节从系统框架、数据流转、功能模块三个方面对系统进行分析设计，为后续结构分析提供基础。

平台按照系统架构划分资环持久化层、服务器层、BFF层、网关层和应用层5个层次。下图规定了Bilibili平台的层次结构及各层之间交互情况。Bilibili平台的层次划分，规定了各层次的功能任务，理清了平台各层之间的范围。

第一层为资源持久化层在数据库的基础上，进一步优化了数据管理和存储策略。通过采用分库分表的方式，实现了数据库的水平拆分，使得系统能够更好地应对海量数据的存储和查询需求。同时，引入了数据库的垂直拆分，根据业务模块将数据进行分离，提高了系统的可维护性和灵活性。

为了进一步提升系统的查询速度和效率，搜索引擎不仅在数据库之上建立了索引，还通过引入分布式搜索引擎，如Elasticsearch，来加速对文本信息的检索。这不仅改善了模糊查找效率，还增强了系统对大规模数据的实时搜索和分析能力。

在应对高访问量的挑战上，缓存机制得到了进一步强化。除了常见的缓存服务如Redis和Memcache外，还采用了分布式缓存方案，如Guava Cache和Hazelcast，以降低数据库负担，提高系统整体的稳定性和性能。

第二层为服务器层，不仅仅是简单的集群，而是通过负载均衡器实现了智能流量分发，确保每个应用服务器都能够充分发挥其性能。为了更好地支持业务发展和规模扩大，引入了微服务架构，将应用拆分成多个独立的子系统。这样的架构不仅提高了系统的可伸缩性，还使得各个子系统可以独立演进、部署和扩展。

第三层为BFF层，进一步强调了对移动端设备的友好性。通过引入BFF集群，不仅能够解决单点故障问题，还通过垂直BFF时代的集群化实现了更高的可靠性和扩展性。这有助于提供更加流畅、稳定的用户体验，同时支持多平台的无线设备接入后端服务。

第四层为网关层，其在架构中起到了协调和整合的关键作用。基于业务的“统一API网关”架构不仅简化了系统的复杂度，还提高了业务集成度。通过引入路由、认证、限流等组件，网关层有效地解耦了各个微服务，使得系统更易于升级和迁移。这种架构的优势在于业务线团队可以独立开发和交付微服务，从而提升整体研发效率。

最后一层为应用层，其构建在底层数据和信息资源的基础上，提供了多样化的应用及信息分析服务。针对智能分析的需求，系统不仅实现了广告推荐、视频推荐等功能，还引入了先进的机器学习算法，实现了个性化推荐和动态内容查看，以满足用户对于个性化体验的追求。这使得整个系统更具智能化和用户友好性。

数据流分析

本平台中原始数据一共分为四类，一类是用户上传内容，包括视频、图文等，一类是官方运营内容，包括视频、图文、广告和推荐等，一类是入驻官号发布内容，包括视频、图文等，最后一类是用户操作产生内容，如点赞、评论和弹幕等数据。下图展示了系统的数据流。

本平台将用户上传内容以及用户操作内容转化为结构化的数据并保存至相应的数据库中。整个系统共包括三种数据库。

内容数据库：用户上传、官方运营内容、入驻官号发布内容均存储在此，其主要使用面向对象的存储方法，保证了读写的高效，减小网络压力。

用户数据库：存储因用户操作产生的内容，如用户关注列表、用户点赞列表、动态评论列表等，用于精准内容推送、智能内容推荐等。

领域规则数据库：存储根据内容数据和用户操作数据经过数据挖掘得的领域规则，用于智能地向用户推荐内容，增加内容曝光度。

该平台地数据流从各角色上传内容，经过网络上传，随后来到内容审核层，在此，内容审核员需要根据审核规定对内容进行审核，判断是否发布，如果打回则给出修改意见。下一步就是内容预处理，这一阶段系统根据算法对内容进行分析处理，例如对大存储占用内容进行压缩、根据过往规则进行数据挖掘生成新的领域规则，最后将生成内容持久化到各类数据库中。

当用户发出请求时，系统根据领域规则数据库、用户数据库进行内容推荐、内容推送筛选合适的内容，随后将其从内容数据库推送至用户界面。

通过系统架构可以得知，系统的角色分为匿名用户、登录用户、管理人员。现在从不同角色出发，设计系统的功能模块。

平台管理模块旨在维护系统的稳定运行。平台管理者需要对角色和用户进行权限的分配管理，对系统进行数据的备份和恢复、处理系统异常，并监测系统的运行状况。

       管理审核模块主要需要对用户上传及其操作的内容进行审核，同时对已经上传操作但存在风险的内容进行判断，及时解除系统风险，避免用户进行不法操作，例如大规模数据爬取、传播敏感内容。

用户功能模块分为匿名用户和登录用户：

匿名用户

       内容查看：用户未登录时，可以进入系统查看平台自动推荐内容，同时可以查看部分评论、弹幕内容。另外，用户还可以查看外部分享链接，但对内容展示品质有一定限制。

       内容搜索：用户未登录时，可以进行内容搜索，但对搜索数量有一点限制，搜索得到内容后，用户可以对其进行查看。

登录用户

       内容点赞：用户登录后，可以对自己感兴趣的内容进行点赞推荐，也可以取消本账号的点赞，系统在获取点赞数据后，会对其进行更新，同时，会将该视频推荐给更多相似用户。

       内容评论：用户登录后，可以对自己感兴趣的内容进行评论互动，也可以删除本账号的评论内容，系统在获取评论数据后，会对其进行更新展示，同时，其他用户也可以对此评论进行回复和点赞推荐。

       弹幕发送：用户登录后，可以在自己感兴趣的内容中发送弹幕，也可以删除本账号的弹幕内容，系统在获取弹幕数据后，会对其进行滚动播放，同时其他用户也可以对此弹幕进行点赞推荐。

       内容创作：用户登录后，可以上传自己创作的内容，经过审核员审核后，系统会将该内容推荐至其他用户，同时，关注该用户的其他用户也会接收到消息推送，其他用户可以对该视频进行点赞、评论以及弹幕操作，另外，创作者也可以删除本账号的创作内容。

“4+1”是由Philippe Kruchten于1995年提出的一种可以通过多种共存的视图描述软件密集型系统架构的视图模型，这些视图基于不同利益相关者的观点。“4+1”由4种基础视图和一些经过挑选的用例或场景（即额外的“+1”视图）组成。提到“4+1”的各种视图，一般都是使用UML来表示，但是实际上“4+1”本身是一种通用的视图模型，并没有限制绘图的记号和工具。它的架构制图思想是：架构需要通过多种视图来描述，而这些视图是来源于不同项目干系人的视点；只有这样才能产生一整套全面、立体且客观的架构描述。

“4+1”视图模型的五个不同视角，分别是逻辑视图、开发视图、进程视图、物理视图、场景视图。每一个视图只关心系统的一个侧面，5个视图结合在一起，才能反映系统的软件体系结构的全部内容。

主要支持系统的功能与服务需求，即系统提供给最终用户的服务。在逻辑视图中，系统被分解成一系列的职责抽象，这些抽象主要源自问题领域。逻辑视图设计中要注意的主要问题是：要保持一个单一的、内聚的对象模型，贯穿整个系统。

开发视图主要侧重于在开发的场景下，软件模块的组织和管理，其要求要关注程序包，还要考虑软件内部在开发方面的技术性需求。在确定了软件包含的所有元素之后，完整描述开发人员应该了解和关注的元素及其结构关系。逻辑视图和开发视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。

进程视图也称为并发视图，侧重于系统的运行特性，主要关注一些非功能性的需求，如关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。其强调：并发性、分布性、容错能力，以及逻辑视图中的主要抽象，是如何适合于进程结构的。

开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程。进程视图比较关注的正是这些运行时单元的交互问题。

物理视图关注“目标程序及其依赖的运行库和系统软件”最终如何被安装或部署到物理机器上，以及如何部署机器和网络，以配合软件系统的可靠性、可伸缩性等要求。

物理视图重视目标程序的静态位置向题，而进程视图特别关注目标程序的动态执行情况，同时物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图，其决定拓扑结构、系统安装、通讯等方面的向题。各视图中的构件，都直接就间接地对应于系统的不同节点上。

场景可以看作是那些重要系统活动的抽象，它使4个视图有机地联系起来。

在开发软件架构时，它可以帮助设计师，找到架构中的构件和它们之间的交互协作关系。同时，也可以用场景，来分析一个特定的视图，或描述不同视图构件间是如何相互协作的。场景可以用文本表示，也可以用图形表示。

逻辑视图(LogicalView)的风格一般采取面向对象的风格，其主要的设计准则是为了使整个系统中保持单一的、一致的对象模型，避免就系统中的场合或过程产生草率的类、实体以及机制的技术描述。

Bilibili弹幕视频平台的逻辑视图如下图所示，从内容展示、内容管理、内容持久化、内容推荐四个方面详细描述了Bilibili弹幕视频平台的逻辑视图，使用类图的方式各个类的内容以及类之间的包含、继承关系进行了详细的描述。

开发视图(DevelopmentView)是对系统在开发环境中软件的组织结构的具体描述，即主要关注软件在开发环境下实际模型的组织结构，服务于软件编程人员，从下到上定义每一层的接口，使上层结构不关注下层的具体实现，直接调用下层的接口。可以将软件开发分为多个小的程序块，然后把程序块分给不同的程序员开发，彼此独立开发，而又不影响系统的集成。每个小的程序块可以组织成不同分层结构，每个层为上一层提供调用接口，上层不需要关注下层的实现的维护，根据只需要调用下层的接口，开发人员只需维护每层的接口，只关注自己控制的接口开发。

         在此，由于Bilibili弹幕视频平台采用分布式微服务架构，各模块较为独立，同时其模块复杂程度高、功能数量多，因为将其拆分为四个模块，分别为动态模块、点赞模块、弹幕模块和评论模块。

哔哩哔哩动态作为平台上的社交功能，具有丰富的功能特性，包括用户分享生活、兴趣、观点等内容，以及与其他用户进行互动和交流的能力。这不仅包括文字、图片、视频等形式的内容发布，还涵盖观看记录、点评、收藏等多种互动方式。此外，视频创作者（UP主）也通过动态与粉丝互动，发布视频预告、幕后花絮、直播链接，以及回答粉丝问题、分享创作经验等。

在业务需求方面，哔哩哔哩动态面临着巨大的流量池，日均综合页PV达到十亿级以上，且功能逻辑复杂，要求开发人员深入理解业务逻辑。覆盖业务广泛，与约20多个非动态业务进行对接，业务间常常需要互相联动，导致业务功能耦合，因此开发工作需要在网状联动的业务复杂性中寻找解决方案，以满足业务需求并方便维护。动态场景下的稿件、图文、直播三大内容金刚在日均近亿次点击中发挥着强大的导流效果。考虑到动态功能自2017年9月上线以来已有5年多的历史，迭代时间较长，系统需要不断适应业务的发展和变化。

在开发视图方面，哔哩哔哩动态的架构设计分为四层。最底层是数据存储层，负责进行数据持久化存储。第二层是数据抽象层，对持久化数据进行索引和其他操作的封装，以实现高复用。在第三层是逻辑层，将动态的常用逻辑处理封装聚合为各类API，以方便不同客户端的调用，并降低耦合度。最顶层是接入层，为前端用户界面提供经过处理的数据。

这种架构设计使得动态模块在开发环境中的组织结构清晰，使得不同层次的开发人员能够专注于各自的工作，降低了系统的复杂性，提高了开发效率。通过明确定义的接口，实现了各层次之间的解耦，使得上层结构无需关注下层的具体实现，只需调用接口进行开发。这种模块化的结构有助于系统的可维护性和可扩展性，满足了动态模块复杂性和业务需求的挑战。

Bilibili（哔哩哔哩）的点赞功能是视频观众表达喜爱和支持的重要互动方式，通过点击视频底部的心形按钮完成。这简单而直观的互动机制不仅促使观众积极参与社区，还为创作者提供了正面的反馈。点赞总次数不仅评价视频受欢迎程度，还可能影响视频在平台推荐算法中的排名，从而提高曝光度。

点赞服务的关键特性在于用户对视频的喜好进行有效表达，形成社区互动。每个视频的点赞总数作为受欢迎程度的指标，影响推荐算法，从而影响视频的曝光度。系统承受全站点赞状态查询、点赞数查询等读流量超过300k，点赞、点踩等写流量超过15K。此外，系统还需要应对热门事件、稿件等带来的系统热点问题，包括DB热点、缓存热点，以及存储超过千亿级别的点赞数据。

为了满足高流量、高写入的业务需求，点赞服务正在努力改造工程，其中一个关键工程是KV化存储。如何高效利用存储介质存放数据，既满足业务需求又能最大程度节省成本，是点赞服务的重要挑战。系统还要面对未知灾难，如DB宕机、Redis集群抖动、机房故障、网络故障等，确保服务的高可用性与容灾能力。

整个点赞服务系统可分为五个关键部分。首先，流量路由层决定流量应该去往哪个机房，以处理全局流量。其次，业务网关层负责统一鉴权、反黑灰产等统一流量筛选。在点赞服务层，通过thumbup-service提供统一的RPC接口，实现点赞功能。同时，点赞异步任务（thumbup-job）处理异步任务，确保系统的稳定性。最后，数据层包括db、kv、redis，用于存储点赞相关数据。整体而言，这个开发视图设计清晰，每个部分的功能都有明确的定位，确保系统的高效运作。

评论模块的核心功能在于提供用户交流的平台，让用户对UP主的内容进行讨论和互动。评论文本更丰富，观点更深入，评论区的热门计算、评论管控、审核等基础服务都是为了提高用户体验、维护社区秩序和确保内容的质量。评论系统的组件化和平台化使其能够灵活应对不断增长的业务需求。随着业务的不断发展，B站评论系统逐渐组件化、平台化，通过持续演进架构设计，管理不断上升的系统复杂度，更好地满足各类用户的需求。

评论作为主体内容的外延，因此被设计成一个独立系统。为了满足业务发展的需求，Bilibili评论系统的架构设计分为四个关键层次。最底层是存储及缓存层，通过TiDB、MySQL、NoSQL实现数据持久化存储，同时通过Bloomfilter、LocalCache、Cache进行数据缓存。第二层是基础支撑服务层，包括评论区注册、评论发布、热评计算、评论管控、评论审核等基础服务。第三层是基础业务服务层，包括reply-interface和reply-admin。reply-interface作为评论系统的接入层，主要服务于两种调用者：一是客户端的评论组件，二是基于评论系统做二次开发或存在业务关联的其他业务后端。评论管理服务层为多个内部管理后台提供服务。最顶层是表示层，为前端用户界面提供经过处理的数据。

评论系统的点赞功能是其重要的互动要素之一。在开发视图中，点赞功能需要被嵌入基础支撑服务层，与评论发布、热评计算等服务相互关联。通过合理的架构设计，点赞功能可以被统一管理，确保系统的稳定性和高效性。同时，需要考虑点赞数据的存储和缓存策略，以及如何高效处理点赞请求，满足高流量的业务需求。整个点赞开发视图分析应紧密结合评论系统的整体架构，确保点赞功能与其他功能协同工作，为用户提供良好的互动体验。

哔哩哔哩（Bilibili）的弹幕功能是其独特的特色之一，允许用户在观看视频时实时发送、显示短文字弹幕，为观众提供了实时互动和社交的体验，构建了强大的社区氛围，成为平台上用户互动和内容共享的重要元素。

弹幕模块的发展历程可分为三个阶段。首先是基础能力阶段，着重保障在高并发、热点场景下弹幕服务的稳定和高可用。其次是负向治理阶段，通过删除、自见、打薄等手段对低质弹幕内容进行管控。最后是正向推荐阶段，目标在于优化视频消费体验，通过筛选优质弹幕内容进行展示。

弹幕模块的开发视图分析分为四层一系统。底层是存储层，拥有三级缓存体系，包括接口级缓存、弹幕ID列表缓存和具体弹幕内容缓存，以满足C端读流量需求。业务层涵盖展示聚合、数据回源、增量更新、弹幕池淘汰等服务，通过业务层实现对弹幕的管理和展示。网关层负责弹幕的发送和展示等功能，为顶层表示层提供接口。整个系统中，弹幕个性化推荐系统通过AI精排接口获取弹幕ID，在内部存储系统中读取弹幕内容，实现渲染并返回的过程。核心目标在于最大限度扩大推荐系统的召回池容量，同时采用基于模型的召回策略并支持回刷，通过简化存储并提升计算能力实现优化。

进程视图考虑一些非功能性的需求，如系统的吞吐量和可靠行，其能够控制具体执行定义在逻辑视图中的各个类的具体操作是在哪一个线程(Thread)，考虑进程的并发和同步以及系统运行时的网络通信。

在此，我是用UML中的时序图来进行进程视图的描述，时序图是一种图形化表示系统中各个对象之间交互行为的 UML（Unified Modeling Language）图表。它强调了时间序列，以展示在一段时间内系统中各个对象的交互顺序。时序图通常用于描述系统中的消息传递、方法调用或事件触发等交互关系。在时序图中，垂直轴表示参与者或对象，水平轴表示时间流逝，通过箭头表示消息或事件的流向。

如下图所示，主要从普通用户的角度和系统审核管理员的角度来进行时序图的绘制，普通用户可以点击进入软件后进行系统内容的查看以及本账号内容的管理。系统审核管理员可以对用户上传内容进行审核，同时可以排查已经存在的风险内容。

物理视图(PhysicalView)主要描述系统需要的硬件配置，可以系统工程人员为系统安装说明书，详细描述系统的拓扑结构、系统安装、通信等问题。物理视图主要考虑如何把软件系统映射到硬件系统上，同时也要考虑系统规模、运行性能、可靠性等问题。如下图所示，使用UML图中的部署图来展示了Bilibili弹幕视频平台的物理视图。其主要被分为7各部分，分别是客户端：包括浏览器、PC客户端、移动客户端等；外部网络：包括DNS服务器、CDN缓存服务器、外网防火墙等；网关：包括BFE服务器、SLB负载均衡服务器、API GateWay网关服务器等；核心交换域：包括核心交换机、内网防火墙等；数据库：包括用户数据库、动态数据库等；应用中心：包括应用服务器、文件服务器、配置中心服务器等；其他服务器：包括缓存服务器、消息服务器集群等；

场景视图又可以称为“用例视图”，就是将四个视图有机地联系起来。可以描述某一个特定的场景下四个视图内的构件关系以及业务过程，也可以描述不同视图间的进程、构建、线程之间的关系。

因此，在此我选用用例图来进行场景视图的描述。在下图中，主要包括普通用户和管理员用户两个角色。其共同用力包括登录注册、内容查看。普通用户用例还包括本账号内容管理，管理员用户用例还包括全局内容管理。其中内容主要包括动态、点赞、评论以及弹幕。

哔哩哔哩平台的数据库架构设计体现了对稳定性、高可用性和容灾性的追求，采用了多机房多活部署的方案。在数据库层面，通过读写分离和主从同步的实现，以及Proxy和DTS的定制化应用，构建了一个成熟而高效的体系。

首先，数据库的异地多活架构实现了两地三中心的布局，确保了系统的高可用性和容灾性。Proxy作为数据库的访问代理，经过深度打磨成为一个成熟的产品，提供了分库分表、限流、黑白名单等功能。其部署方式既可以选择集中式，类似于网关模式，实现了统一的限流和资源调控，也可以采用Sidecar模式，使得应用层配置简单。然而，Sidecar模式也带来了一些挑战，如全局管控和成本管理，需要综合考虑。

在DTS方面，根据B站技术栈的特点进行了大量定制，使其更好地适应异地多活场景。特别是在冲突检测方面，提供了多种规则选择，包括基于特定字段和全字段匹配，同时为冲突数据提供了两种处理途径。一方面，直接将不重要的冲突数据打入公司的Data Bus，另一方面，业务方可以通过DTS提供的接口将数据回写到特定机房，实现了冲突数据的二次处理。

主从切换是数据库架构中的关键操作，为了保证数据可以来回切换，DTS提供了数据冲突的打捞队列，实现了对边缘场景下的数据冲突问题的二次处理。这进一步加强了系统在主从切换期间的数据一致性。

综合来看，哔哩哔哩平台的数据库架构设计充分考虑了系统的实际需求，通过Proxy和DTS的协同作用，实现了对多机房多活部署的高效支持。这一设计不仅提升了系统的可用性和性能，同时也为业务的扩展和发展提供了坚实的基础。

哔哩哔哩数据库架构图

哔哩哔哩平台通过充分利用Proxy模块，实现了对数据库的灵活而强大的管理和控制。这一模块的广泛使用为我们提供了多种手段，用于拦截、限流和熔断，有效地防止异常流量导致数据库崩溃的场景。此外，Proxy还轻松实现了状态下的读写分离，为数据库操作提供了更高的灵活性。

其中，Proxy的强大之处体现在对特定数据库、服务、SQL指纹的定向控制。通过拦截和限流，我们能够精准地应对异常流量，防止其对数据库造成不可挽回的损害。这种细粒度的控制使得系统更具鲁棒性，能够在异常情况下保持稳定运行。

Proxy的多机房路由功能使得我们能够灵活地管理数据流量的转发。通过将机动架构下的数据流量动态路由到主库，系统可以更好地适应变化的拓扑结构。新增或删除从库以及节点的变化都能够被迅速发现，为系统架构的调整提供了实时的支持。

另一方面，通过更精细化的Sidecar模式，我们能够减少业务技术与能力的负担。在这种模式下，通过使用Proxy，我们不仅能够实现对大量场景下的需求响应，还能够实现更细致的管理和控制。这种灵活性使得系统在不同业务场景下都能够得到有效的应用。

综上所述，哔哩哔哩平台的数据库架构中的Proxy模块通过其多功能性和灵活性，为系统提供了可靠的数据库管理和控制手段。这种设计不仅保障了系统的稳定性和性能，同时也为未来的业务发展奠定了坚实的基础。

哔哩哔哩数据库Proxy架构图