如何基于OceanBase构建应用和数据库的异地多活
如何基于OceanBase構(gòu)建應(yīng)用和數(shù)據(jù)庫(kù)的異地多活
前言
OceanBase是一個(gè)通用的分布式的關(guān)系型數(shù)據(jù)庫(kù)，有很多獨(dú)特的特點(diǎn)。比如數(shù)據(jù)庫(kù)的多租戶、高可用、極致彈性伸縮能力。如果把OceanBase當(dāng)作單庫(kù)使用，就沒(méi)有把OceanBase的分布式優(yōu)勢(shì)發(fā)揮到極致。
本文主要分享一個(gè)基于分布式架構(gòu)的應(yīng)用把OceanBase數(shù)據(jù)庫(kù)的分布式優(yōu)勢(shì)發(fā)揮到極致所需要了解的OceanBase基礎(chǔ)，這也是理解螞蟻金服的基于OceanBase構(gòu)建的三地五中心異地多活架構(gòu)的基礎(chǔ)。
?
分布式數(shù)據(jù)庫(kù)開(kāi)發(fā)相關(guān)問(wèn)題
好的性能首先是設(shè)計(jì)出來(lái)的，應(yīng)用如果追求極致的性能，就需要關(guān)注OceanBase里數(shù)據(jù)的相關(guān)事情。如：
-
數(shù)據(jù)如何分布？
-
數(shù)據(jù)如何讀寫(xiě)？
-
存儲(chǔ)容量瓶頸怎么辦？
-
訪問(wèn)性能瓶頸怎么辦？
-
數(shù)據(jù)庫(kù)出故障時(shí)數(shù)據(jù)可用性和可靠性具體怎樣？應(yīng)用需要做什么特殊處理么？
-
數(shù)據(jù)庫(kù)擴(kuò)展時(shí)應(yīng)用需要遷移數(shù)據(jù)么？數(shù)據(jù)遷移的時(shí)候?qū)?yīng)用有什么影響？
?
這些問(wèn)題對(duì)理解OceanBase的分布式特點(diǎn)很有幫助。后面我們逐步看看OceanBase是如何應(yīng)對(duì)。
?
OceanBase集群外觀
首先簡(jiǎn)介一下OceanBase集群的外觀。
圖 1 OceanBase集群外觀
?
OceanBase是以集群形式運(yùn)行的，由一堆服務(wù)器組成。上圖是「三副本」部署，機(jī)器會(huì)分為三組，每組一個(gè)區(qū)域（稱為Zone），各個(gè)機(jī)器通過(guò)網(wǎng)絡(luò)互相訪問(wèn)。沒(méi)有光纖交換機(jī)、共享存儲(chǔ)以及直連網(wǎng)線等。
服務(wù)器通常建議CPU、內(nèi)存和磁盤(pán)盡可能的大，磁盤(pán)建議用普通SSD盤(pán)。普通服務(wù)器的好處是便宜，劣勢(shì)是可靠性和性能可能不如小型機(jī)那么高。也就是說(shuō)OceanBase可以部署在一組可靠性和性能不是特別高的普通服務(wù)器上，卻提供了高性能、高可用和高可靠、彈性伸縮等多項(xiàng)能力。
?
以上是一個(gè)OceanBase集群的外觀和能力，但是提供給業(yè)務(wù)的并不是這個(gè)集群的全部資源和能力，而是其子集，即租戶（Tenant）。
?
OceanBase多租戶特性
OceanBase定義了一些基本的資源規(guī)格（Resource unit config，如4CPU8Gmem500Gdisk等），然后選取某類(lèi)資源規(guī)格創(chuàng)建一組資源池（Resource Pool），此時(shí)集群資源就有一部分被分配出去了。最后將這個(gè)資源池關(guān)聯(lián)到一個(gè)新建租戶，則租戶就可以使用這個(gè)資源池的能力。
OceanBase默認(rèn)有個(gè)sys租戶，管理整個(gè)集群。用戶租戶必須在sys租戶內(nèi)部創(chuàng)建。
?
如下示例就是創(chuàng)建租戶的過(guò)程。
#sys租戶登錄方法
$mysql -hxxx.xx.11.11 -uroot@sys#obdemo -P2883 -proot oceanbase -A
#資源規(guī)格（UnitConfig）
create?resourceunit?S0_uc max_cpu=2,max_memory='5G',…
資源單元（Unit）
create?resourcepool?Pool_01 unit='S0_uc',unit_num=2,...
租戶（Tenant）
create?tenant?test_ins resource_pool_list=?('Pool_01'),...
?
OceanBase兼容了大部分MySQL連接協(xié)議和語(yǔ)法，租戶的使用體驗(yàn)跟MySQL實(shí)例很像。研發(fā)可以在租戶里創(chuàng)建數(shù)據(jù)庫(kù)（Database）、表（Table）。還包括分區(qū)表等。
OceanBase里描述數(shù)據(jù)的最小粒度是分區(qū)。普通的表（非分區(qū)表）就是一個(gè)分區(qū)，分區(qū)表則包含多個(gè)分區(qū)。
?
租戶的示意圖如下。租戶之間數(shù)據(jù)是絕對(duì)隔離，資源有一定程度隔離。研發(fā)可以將業(yè)務(wù)先垂直拆分為多個(gè)獨(dú)立的子業(yè)務(wù)，分別使用不同的租戶或者集群。
圖2 OceanBase多租戶示意圖
?
OceanBase資源單元
租戶里并不知道數(shù)據(jù)具體在哪個(gè)機(jī)器上，也可以說(shuō)沒(méi)必要知道。只是租戶的性能還取決于運(yùn)維為租戶規(guī)劃的資源池分布情況，所以了解一下資源單元的分布特點(diǎn)對(duì)性能規(guī)劃也是有意義的。
資源池（Resource Pool）是由一組資源單元（Resource Unit）組成。資源單元數(shù)量默認(rèn)跟Zone的數(shù)量一致或者是它的倍數(shù)（可以配置具體分布在哪些Zone以及每個(gè)Zone里的Unit數(shù)量）。如下圖
?
圖 3 OceanBase 資源池分配示意圖
?
資源單元具備一定的資源能力，是數(shù)據(jù)的容器。租戶擁有的資源單元規(guī)格和數(shù)量決定了這個(gè)租戶最大性能。資源單元可以在同一個(gè)Zone的不同節(jié)點(diǎn)之間自由遷移，OceanBase借此來(lái)維持各個(gè)節(jié)點(diǎn)的資源利用率盡可能維持一個(gè)均衡狀態(tài)。
?
OceanBase拆分設(shè)計(jì)
數(shù)據(jù)庫(kù)拆分
數(shù)據(jù)庫(kù)拆分有兩種。
?
一是垂直拆分。即按業(yè)務(wù)模塊拆分到不同的實(shí)例或庫(kù)里。為了模塊之間互不影響，拆分到不同的實(shí)例比較好。在OceanBase里實(shí)現(xiàn)時(shí)可以是拆分到同一個(gè)集群里不同租戶或者不同集群里的租戶都可以，取決于業(yè)務(wù)規(guī)模和數(shù)據(jù)庫(kù)集群規(guī)模。垂直拆分很好理解，后面不再贅述。
?
一是水平拆分。即按某個(gè)業(yè)務(wù)維度將數(shù)據(jù)拆分到多個(gè)分片。這些分片可以是在一個(gè)庫(kù)或者不同庫(kù)或者不同實(shí)例的不同庫(kù)下。水平拆分實(shí)現(xiàn)又有兩類(lèi)常用的選擇。如下：
-
分庫(kù)分表。將一個(gè)業(yè)務(wù)表拆分到N個(gè)相同結(jié)構(gòu)的物理表中。中間件做業(yè)務(wù)表（邏輯表）到分表（物理表）的映射路由以及其他相關(guān)操作（如結(jié)果聚合計(jì)算）等。這個(gè)N個(gè)物理表可以在不同實(shí)例的不同分庫(kù)中。分庫(kù)的維度和分表的維度可以不一樣，比較靈活。
-
分區(qū)表。將一個(gè)物理表設(shè)計(jì)為分區(qū)表，拆分到N個(gè)分區(qū)。分區(qū)表的各個(gè)分區(qū)結(jié)構(gòu)是數(shù)據(jù)庫(kù)內(nèi)部保證一致。OceanBase選擇的是分區(qū)表的水平拆分方式，并且支持二級(jí)分區(qū)表（即有2個(gè)不同的拆分維度疊加使用）。
?
水平拆分示意圖如下：
圖 4? 水平拆分的分庫(kù)分表和分區(qū)表
?
上圖是分庫(kù)分表和分區(qū)表同時(shí)結(jié)合使用。業(yè)務(wù)表order先經(jīng)過(guò)中間件拆分為100個(gè)分表（存在10個(gè)分庫(kù)里），每個(gè)分表在OceanBase內(nèi)部又是一個(gè)分區(qū)表（100個(gè)分區(qū)）。分庫(kù)分表的維度和分區(qū)表分區(qū)的維度都是一致的，根據(jù)用戶ID。
?
分庫(kù)分表和分區(qū)各有利弊。
分庫(kù)分表的好處是各個(gè)分表的結(jié)構(gòu)一致性是在中間件層保證，比較好控制，比較適合灰度變更（允許部分分表結(jié)構(gòu)不一致，最終必須全部一致）。此外更大的好處是，分庫(kù)分表是實(shí)現(xiàn)異地多活單元話架構(gòu)的必不可少的條件。缺點(diǎn)是中間件的SQL支持范圍有限。
分區(qū)的好處是在數(shù)據(jù)庫(kù)內(nèi)部解決了拆分問(wèn)題。針對(duì)分區(qū)表的SQL功能是數(shù)據(jù)庫(kù)SQL引擎的本質(zhì)工作，相關(guān)特性（全局索引、二級(jí)分區(qū)等）會(huì)持續(xù)開(kāi)發(fā)完善。
?
分區(qū)
分庫(kù)分表架構(gòu)設(shè)計(jì)，需要確定機(jī)器數(shù)、實(shí)例數(shù)、分庫(kù)數(shù)和分表數(shù)的拓?fù)?#xff0c;性能理論上限取決于主實(shí)例所處的機(jī)器節(jié)點(diǎn)數(shù)。此后要做擴(kuò)展就要調(diào)整這四個(gè)元素的數(shù)目及其聯(lián)系。這種擴(kuò)展很可能涉及到分表數(shù)據(jù)的遷移，需要借助外部工具或產(chǎn)品實(shí)現(xiàn)。
?
分區(qū)架構(gòu)設(shè)計(jì)，研發(fā)確定分區(qū)策略和分區(qū)數(shù)，運(yùn)維確定租戶的資源單元數(shù)量，OceanBase確定資源單元（Unit）在哪些機(jī)器節(jié)點(diǎn)上以及分區(qū)（Partition）在哪些資源單元里。同一個(gè)分區(qū)不能跨節(jié)點(diǎn)存儲(chǔ)。如下圖。此后要做擴(kuò)展就是調(diào)整資源單元的規(guī)格、數(shù)量。
?
OceanBase在確定Unit里的分區(qū)的位置時(shí)會(huì)盡量讓每個(gè)節(jié)點(diǎn)的負(fù)載維持均衡。這個(gè)負(fù)載的計(jì)算方式比較復(fù)雜，會(huì)綜合考慮OB節(jié)點(diǎn)內(nèi)部CPU、內(nèi)存和空間利用率等。分區(qū)隨意分布對(duì)應(yīng)用性能很可能有負(fù)面影響。當(dāng)業(yè)務(wù)上有聯(lián)系的兩個(gè)表的分區(qū)分布在不同的資源單元里（同時(shí)也分布在不同的節(jié)點(diǎn)里），這兩個(gè)表的連接就難以避免跨節(jié)點(diǎn)請(qǐng)求數(shù)據(jù)，網(wǎng)絡(luò)上的延時(shí)會(huì)影響這個(gè)連接的性能。
?
圖5 分區(qū)在資源單元中的位置
注： t1(p0) 表示表t1的0號(hào)分區(qū)。
?
每個(gè)分區(qū)在集群里數(shù)據(jù)實(shí)際有三份，即三副本（Replica）。圖中忽略了Zone2和Zone3的細(xì)節(jié)。三副本之間的數(shù)據(jù)同步靠把Leader副本的事務(wù)日志同步到其他Follower副本中。Paxos協(xié)議會(huì)保障這個(gè)事務(wù)日志傳輸?shù)目煽啃?#xff08;事務(wù)日志在一半以上成員里落盤(pán)，剩余成員最終也會(huì)落盤(pán)），同時(shí)還有個(gè)以分區(qū)為粒度的選舉機(jī)制，保障Leader副本不可用的時(shí)候，能快速?gòu)默F(xiàn)有兩個(gè)Follower副本里選舉出新的Leader副本，并且數(shù)據(jù)還絕對(duì)不丟。這里就體現(xiàn)了故障切換時(shí)兩個(gè)重要指標(biāo)：RPO=0， RTO<30s。
?
Locality
圖5中t0和t1業(yè)務(wù)上是有聯(lián)系的表（如主表和詳情表），兩者都是分區(qū)表，分區(qū)策略和分片數(shù)都相同，OceanBase提供了一個(gè)表屬性“表分組”（TableGroup）。設(shè)置為同一個(gè)表分組的不同表的分區(qū)數(shù)一定一樣，并且同號(hào)分區(qū)組成一個(gè)“分區(qū)分組”（PartitionGroup）。同一個(gè)分區(qū)分組的分區(qū)一定會(huì)分配在同一個(gè)資源單元（Unit）內(nèi)部（也就是會(huì)在同一個(gè)節(jié)點(diǎn)內(nèi)部），彼此的連接邏輯就避免了跨節(jié)點(diǎn)請(qǐng)求。另外一個(gè)效果是如果一個(gè)事務(wù)同時(shí)修改兩個(gè)有業(yè)務(wù)關(guān)聯(lián)的分區(qū)，使用分區(qū)分組也可以規(guī)避跨節(jié)點(diǎn)的分布式事務(wù)。這個(gè)表分組屬性的設(shè)置就是OceanBase的Locality特性之一——影響相關(guān)分區(qū)的分布。
?
實(shí)際上每個(gè)分區(qū)都有三副本（Replica, 本文例子），圖5中省略了t0(p0)和t1(p0)的其他兩個(gè)副本都分別會(huì)在同一個(gè)Unit里分配。不僅如此，每個(gè)分區(qū)的三副本里都會(huì)有l(wèi)eader副本默認(rèn)提供讀寫(xiě)服務(wù)。leader副本是選舉出來(lái)的。t0(p0)和t1(p0)的leader副本也一定會(huì)在同一個(gè)Unit里（即在同一個(gè)Zone里）。這樣才徹底的避免了連接的時(shí)候跨節(jié)點(diǎn)請(qǐng)求。
?
OceanBase的Locality特性還可以指定租戶/數(shù)據(jù)庫(kù)/表的默認(rèn)Zone，這樣下面的表的leader副本會(huì)優(yōu)先被選舉為這個(gè)Zone里副本。
如下面例子，數(shù)據(jù)庫(kù)和表會(huì)繼承租戶的默認(rèn)設(shè)置，當(dāng)然也可以自己修改primary_zone或者locality屬性覆蓋上層設(shè)置。：
create?tenant?obtrans0primary_zone='hz1';
create table item (…)locality?= 'F@hz1, F@hz2, F@hz3,R{all_server}@hz1, R{all_server}@hz2, R{all_server}@hz3'
注：F表示全功能副本，R表示只讀副本。
?
設(shè)置primary_zone后單個(gè)租戶的所有表的讀寫(xiě)都集中到一個(gè)Zone里，該租戶在其他zone里的Unit就沒(méi)有讀寫(xiě)壓力。通常這樣做是源于業(yè)務(wù)應(yīng)用的要求。如應(yīng)用的請(qǐng)求都是來(lái)自于這個(gè)Zone，為了規(guī)避應(yīng)用跨Zone讀寫(xiě)數(shù)據(jù)性能下降。不過(guò)primary_zone更大的意義在于當(dāng)集群里有很多租戶的時(shí)候，可以將不同業(yè)務(wù)租戶的讀寫(xiě)壓力分?jǐn)偟讲煌琙one的機(jī)器，這樣集群整體資源利用率提升，所有應(yīng)用的總體性能也得到提升。后面要介紹的異地多活架構(gòu)就充分利用OceanBase這個(gè)特性，在數(shù)據(jù)庫(kù)層面將拆分的表的業(yè)務(wù)讀寫(xiě)點(diǎn)盡可能分散到所有Zone的所有機(jī)器上。
?
除了表與表之間可能有聯(lián)系，業(yè)務(wù)模塊之間也可能有聯(lián)系。一個(gè)業(yè)務(wù)過(guò)程可能會(huì)橫跨多個(gè)業(yè)務(wù)模塊，前面這些模塊的數(shù)據(jù)被垂直拆分到多個(gè)租戶里。OceanBase的Locality特性“租戶分組”（TenantGroup）還可以設(shè)置不同租戶之間的聯(lián)系。如下租戶交易訂單和支付訂單在業(yè)務(wù)上是先后發(fā)生。
create tenantgroup tgtrade tenant_array=('obtrade0', 'obpay0');
租戶分組的意義依然是為了在分布式架構(gòu)下盡可能將一個(gè)業(yè)務(wù)流程內(nèi)多次數(shù)據(jù)庫(kù)請(qǐng)求都約束在同一個(gè)Zone或者Region（注：OceanBase將地域相鄰的Zone定義為一個(gè)Region）里。
?
?
?
OceanBase異地多活架構(gòu)
異地多活概念
異地多活的概念一直都有，只是內(nèi)涵不斷變化。以雙機(jī)房多活為例，應(yīng)用通常都是無(wú)狀態(tài)的，可以多地部署。數(shù)據(jù)庫(kù)有狀態(tài)，傳統(tǒng)數(shù)據(jù)庫(kù)只有主庫(kù)可以提供讀寫(xiě)，備庫(kù)最多只能提供只讀服務(wù)（如ORACLE的Active Dataguard）：
-
1. 應(yīng)用雙活，數(shù)據(jù)庫(kù)A地讀寫(xiě)，B地不可讀寫(xiě)。這種只有應(yīng)用多活，數(shù)據(jù)庫(kù)是異地備份容災(zāi)（無(wú)并發(fā)）。
-
2. 應(yīng)用雙活，數(shù)據(jù)庫(kù)A地讀寫(xiě)，B地只讀。這種也是應(yīng)用雙活，數(shù)據(jù)庫(kù)讀寫(xiě)分離（實(shí)例級(jí)并發(fā)）。
-
3. 應(yīng)用雙活，數(shù)據(jù)庫(kù)雙活，兩地應(yīng)用同時(shí)讀寫(xiě)不同表。這種數(shù)據(jù)庫(kù)雙向同步，應(yīng)用同時(shí)錯(cuò)開(kāi)寫(xiě)不同的數(shù)據(jù)（表級(jí)并發(fā)）。
-
4. 應(yīng)用雙活，數(shù)據(jù)庫(kù)雙活，兩地應(yīng)用同時(shí)讀寫(xiě)相同表不同記錄。這種數(shù)據(jù)庫(kù)雙向同步，應(yīng)用同時(shí)錯(cuò)開(kāi)寫(xiě)不同的數(shù)據(jù)（行級(jí)并發(fā)）。
-
5. 應(yīng)用雙活，數(shù)據(jù)庫(kù)雙活，兩地應(yīng)用同時(shí)讀寫(xiě)相同表相同記錄。這種數(shù)據(jù)庫(kù)雙向同步，應(yīng)用同時(shí)寫(xiě)相同的數(shù)據(jù)，最終會(huì)因?yàn)闆_突一方事務(wù)回滾（行級(jí)并發(fā)寫(xiě)沖突）
?
上面第1種情形，B地應(yīng)用是跨地域遠(yuǎn)程讀寫(xiě)數(shù)據(jù)庫(kù)。兩地距離較大的時(shí)候性能會(huì)很不好。2的B地應(yīng)用是本地訪問(wèn)數(shù)據(jù)庫(kù)。3，4，5三種情形兩地?cái)?shù)據(jù)庫(kù)都提供讀寫(xiě)服務(wù)，對(duì)應(yīng)用而言是本地訪問(wèn)數(shù)據(jù)庫(kù)，但到分布式數(shù)據(jù)庫(kù)內(nèi)部，其要讀寫(xiě)的數(shù)據(jù)是否正好在本地就取決于業(yè)務(wù)和數(shù)據(jù)庫(kù)的拆分設(shè)計(jì)。有這么一種情形，B地應(yīng)用訪問(wèn)B地?cái)?shù)據(jù)庫(kù)實(shí)例，請(qǐng)求的數(shù)據(jù)的寫(xiě)入點(diǎn)恰好是A地，這樣會(huì)走分布式數(shù)據(jù)庫(kù)內(nèi)部路由遠(yuǎn)程A地實(shí)例中拿到數(shù)據(jù)，性能上會(huì)有些下降，而業(yè)務(wù)可能不知道為什么。
?
OceanBase水平拆分方案
為了避免在分布式數(shù)據(jù)庫(kù)OceanBase內(nèi)部發(fā)生跨Zone請(qǐng)求，應(yīng)用的請(qǐng)求流量的水平拆分規(guī)則和數(shù)據(jù)的水平拆分規(guī)則要保持一致并聯(lián)動(dòng)，就可以實(shí)現(xiàn)真正的應(yīng)用向本地實(shí)例請(qǐng)求讀寫(xiě)的數(shù)據(jù)恰好就是在本地實(shí)例種。這就是Locality的用途所在。
?
圖 6 OceanBase集群異地多活水平拆分示意圖
?
首先業(yè)務(wù)架構(gòu)層面能根據(jù)用戶ID（uid）做拆分，將用戶拆分為100分。x和y是用戶直接相關(guān)的表，都根據(jù)uid拆分為100個(gè)分表，分布在5個(gè)不同的租戶里。x[00-19]表示20個(gè)分表。每個(gè)租戶的Leader分別分布在不同的Zone。uid:00-19表示 分到這20個(gè)分片的用戶數(shù)據(jù)和用戶流量。
應(yīng)用層面在某個(gè)環(huán)節(jié)能根據(jù)UID將用戶請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的機(jī)房（Zone），應(yīng)用服務(wù)之間的請(qǐng)求信息都有這個(gè)UID信息，后面應(yīng)用請(qǐng)求都在本機(jī)房流轉(zhuǎn)，并且訪問(wèn)數(shù)據(jù)庫(kù)時(shí)通過(guò)分庫(kù)分表中間件（DBP）和OceanBase的反向代理（OBProxy）就路由到本機(jī)房的業(yè)務(wù)租戶上。
?
實(shí)際使用這個(gè)架構(gòu)時(shí)，有幾個(gè)隱含的前提，Zone1和Zone2是同城雙機(jī)房，Zone3和Zone4是同城雙機(jī)房，兩個(gè)城市靠的比較近，Zone5 實(shí)際很遠(yuǎn)，所以一般不提供寫(xiě)入。為節(jié)省空間，Zone5里的副本放的是日志副本。
應(yīng)用異地多活架構(gòu)
上面要實(shí)現(xiàn)OceanBase在每個(gè)Zone的應(yīng)用寫(xiě)入都是恰好是本地訪問(wèn)，關(guān)鍵點(diǎn)就是應(yīng)用流量水平拆分規(guī)則跟數(shù)據(jù)水平拆分規(guī)則保持一致。而應(yīng)用要維持這樣一個(gè)規(guī)則，需要很多產(chǎn)品都要支持水平拆分等。如下圖
圖 7 應(yīng)用三地五中心多活解決方案
?
圖中流量接入層的“負(fù)載均衡”環(huán)節(jié)負(fù)責(zé)調(diào)整用戶流量到對(duì)應(yīng)的機(jī)房（Zone），此后的應(yīng)用之間的請(qǐng)求就都是本地訪問(wèn)。
能使用這個(gè)解決方案的業(yè)務(wù)都是能按用戶維度做水平拆分。有些業(yè)務(wù)的拆分維度跟用戶維度是沖突的，或者有些業(yè)務(wù)的數(shù)據(jù)只支持集中寫(xiě)入等，不能做到上面這種多活，但也可以使用OceanBase，實(shí)現(xiàn)單點(diǎn)寫(xiě)入，多點(diǎn)讀取的功能。
OceanBase在異地容災(zāi)和多活架構(gòu)方案中的價(jià)值就是支持水平拆分規(guī)則的定義、解決了多個(gè)機(jī)房間數(shù)據(jù)同步和一致性問(wèn)題、始終具備高可用和彈性伸縮能力等。
?
參考
-
OceanBase負(fù)載均衡的魅力
-
螞蟻金服異地多活的微服務(wù)體系
總結(jié)
以上是生活随笔為你收集整理的如何基于OceanBase构建应用和数据库的异地多活的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： sklearn svm
- 下一篇： 2019年前端的3个趋势