整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
本文曾獲阿里內(nèi)網(wǎng)ATA“峰云之巔”獎。未經(jīng)允許，不得轉(zhuǎn)載。本文曾被大量轉(zhuǎn)載和修改文章標(biāo)題，給本人帶來了極大的傷害。
一年一度的雙十一又要來了，自2008年雙十一以來，在每年雙十一超大規(guī)模流量的沖擊上，螞蟻金服都會不斷突破現(xiàn)有技術(shù)的極限。2010年雙11的支付峰值為2萬筆/分鐘，全天1280萬筆支付，這個數(shù)字到2017雙11時變?yōu)榱?5.6萬筆/秒，全天14.8億筆。在如此之大的支付TPS背后除了削峰等錦上添花的應(yīng)用級優(yōu)化，最解渴最實質(zhì)的招數(shù)當(dāng)數(shù)基于分庫分表的單元化了，螞蟻技術(shù)稱之為LDC（邏輯數(shù)據(jù)中心）。本文不打算討論具體到代碼級的分析，而是嘗試用最簡單的描述來說明其中最大快人心的原理。我想關(guān)心分布式系統(tǒng)設(shè)計的人都曾被下面這些問題所困擾過：
如果你對這些感興趣，不妨看一場赤裸裸的論述，拒絕使用晦澀難懂的詞匯，直面最本質(zhì)的邏輯。
本文提及的所有關(guān)于支付寶和螞蟻的技術(shù)點均為網(wǎng)絡(luò)采集，未經(jīng)親自核實，請謹(jǐn)慎參考。如有涉及關(guān)鍵技術(shù)泄露請指明具體細(xì)節(jié)，并提供證據(jù)，比如到底是哪個點侵害了您的哪個權(quán)益。尤其是支付寶的公關(guān)和法務(wù)同學(xué)，不要聽風(fēng)就是雨，本文曾被大量轉(zhuǎn)載和修改名稱，尤其會攜帶一些“大廠揭秘”等具有誤導(dǎo)性的詞匯，請保持理性閱讀，過腦分析。按照個人的理解，本文不涉及任何關(guān)鍵技術(shù)細(xì)節(jié)，也不會給貴司帶來任何損失和負(fù)面作用。
LDC（logic data center)是相對于傳統(tǒng)的（Internet Data Center-IDC）提出的，邏輯數(shù)據(jù)中心所表達的中心思想是無論物理結(jié)構(gòu)如何的分布，整個數(shù)據(jù)中心在邏輯上是協(xié)同和統(tǒng)一的。這句話暗含的是強大的體系設(shè)計，分布式系統(tǒng)的挑戰(zhàn)就在于整體協(xié)同工作（可用性，分區(qū)容忍性）和統(tǒng)一（一致性）。
單元化是大型互聯(lián)網(wǎng)系統(tǒng)的必然選擇趨勢，舉個最最通俗的例子來說明單元化。我們總是說TPS很難提升，確實任何一家互聯(lián)網(wǎng)（比如淘寶、攜程、新浪）它的交易TPS頂多以十萬計量（平均水平），很難往上串了，因為數(shù)據(jù)庫存儲層瓶頸的存在再多水平擴展的服務(wù)器都無法繞開這個瓶頸，而從整個互聯(lián)網(wǎng)的視角看，全世界電商的交易TPS可以輕松上億。
這個例子帶給我們一些思考：為啥幾家互聯(lián)網(wǎng)的TPS之和可以那么大，服務(wù)的用戶數(shù)規(guī)模也極為嚇人，而單個互聯(lián)網(wǎng)的TPS卻很難提升？究其本質(zhì)，每家互聯(lián)網(wǎng)都是一個獨立的大型單元，他們各自服務(wù)自己的用戶互不干擾。這就是單元化的基本特性，任何一家互聯(lián)網(wǎng)公司，其想要成倍的擴大自己系統(tǒng)的服務(wù)能力，都必然會走向單元化之路，它的本質(zhì)是分治，我們把廣大的用戶分為若干部分，同時把系統(tǒng)復(fù)制多份，每一份都獨立部署，每一份系統(tǒng)都服務(wù)特定的一群用戶，以淘寶舉例，這樣之后，就會有很多個淘寶系統(tǒng)分別為不同的用戶服務(wù)，每個淘寶系統(tǒng)都做到十萬TPS的話，N個這樣的系統(tǒng)就可以輕松做到N*十萬的TPS了。
LDC實現(xiàn)的關(guān)鍵就在于單元化系統(tǒng)架構(gòu)設(shè)計，所以據(jù)說在螞蟻金服內(nèi)部，LDC和單元化是不分家的，這也是很多同學(xué)比較困擾的地方，看似沒啥關(guān)系，實則是單元化體系設(shè)計成就了LDC。
小結(jié)：分庫分表解決的最大痛點是數(shù)據(jù)庫單點瓶頸，這個瓶頸的產(chǎn)生是由現(xiàn)代二進制數(shù)據(jù)存儲體系決定的（即I/O速度）。單元化只是分庫分表后系統(tǒng)部署的一種方式，這種部署模式在災(zāi)備方面也發(fā)揮了極大的優(yōu)勢。
幾乎任何規(guī)模的互聯(lián)網(wǎng)公司，都有自己的系統(tǒng)架構(gòu)迭代和更新，大致的演化路徑都大同小異。最早一般為了業(yè)務(wù)快速上線，所有功能都會放到一個應(yīng)用里，系統(tǒng)架構(gòu)如圖1所示。
這樣的架構(gòu)顯然是有問題的，單機有著明顯的單點效應(yīng)，單機的容量和性能都是很局限的，而使用中小型機會帶來大量的浪費。 隨著業(yè)務(wù)發(fā)展，這個矛盾逐漸轉(zhuǎn)變?yōu)橹饕埽虼斯こ處焸儾捎昧艘韵录軜?gòu)。
通過對應(yīng)用進行水平擴展可以大幅度提高服務(wù)器容量，這時候應(yīng)用代碼還是一份，里面五臟俱全，只是應(yīng)用代碼運行在多個服務(wù)器實例上。這也是整個公司第一次觸碰到分布式，它的理論基礎(chǔ)是將多個微機的計算能力團結(jié)起來，其效果可以完勝同等價格的中小型機器。隨著業(yè)務(wù)進一步發(fā)展，用量到達了百萬級，慢慢的大家發(fā)現(xiàn)，應(yīng)用服務(wù)器CPU都很正常了，但是還是有很多慢請求，究其原因，是因為單點數(shù)據(jù)庫帶來了性能瓶頸。于是程序員們決定使用主從結(jié)構(gòu)的數(shù)據(jù)庫集群，如下圖所示。
其中大部分讀操作可以直接訪問從庫，從而減輕主庫的壓力。然而這種方式還是無法解決寫瓶頸，寫依舊需要主庫來處理，當(dāng)業(yè)務(wù)量量級再次增高時，寫已經(jīng)變成刻不容緩的待處理瓶頸。這時候，分庫分表方案出現(xiàn)了。
分庫分表不僅可以對相同的庫進行更細(xì)的業(yè)務(wù)拆分，還可以進行對同一張表進行拆分，對表進行拆分的方式叫做水平拆分。原本在同一個庫中不同功能表拆分后放到不同的數(shù)據(jù)庫中，這種方式對應(yīng)的是垂直拆分（按照業(yè)務(wù)功能進行拆分），此時一般還對應(yīng)了微服務(wù)化。分庫分表往往按照用戶ID進行散列，不同用戶的數(shù)據(jù)訪問請求會在固定的不同數(shù)據(jù)庫實例上進行處理，這種方法做到極致基本能支撐TPS在萬級甚至更高的訪問量了。
然而這種模式下需要每個擴展出的應(yīng)用都連接所有的數(shù)據(jù)庫實例以保證任意用戶的請求在本應(yīng)用都能進行處理，隨著應(yīng)用擴展的越多，每個數(shù)據(jù)庫實例的連接數(shù)也成倍增長，而數(shù)據(jù)庫服務(wù)器的連接數(shù)量一般是恒定的，因此無法跟著可以無限擴容的應(yīng)用服務(wù)實例增長而同比增長，這種機制是出于對數(shù)據(jù)庫的保護而設(shè)計的。
事實上即便數(shù)據(jù)庫連接池可以無限增長，應(yīng)用服務(wù)也會花費大量的性能消耗在維護與每個分庫的數(shù)據(jù)庫連接池上。比如在16個分庫200臺水平擴展應(yīng)用的情況下，若每個應(yīng)用與數(shù)據(jù)庫的連接池在100個，那么每臺應(yīng)用上的數(shù)據(jù)庫連接數(shù)量將高達1600個，每臺數(shù)據(jù)庫服務(wù)實例上維護的連接數(shù)量達20000個。雖然對于任意一臺數(shù)據(jù)庫來說不代表同時會有20000個連接在傳輸數(shù)據(jù)，但由于系統(tǒng)實際運行時的各種不可預(yù)期的復(fù)雜調(diào)用（比如原先估計同時最多只有200個連接在讀寫數(shù)據(jù)——根據(jù)數(shù)據(jù)庫服務(wù)的容量進行合理計算得出，實際上一旦將最大連接數(shù)設(shè)置為20000個連接，同時讀寫的連接數(shù)超過200會變得非常常見）和請求流轉(zhuǎn)以及數(shù)據(jù)庫服務(wù)器中連接調(diào)度的性能消耗，這20000個始終保持存活的連接將逐步成為數(shù)據(jù)庫訪問的瓶頸，從而影響整個系統(tǒng)。
Mysql等數(shù)據(jù)庫的主流用法中都是在數(shù)據(jù)訪問期間獨占連接，而不是像HTTP2.0那樣允許多路復(fù)用的純異步訪問，這是由于SQL語句的執(zhí)行必須要符合順序性，否則一致性將被破壞。對于那些完全不需要一致性的業(yè)務(wù)（作者也舉不出來例子但應(yīng)該是存在的），可能可以使用異步執(zhí)行模式，在那種情況下數(shù)據(jù)庫連接瓶頸的問題或可以得到解決。
從本質(zhì)上看，這種模式的資源隔離性還不夠徹底，總會存在資源間互相污染的情況，這些污染最終會變現(xiàn)為系統(tǒng)的急劇熵增。要徹底讓資源進行隔離，就需要按照某種規(guī)則將網(wǎng)絡(luò)訪問用戶進行分流，讓一套服務(wù)和數(shù)據(jù)庫為某個特定群體進行服務(wù)——就像每個電商平臺一樣，這樣一來凡是來自這個用戶的所有請求都會由其對應(yīng)的應(yīng)用服務(wù)和數(shù)據(jù)庫實例來處理，而不會影響其他的服務(wù)和數(shù)據(jù)庫。這樣帶來另外一個變化就是識別用戶分庫的邏輯需要往上層移動——從數(shù)據(jù)庫層向上移動到路由網(wǎng)關(guān)層。當(dāng)網(wǎng)關(guān)識別到A用戶時通過散列算法將其分配到對應(yīng)的應(yīng)用服務(wù)器(Server-A)，最后數(shù)據(jù)持久化到對應(yīng)的數(shù)據(jù)庫實例DB-1，因此Server-A也不再需要鏈接其他的數(shù)據(jù)庫實例了，如此一個單元化的雛形就誕生了。
如上圖所示，但我們把整套系統(tǒng)打包為單元化時，每一類的數(shù)據(jù)從進單元開始就注定在這個單元被消化，由于這種徹底的隔離性，整個單元可以輕松的部署到任意機房而依然能保證邏輯上的統(tǒng)一。下圖為一個三地五機房的部署方式。
螞蟻支付寶應(yīng)該是國內(nèi)最大的支付工具，其在雙十一等活動日當(dāng)日的支付TPS可達幾十萬級，未來這個數(shù)字可能會更大，這決定了螞蟻單元化架構(gòu)從容量要求上看必然從單機房走向多機房。另一方面，異地災(zāi)備也決定了這些IDC機房必須是異地部署的。 整體上支付寶也采用了三地五中心（IDC機房）來保障系統(tǒng)的可用性[7]，跟2.1中描述的有所不同的是，支付寶將單元分成了三類（也稱CRG架構(gòu)）[8]：
“寫讀時間差現(xiàn)象”是架構(gòu)師們根據(jù)實踐統(tǒng)計總結(jié)的，他們發(fā)現(xiàn)大部分情況下，一個數(shù)據(jù)被寫入后，都會過足夠長的時間后才會被訪問。生活中這種例子很常見，我們辦完銀行卡后可能很久才會存第一筆錢；我們創(chuàng)建微博賬號后，可能想半天才會發(fā)微博；我們下載創(chuàng)建淘寶賬號后，可能得瀏覽好幾分鐘才會下單買東西。當(dāng)然了這些例子中的時間差遠遠超過了系統(tǒng)同步時間。一般來說異地的延時在100ms以內(nèi)，所以只要滿足某地CZone寫入數(shù)據(jù)后100ms以后才用這個數(shù)據(jù)，這樣的數(shù)據(jù)和服務(wù)就適合放到CZone中。
相信大家看到這都會問：為啥分這三種單元？其實其背后對應(yīng)的是不同性質(zhì)的數(shù)據(jù)，而服務(wù)不過是對數(shù)據(jù)的操作集。下面我們來根據(jù)數(shù)據(jù)性質(zhì)的不同來解釋支付寶的CRG架構(gòu)。當(dāng)下幾乎所有互聯(lián)網(wǎng)公司的分庫分表規(guī)則都是根據(jù)用戶ID來制定的，而圍繞用戶來看整個系統(tǒng)的數(shù)據(jù)可以分為以下兩類：用戶專屬型數(shù)據(jù)和用戶間共享型數(shù)據(jù)。
注：網(wǎng)上和支付寶內(nèi)部有另外一些分法，比如流水型和狀態(tài)性，有時候還會分為三類：流水型、狀態(tài)型和配置型。
（1）用戶專屬型數(shù)據(jù)
代表只有用戶自己會訪問的數(shù)據(jù)，典型的有用戶的訂單、用戶發(fā)的評論、用戶的行為記錄等。這些數(shù)據(jù)都是用戶行為產(chǎn)生的流水型數(shù)據(jù)，具備天然的用戶隔離性，比如A用戶的App上絕對看不到B用戶的訂單列表。所以此類數(shù)據(jù)非常適合分庫分表后獨立部署服務(wù)，即按照用戶ID散列部署為RZone。
（2）用戶共享型數(shù)據(jù)
代表所有的用戶都可能訪問的數(shù)據(jù)。由于數(shù)據(jù)可能會被所有用戶訪問，將提供這類數(shù)據(jù)的服務(wù)部署到RZone就變得不合適了，因為RZone可能被分布在全國各地，高頻的遠程調(diào)用并不經(jīng)濟。用戶共享型數(shù)據(jù)又可以進一步分為以下幾類：
以上只是從數(shù)據(jù)特性上做了分類，具體的案例場景并不具備必然的參考意義，具體使用什么方式部署，需要結(jié)合業(yè)務(wù)場景進行判斷。即便在支付寶的實際應(yīng)用中，各個系統(tǒng)仍然存在不合理的CRG分類，尤其是CG不分的現(xiàn)象很常見。為了避免過度設(shè)計，作者建議共享型數(shù)據(jù)服務(wù)一開始可以優(yōu)先考慮放到GZone中，當(dāng)逐步發(fā)現(xiàn)瓶頸時再對數(shù)據(jù)做劃分，逐步引入CZone。
單元化后，異地多活從未如此簡單——只需要在多地進行單元部署而已。比如上海的兩個單元負(fù)責(zé)用戶ID范圍為[00~19],[40~59]的用戶服務(wù)，而杭州的兩個單元為ID為[20~39]和[60,79]的用戶服務(wù)，這樣上海和杭州就是異地雙活的。
支付寶對單元化的基本要求是每個單元都具備服務(wù)所有用戶的能力，以應(yīng)對不可預(yù)期的天災(zāi)人禍，即具體的哪個單元服務(wù)哪些用戶是可以動態(tài)配置的。所以異地雙活的這些單元還充當(dāng)了彼此的備份。
發(fā)現(xiàn)工作中冷備熱備已經(jīng)被用的很亂了。最早冷備是指數(shù)據(jù)庫在備份數(shù)據(jù)時需要關(guān)閉后進行備份（也叫離線備份），防止數(shù)據(jù)備份過程中又修改了，不需要關(guān)閉即在運行過程中進行數(shù)據(jù)備份的方式叫做熱備(也叫在線備份)[9]。也不知道從哪一天開始，冷備在主備系統(tǒng)里代表了這臺備用機器是關(guān)閉狀態(tài)的，只有主服務(wù)器掛了之后，備服務(wù)器才會被啟動；而相同的熱備變成了備服務(wù)器也是啟動的，只是沒有流量而已，一旦主服務(wù)器掛了之后，流量自動打到備服務(wù)器上。本文不打算用第二種理解，因為感覺有點野、、、
為了做到每個單元訪問哪些用戶變成可配置，支付寶要求單元化管理系統(tǒng)具備流量到單元的可配置以及單元到DB的可配置能力，如下圖所示：
其中spanner是基于nginx自研的反向代理網(wǎng)關(guān)，也很好理解，有些請求我們希望在反向代理層就被轉(zhuǎn)發(fā)至其他IDC的spanner而無需進入后端服務(wù)，如圖箭頭2所示。那么對于應(yīng)該在本IDC處理的請求，就直接映射到對應(yīng)的RZ即可，如圖箭頭1。進入后端服務(wù)后，理論上如果請求只是讀取用戶專屬型數(shù)據(jù)，那么一般不會再進行路由了。然而對于有些場景來說，A用戶的一個請求可能關(guān)聯(lián)了對B用戶數(shù)據(jù)的訪問，比如A轉(zhuǎn)賬給B，A扣完錢后要調(diào)用賬務(wù)系統(tǒng)去增加B的余額。這時候就涉及到再次的路由，同樣有兩個結(jié)果：跳轉(zhuǎn)到其他IDC（如圖箭頭3）或是跳轉(zhuǎn)到本IDC的其他RZone（如圖箭頭4）。
RZone到DB數(shù)據(jù)分區(qū)的訪問這是事先配置好的，上圖中RZ和DB數(shù)據(jù)分區(qū)的關(guān)系為：
RZ0* --> a
RZ1* --> b
RZ2* --> c
RZ3* --> d
下面我們舉個例子來說明整個流量挑撥的過程，假設(shè)C用戶所屬的數(shù)據(jù)分區(qū)是c，而C用戶在杭州訪問了cashier.xxx.com（隨便編的）。
（1）首先默認(rèn)會按照地域來路由流量，具體的實現(xiàn)承載者是全局負(fù)載均衡GLSB（Global Server Load Balancing），它會根據(jù)請求者的IP，自動將cashier.xxx.com解析為杭州IDC的IP地址（或者跳轉(zhuǎn)到IDC所在的域名）。自己搞過網(wǎng)站的同學(xué)應(yīng)該知道大部分DNS服務(wù)商的地址都是靠人去配置的，GLSB屬于動態(tài)配置域名的系統(tǒng)，網(wǎng)上也有比較火的類似產(chǎn)品，比如花生殼之類（建過私站的同學(xué)應(yīng)該很熟悉）的。
（2）好了，到此為止，用戶的請求來到了IDC-1的Spanner集群服務(wù)器上，Spanner從內(nèi)存中讀取到了路由配置，知道了這個請求的主體用戶C所屬的RZ3*不在本IDC，于是直接轉(zhuǎn)到了IDC-2進行處理。
（3）進入IDC-2之后，根據(jù)流量配比規(guī)則，該請求被分配到了RZ3B進行處理。
（4）RZ3B得到請求后對數(shù)據(jù)分區(qū)c進行訪問。
（5）處理完畢后原路返回。
大家應(yīng)該發(fā)現(xiàn)問題所在了，如果再來一個這樣的請求，豈不是每次都要跨地域進行調(diào)用和返回體傳遞？確實是存在這樣的問題的，對于這種問題，支付寶架構(gòu)師們決定繼續(xù)把決策邏輯往用戶終端推移。比如，每個IDC機房都會有自己的域名（真實情況可能不是這樣命名的）: IDC-1對應(yīng)cashieridc-1.xxx.com IDC-2對應(yīng)cashieridc-2.xxx.com 那么請求從IDC-1涮過一遍返回時會將前端請求跳轉(zhuǎn)到cashieridc-2.xxx.com去（如果是APP，只需要替換rest調(diào)用的接口域名），后面所有用戶的行為都會在這個域名上發(fā)生，就避免了走一遍IDC-1帶來的延時。
流量挑撥是災(zāi)備切換的基礎(chǔ)和前提條件，發(fā)生災(zāi)難后的通用方法就是把陷入災(zāi)難的單元的流量重新打到正常的單元上去，這個流量切換的過程俗稱切流。支付寶LDC架構(gòu)下的災(zāi)備有三個層次：
（1）同機房單元間災(zāi)備
災(zāi)難發(fā)生可能性相對最高（但其實也很小）。對LDC來說，最小的災(zāi)難就是某個單元由于一些原因（局部插座斷開、線路老化、人為操作失誤）宕機了。從3.1節(jié)里的圖中可以看到每組RZ都有A，B兩個單元，這就是用來做同機房災(zāi)備的，并且AB之間也是雙活雙備的，正常情況下AB兩個單元共同分擔(dān)所有的請求，一旦A單元掛了，B單元將自動承擔(dān)A單元的流量份額。這個災(zāi)備方案是默認(rèn)的。
(2) 同城機房間災(zāi)備
災(zāi)難發(fā)生可能性相對更小。這種災(zāi)難發(fā)生的原因一般是機房電線網(wǎng)線被挖斷，或者機房維護人員操作失誤導(dǎo)致的。在這種情況下，就需要人工的制定流量挑撥（切流）方案了。下面我們舉例說明這個過程，如下圖所示為上海的兩個IDC機房。
整個切流配置過程分兩步，首先需要將陷入災(zāi)難的機房中RZone對應(yīng)的數(shù)據(jù)分區(qū)的訪問權(quán)配置進行修改；假設(shè)我們的方案是由IDC-2機房的RZ2和RZ3分別接管IDC-1中的RZ0和RZ1。那么首先要做的是把IDC2中的數(shù)據(jù)分區(qū)a，b對應(yīng)的訪問權(quán)從RZ0和RZ1收回。分配給RZ2和RZ3。即將（如上圖所示為初始映射）：
RZ0* --> a
RZ1* --> b
RZ2* --> c
RZ3* --> d
變?yōu)椋?/span>
RZ0* --> /
RZ1* --> /
RZ2* --> a
RZ2* --> c
RZ3* --> b
RZ3* --> d
然后再修改用戶ID和RZ之間的映射配置。假設(shè)之前為:
[00-24] --> RZ0A(50%),RZOB(50%)
[25-49] --> RZ1A(50%),RZ1B(50%)
[50-74] --> RZ2A(50%),RZ2B(50%)
[75-99] --> RZ3A(50%),RZ3B(50%)
那么按照災(zāi)備方案的要求，這個映射配置將變?yōu)椋?/span>
[00-24] --> RZ2A(50%),RZ2B(50%)
[25-49] --> RZ3A(50%),RZ3B(50%)
[50-74] --> RZ2A(50%),RZ2B(50%)
[75-99] --> RZ3A(50%),RZ3B(50%)
這樣之后，所有流量將會被打到IDC-2中，期間部分已經(jīng)向IDC-1發(fā)起請求的用戶會收到失敗并重試的提示。 實際情況中，整個過程并不是災(zāi)難發(fā)生后再去做的，整個切換的流程會以預(yù)案配置的形式事先準(zhǔn)備好，推送給每個流量挑撥客戶端（集成到了所有的服務(wù)和spanner中）。
這里可以思考下，為何先切數(shù)據(jù)庫映射，再切流量呢？這是因為如果先切流量，意味著大量注定失敗的請求會被打到新的正常單元上去，從而影響系統(tǒng)的穩(wěn)定性（數(shù)據(jù)庫還沒準(zhǔn)備好）。
(2) 異地機房間災(zāi)備
這個基本上跟同城機房間災(zāi)備一致（這也是單元化的優(yōu)點），不再贅述。
CAP原則是指任意一個分布式系統(tǒng)，同時最多只能滿足其中的兩項，而無法同時滿足三項。所謂的分布式系統(tǒng)，說白了就是一件事一個人做的，現(xiàn)在分給好幾個人一起干。我們先簡單回顧下CAP各個維度的含義[1]：
下圖為CAP之間的經(jīng)典關(guān)系圖：
還有個需要說明的地方，“分布式系統(tǒng)不可能同時滿足CAP“的前提條件是這個分布式系統(tǒng)一定是有讀有寫的，如果只考慮讀，那么CAP很容易都滿足，比如一個計算器服務(wù)，接受表達式請求，返回計算結(jié)果，搞成水平擴展的分布式，顯然這樣的系統(tǒng)沒有一致性問題，網(wǎng)絡(luò)分區(qū)也不怕，可用性也是很穩(wěn)的，所以可以滿足CAP。而對于需要分布式讀寫的系統(tǒng)則符合CAP約束，分布式讀寫意味著在A點寫入的數(shù)據(jù)，在B點也可以讀取，這樣的系統(tǒng)無法在任一時刻同時滿足CAP。
先說下CA和P的關(guān)系，如果不考慮P的話，系統(tǒng)是可以輕松實現(xiàn)CA的。而P并不是一個單獨的性質(zhì)，它代表的是目標(biāo)分布式系統(tǒng)有沒有對網(wǎng)絡(luò)分區(qū)的情況做容錯處理。如果做了處理，就一定是帶有P的，接下來再考慮分區(qū)情況下到底選擇了A還是C。所以分析CAP，建議先確定有沒有對分區(qū)情況做容錯處理。 以下是個人總結(jié)的分析一個分布式系統(tǒng)CAP滿足情況的一般方法：
if( 不存在分區(qū)的可能性 || 分區(qū)后不影響可用性或一致性 || 有影響但考慮了分區(qū)情況-P){
if(可用性分區(qū)容忍性-A under P)）
return "AP";
else if(一致性分區(qū)容忍性-C under P）
return "CP";
}
else{ //分區(qū)有影響但沒考慮分區(qū)情況下的容錯
if(具備可用性-A && 具備一致性-C）{
return AC;
}
}
這里說明下，如果考慮了分區(qū)容忍性，就不需要考慮不分區(qū)情況下的可用性和一致性了（大多是滿足的）。
讓我們再來回顧下分布式應(yīng)用系統(tǒng)的來由，早年每個應(yīng)用都是單體的，跑在一個服務(wù)器上，服務(wù)器一掛，服務(wù)就不可用了。另外一方面，單體應(yīng)用由于業(yè)務(wù)功能復(fù)雜，對機器的要求也逐漸變高，普通的微機無法滿足這種性能和容量的要求。所以要拆！還在IBM大賣小型商用機的年代，阿里巴巴就提出要以分布式微機替代小型機。所以我們發(fā)現(xiàn)，分布式系統(tǒng)解決的最大的痛點，就是單體單機系統(tǒng)的可用性問題。要想高可用，必須分布式。 一家互聯(lián)網(wǎng)公司的發(fā)展之路上，第一次與分布式相遇應(yīng)該都是在單體應(yīng)用的水平擴展上。也就是同一個應(yīng)用啟動了多個實例，連接著相同的數(shù)據(jù)庫（為了簡化問題，先不考慮數(shù)據(jù)庫是否單點），如下圖所示。
這樣的系統(tǒng)天然具有的就是AP（可用性和分區(qū)容忍性），一方面解決了單點導(dǎo)致的低可用性問題，另一方面無論這些水平擴展的機器間網(wǎng)絡(luò)是否出現(xiàn)分區(qū)，這些服務(wù)器都可以各自提供服務(wù)，因為他們之間不需要進行溝通。然而，這樣的系統(tǒng)是沒有一致性可言的，當(dāng)每個實例都可以往數(shù)據(jù)庫insert和update（注意這里還沒討論到事務(wù)）時，數(shù)據(jù)就亂套了。
于是我們轉(zhuǎn)向了讓DB去做這個事，這時候”數(shù)據(jù)庫事務(wù)”就被用上了。用大部分公司會選擇的Mysql/MariaDB來舉例，用了事務(wù)之后會發(fā)現(xiàn)數(shù)據(jù)庫又變成了單點和瓶頸。單點就像單機一樣(本例子中不考慮從庫模式)，理論上就不叫分布式了，如果一定要分析其CAP的話，根據(jù)4.1.2的步驟分析過程應(yīng)該是這樣的：
因此這樣的一個系統(tǒng)，個人認(rèn)為只是滿足了CP。A有但不出色，從這點可以看出，CAP并不是非黑即白的。包括常說的BASE[3]（最終一致性）方案，其實只是C不出色，但最終也是達到一致性的，BASE在一致性上選擇了退讓。
關(guān)于分布式應(yīng)用+單點數(shù)據(jù)庫的模式算不算純正的分布式系統(tǒng)，這個可能每個人看法有點差異，上述只是我個人的一種理解，是不是分布式系統(tǒng)不重要，重要的是分析過程。其實我們討論分布式，就是希望系統(tǒng)的可用性是多個系統(tǒng)多活的，一個掛了另外的也能頂上，顯然單機單點的系統(tǒng)不具備這樣的高可用特性。所以在我看來，廣義的說CAP也適用于單點單機系統(tǒng)，單機系統(tǒng)是CP的。說到這里，大家似乎也發(fā)現(xiàn)了，水平擴展的服務(wù)應(yīng)用+數(shù)據(jù)庫這樣的系統(tǒng)的CAP魔咒主要發(fā)生在數(shù)據(jù)庫層，因為大部分這樣的服務(wù)應(yīng)用都只是承擔(dān)了計算的任務(wù)（像計算器那樣），本身不需要互相協(xié)作，所有寫請求帶來的數(shù)據(jù)的一致性問題下沉到了數(shù)據(jù)庫層去解決。想象一下，如果沒有數(shù)據(jù)庫層，而是應(yīng)用自己來保障數(shù)據(jù)一致性，那么這樣的應(yīng)用之間就涉及到狀態(tài)的同步和交互了，分布式鎖就是一個典型的例子。
上一節(jié)我們討論了多應(yīng)用實例+單數(shù)據(jù)庫實例的模式，這種模式是分布式系統(tǒng)也好，不是分布式系統(tǒng)也罷，整體是偏CP的。現(xiàn)實中，技術(shù)人員們也會很快發(fā)現(xiàn)這種架構(gòu)的不合理性——可用性太低了。于是如下圖所示的模式成為了當(dāng)下大部分中小公司所使用的架構(gòu)：
從上圖我可以看到三個數(shù)據(jù)庫實例中只有一個是主庫，其他是從庫。一定程度上，這種架構(gòu)極大的緩解了”讀可用性”問題，而這樣的架構(gòu)一般會做讀寫分離來達到更高的”讀可用性”，幸運的是大部分互聯(lián)網(wǎng)場景中讀都占了80%以上，所以這樣的架構(gòu)能得到較長時間的廣泛應(yīng)用。對于”寫可用性”方面主備模式可以采用keepalived[4]等HA（高可用）框架來保證主庫的存活性，但實質(zhì)上這種方式并沒有帶來性能上的可用性提升，只是保證了宕機情況下的可用性，至少系統(tǒng)不會因為某個實例掛了就都不可用了。該分布式系統(tǒng)可用性勉強達標(biāo)了，具體的CAP分析如下：
所以這樣的一個系統(tǒng)，我們認(rèn)為它是CA的。我們再深入研究下，如果發(fā)生腦裂產(chǎn)生數(shù)據(jù)不一致后有一種方式可以仲裁一致性問題，是不是就可以滿足P了呢。還真有嘗試通過預(yù)先設(shè)置規(guī)則來解決這種多主庫帶來的一致性問題的系統(tǒng)，比如CouchDB，它通過版本管理來支持多庫寫入，在其仲裁階段會通過DBA配置的仲裁規(guī)則（也就是合并規(guī)則，比如誰的時間戳最晚誰的生效）進行自動仲裁（自動合并），從而保障最終一致性（BASE），自動規(guī)則無法合并的情況則只能依賴人工決策了。
在討論LDC架構(gòu)的CAP之前，我們再來想想分區(qū)容忍性有啥值得一提的，為啥很多大名鼎鼎的BASE（最終一致性）體系系統(tǒng)都選擇損失實時一致性，而不是丟棄分區(qū)容忍性呢？
分區(qū)的產(chǎn)生一般有兩種情況：
那么螞蟻是怎么解決這個問題的呢？我們在4.2的備注部分討論過，其實LDC機房的各個單元都由兩部分組成：負(fù)責(zé)業(yè)務(wù)邏輯計算的應(yīng)用服務(wù)器和負(fù)責(zé)數(shù)據(jù)持久化的數(shù)據(jù)庫。大部分應(yīng)用服務(wù)器就像一個個計算器，自身是不對寫一致性負(fù)責(zé)的，這個任務(wù)被下沉到了數(shù)據(jù)庫。所以螞蟻解決分布式一致性問題的關(guān)鍵就在于數(shù)據(jù)庫！
想必有些讀者大概猜到下面的討論重點了——OceanBase（下文簡稱OB），中國第一款自主研發(fā)的分布式數(shù)據(jù)庫，一時間也確實獲得了很多光環(huán)。在討論OB前，我們先來想想Why not MySQL?
首先，就像CAP三角圖中指出的，MySQL是一款滿足AC但不滿足P的分布式系統(tǒng)。試想一下，一個MySQL主從結(jié)構(gòu)的數(shù)據(jù)庫集群，當(dāng)出現(xiàn)分區(qū)時，問題分區(qū)內(nèi)的Slave會認(rèn)為主已經(jīng)掛了，所以自己成為本分區(qū)的master（腦裂），等分區(qū)問題恢復(fù)后，會產(chǎn)生2個主庫的數(shù)據(jù)，而無法確定誰是正確的，也就是分區(qū)導(dǎo)致了一致性被破壞。這樣的結(jié)果是嚴(yán)重的，這也是螞蟻寧愿自研OceanBase的原動力之一。
那么如何才能讓分布式系統(tǒng)具備分區(qū)容忍性呢？按照老慣例，我們從”可用性分區(qū)容忍”和”一致性分區(qū)容忍”兩個方面來討論。 (1) 可用性分區(qū)容忍性保障機制
可用性分區(qū)容忍的關(guān)鍵在于別讓一個事務(wù)依賴所有節(jié)點來完成，這個很簡單，別要求所有節(jié)點共同同時參與某個事務(wù)即可。
(2) 一致性分區(qū)容忍性保障機制
老實說，都產(chǎn)生分區(qū)了，哪還可能獲得實時一致性。但要保證最終一致性也不簡單，一旦產(chǎn)生分區(qū)，如何在2個分區(qū)無法通信的情況下保證只有有一份正確的提議呢？究其根本是要保障所有分區(qū)種有且只能有一個大腦，下面我們來看下共識算法PAXOS的核心——Quorum思想是如何解決腦裂問題的。
這里可以發(fā)散下，所謂的”腦”其實就是具備寫能力的系統(tǒng)，”非腦”就是只具備讀能力的系統(tǒng)，對應(yīng)了MySQL集群中的從庫。
下面是兩段摘自維基百科的PAXOS定義[5]：
Paxos is a family of protocols for solving consensus in a network of unreliable processors (that is, processors that may fail).
Quorums express the safety (or consistency) properties of Paxos by ensuring at least some surviving processor retains knowledge of the results.
這段話的意思是：PAXOS是在一群不可靠的節(jié)點組成的集群中的一類共識機制，而Quorum機制則用來保證。眾所周知Paxos算法可以解決分布式系統(tǒng)中的腦裂問題，但其中真正起作用的本質(zhì)思想是Quorum機制，翻譯過來叫做“法定數(shù)量機制”，在分布式領(lǐng)域，它往往要求任何一個提議在一個有N個節(jié)點的分布式系統(tǒng)中至少被(N/2)+1個系統(tǒng)節(jié)點所認(rèn)可，它才被認(rèn)為是可信的，這背后的理論基礎(chǔ)是少數(shù)服從多數(shù)——一個群體不可能存在2種對立的多數(shù)群體觀點。
只要多數(shù)節(jié)點認(rèn)可并持久化數(shù)據(jù)，即便整個系統(tǒng)宕機了，在重啟后該系統(tǒng)仍然可以通過一次互相通信知道哪個值是合法的——多數(shù)節(jié)點保留的那個值。這樣的設(shè)定也巧妙的解決了分區(qū)情況下的共識問題，因為一旦產(chǎn)生分區(qū)，勢必最多只有一個分區(qū)內(nèi)的節(jié)點數(shù)量會大于等于(N/2)+1。也有一些HA（高可用）方案通過依托于另一個仲裁系統(tǒng)來避免腦裂，比如大家同時Ping一個公共的IP，先成功者繼續(xù)為腦，然而顯然這就又制造了另外一個單點——仲裁系統(tǒng)的高可用誰來保障？
如果你了解過比特幣或者區(qū)塊鏈，你就知道區(qū)塊鏈的基礎(chǔ)理論也是Quorum法定數(shù)量機制。區(qū)塊鏈借助Quorum機制來抵御惡意篡改，分布式應(yīng)用系統(tǒng)則是借助Quorum來解決分區(qū)腦裂問題。不過區(qū)塊鏈假設(shè)的是網(wǎng)絡(luò)中存在拜占庭錯誤，因而法定數(shù)量并不是(N/2)+1，具體可搜索相關(guān)技術(shù)文章。
很多同學(xué)肯定聽說過這樣的描述——PAXOS是唯一能解決分布式一致性問題的解法。這句話越是理解越發(fā)覺得詭異，這會讓人以為PAXOS逃離于CAP約束了，所以個人更愿意理解為——PAXOS是唯一一種保障分布式系統(tǒng)最終一致性的共識算法（所謂共識算法，就是大家都按照這個算法來操作，大家最后的結(jié)果一定相同）。
PAXOS并沒有逃離CAP魔咒，畢竟達成共識是(N/2)+1的節(jié)點之間的事，剩下的(N/2)-1的節(jié)點上的數(shù)據(jù)還是舊的，這時候仍然是不一致的，所以PAXOS對一致性的貢獻在于經(jīng)過一次事務(wù)后，這個集群里已經(jīng)有部分節(jié)點保有了本次事務(wù)正確的結(jié)果（共識的結(jié)果），這個結(jié)果隨后會被異步的同步到其他節(jié)點上，從而保證最終一致性。以下摘自維基百科[5]：
另外PAXOS不要求對所有節(jié)點做實時同步，實質(zhì)上是考慮到了分區(qū)情況下的可用性，通過減少完成一次事務(wù)需要的參與者個數(shù)，來保障系統(tǒng)的可用性。
上文提到過，單元化架構(gòu)中的成千山萬的應(yīng)用就像是計算器，本身無CAP限制，其CAP限制和挑戰(zhàn)下沉到了數(shù)據(jù)庫層——螞蟻自研的分布式數(shù)據(jù)庫OceanBase（本節(jié)簡稱OB）[6]。在OB體系中，每個數(shù)據(jù)庫實例都具備讀寫能力，具體是讀是寫可以動態(tài)配置（參考2.2部分）。實際情況下大部分時候，對于某一類數(shù)據(jù)（固定用戶號段的數(shù)據(jù)）任意時刻只有一個單元會負(fù)責(zé)寫入某個節(jié)點，其他節(jié)點要么是實時庫間同步，要么是異步數(shù)據(jù)同步。OB也采用了PAXOS共識協(xié)議，實時庫間同步的節(jié)點(包含自己)個數(shù)至少需要(N/2)+1個，這樣就可以解決分區(qū)容忍性問題。
下面我們舉個馬老師改英文名的例子來說明OB設(shè)計的精妙之處。假設(shè)數(shù)據(jù)庫按照用戶ID分庫分表，馬老師的用戶ID對應(yīng)的數(shù)據(jù)段在[0-9]，由A單元負(fù)責(zé)數(shù)據(jù)寫入，假如馬老師（用戶ID假設(shè)為000）正在用支付寶APP修改自己的英文名，馬老師一開始打錯了，打成了Jason Ma，馬老師看到修改的按鈕還可以點擊，立馬將名字改成了Jack Ma并重新提交。當(dāng)?shù)谝粋€請求來到A單元時，突然A單元網(wǎng)絡(luò)斷開了（分區(qū)產(chǎn)生了），系統(tǒng)執(zhí)行了預(yù)先配置的災(zāi)備策略自動將A單元對數(shù)據(jù)段[0,9]的寫入權(quán)限轉(zhuǎn)交給B單元（更改映射），這時候第二個請求便來到了B單元。由于在網(wǎng)絡(luò)斷開前請求已經(jīng)進入了A，寫權(quán)限轉(zhuǎn)交給單元B生效后，A和B同時對[0,9]數(shù)據(jù)段進行寫入馬老師的英文名。
假如這時候不做任何的分區(qū)容忍性保障即都允許寫入的話就會出現(xiàn)不一致，A單元說我看到馬老師設(shè)置了Jason Ma，B單元說我看到馬老師設(shè)置了Jack Ma。而在OB中這種情況永遠不會發(fā)生——當(dāng)A單元數(shù)據(jù)庫實例向整個系統(tǒng)提議說我建議把馬老師的英文名設(shè)置為Jason Ma時，發(fā)現(xiàn)沒人回應(yīng)它，由于出現(xiàn)了分區(qū)，其他節(jié)點對它來說都是不可達的，所以這個提議被自動丟棄，A心里也明白是自己分區(qū)了，會有主分區(qū)替自己完成寫入任務(wù)的。
同樣的，當(dāng)B單元數(shù)據(jù)庫實例提出將馬老師的英文名改成Jack Ma后，大部分節(jié)點都響應(yīng)了，所以B成功將Jack Ma寫入了馬老師的賬號記錄中。假如在寫權(quán)限轉(zhuǎn)交給單元B后A突然恢復(fù)了，也沒關(guān)系，兩筆寫請求同時要求獲得(N/2)+1個節(jié)點的事務(wù)鎖，通過no-wait設(shè)計，在B獲得了鎖之后，其他爭搶該鎖的事務(wù)都會因為失敗而回滾。
No-wait設(shè)計的思想在于當(dāng)發(fā)現(xiàn)所訪問的資源出現(xiàn)競爭時，不等待資源釋放，而是直接返回失敗。
下面我們分析下OB的CAP：
所以O(shè)B仍然沒有逃脫CAP魔咒，產(chǎn)生分區(qū)的時候它變成AP+最終一致性（C）。整體來說，它是AP的，即高可用和分區(qū)容忍。
個人感覺本文涉及到的知識面確實不少，每個點單獨展開都可以討論半天。回到我們緊扣的主旨來看，雙十一海量支付背后技術(shù)上大快人心的設(shè)計到底是啥？我想無非是以下幾點：
基于用戶分庫分表的RZone設(shè)計。每個用戶群獨占一個單元給整個系統(tǒng)的容量帶來了爆發(fā)式增長。
而這就是螞蟻LDC的CRG架構(gòu)，理論上TPS數(shù)字可以做到更高，但雙十一海量支付的成功不單單是這么一套設(shè)計所決定的，還有預(yù)熱削峰等運營+技術(shù)的手段，在此感謝阿里巴巴全體技術(shù)給大家?guī)淼囊荒暌欢鹊馁徫锸⒀纭?/span>
感謝大家的閱讀，文中可能存在不足或遺漏之處，歡迎批評指正。
本文為個人留檔使用，未經(jīng)允許，不得轉(zhuǎn)載。
[1] Practice of Cloud System Administration, The: DevOps and SRE Practices for Web Services, Volume 2. Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan.
[2] MySQL 5.7半同步復(fù)制技術(shù). https://www.cnblogs.com/zero-gg/p/9057092.html
[3] BASE理論分析; https://www.jianshu.com/p/f6157118e54b
[4] Keepalived; https://baike.baidu.com/item/Keepalived/10346758?fr=aladdin
[5] PAXOS; https://en.wikipedia.org/wiki/Paxos_(computer_science)
[6] OceanBase支撐2135億成交額背后的技術(shù)原理; https://www.cnblogs.com/antfin/articles/10299396.html
[7] 三地五中心,螞蟻金服金融行業(yè)安全最高標(biāo)準(zhǔn)技術(shù)開放,光纜挖斷業(yè)務(wù)照樣用; https://www.sohu.com/a/255067828_114921
[8] 阿里雙11技術(shù)詳解：容量規(guī)劃+LDC+彈性架構(gòu)+大促中控等; https://my.oschina.net/u/4383176/blog/4713897
[9] Backup; https://en.wikipedia.org/wiki/Backup
作者:湯波
出處:https://tbwork.org/2019/11/10/ant-ldc-arch/
知道從什么時候起，談及夢想成了一件可笑的事情。有人說夢想總是要有的，萬一實現(xiàn)了呢！有人說實現(xiàn)的那叫目標(biāo)，實現(xiàn)不了的才叫夢想。可能有太多的夢想沒有實現(xiàn)，于是我們再次談及夢想的時候覺得越來越可笑。曾幾何時我也是為了一篇文章能夠敲上幾個小時再修改無數(shù)遍的職場菜鳥，可隨著時間的推移，好像麻木了很多，忘卻了很多，直到他的故事，讓我重新審視自己。
故事的主人公老周，上學(xué)時候追求搖滾樂近乎癡狂，曾經(jīng)為了買一盒磁帶而吃了一周方便面，而這些瘋狂的事情，現(xiàn)在從他口中說出來不過是簡單的一句“年輕時喜歡搖滾樂，也玩過兩年吉他，也夢想過組建一支自己的樂隊”罷了。與一位執(zhí)著音樂的朋友相遇讓他重新拾起年輕時候的夢想——組辦一場搖滾音樂會。老周與幾個朋友親力親為，懷著最初的夢想去努力，當(dāng)四百多人擠爆現(xiàn)場，一起吶喊，當(dāng)全場唱起《海闊天空》讓這些已過而立之年的漢子濕了眼眶時，老周用DOBBY記錄下來了這個夢想照進現(xiàn)實的過程。
搖滾音樂會彩排照片，DOBBY拍攝
如果你以為故事到這里已經(jīng)是圓滿，我會說：這才剛剛開始而已。東北漢子老周與DOBBY，一起經(jīng)歷了很多樸實卻感人，平凡又卓越的故事。
老周用DOBBY在雪地上的自拍
去年于老周老來說是實現(xiàn)夢想的一年，除了用DOBBY記錄了那場激動人心的搖滾音樂會，還帶著全家在春節(jié)前回到了久別的故鄉(xiāng)。岳母的父親罹患癌癥，臨近年根兒，二老甚是想家，臘月二十七，老周帶著一家人踏上了返鄉(xiāng)的路途。春節(jié)里，一家人團聚在一起，堆雪人、吃年夜飯、外出游玩合影，一切都是那么熟悉又舒適。全程，老周都在認(rèn)真的用DOBBY記錄每一個溫馨時刻，從此全家福變得更加完整。回到那個屯兒，見到熟悉的人兒，雖然故土看著好似破敗，但是那里凝聚了老人們的童年記憶，一張DOBBY視角的留影，記錄下他們在老宅與鄉(xiāng)親們的合影，好似我們在一本書里，讀著他們的故事。
鶴崗，東北邊陲的一座小城，老周生在這里，長在這里，也深深地?zé)釔壑@座城市。作為DOBBY的第一批眾籌用戶，老周一直把DOBBY當(dāng)做生活中的紀(jì)錄者，一篇《寒冬暮色中的東北礦山》曾經(jīng)感動了很多社區(qū)朋友，老周包含深情的文字配上DOBBY的獨特視角，讓我們知道：那里曾在大躍進期間靠人工鎬刨鍬挖開采出露天礦，曾經(jīng)擁有全國最大產(chǎn)量的礦井，這樣一個三四線的小城市也曾經(jīng)為國家的建設(shè)貢獻了自己所有的力量……“為什么我的眼里飽含淚水,因為我對這片土地愛得深沉，因為這是我的家鄉(xiāng)，我經(jīng)歷過這里的輝煌和衰落，這里也見證了我的成長。”老周深情地訴說著。
重情又瀟灑的老周有著一撥兒經(jīng)歷過風(fēng)風(fēng)雨雨一路走來的朋友，八年前他因為《紅河谷》而迷戀上了西藏，老阿媽的慈祥，藏族漢子的驍勇淳樸，西藏文化的神秘，他們對信仰的虔誠，都打動著老周。八年里，老周經(jīng)歷了結(jié)婚，生子，父親病重去世，創(chuàng)業(yè)等等。半年前老周發(fā)現(xiàn)自己得了高血壓，然而這場西藏行卻還未開始，于是毅然決然收拾行囊與朋友出發(fā)了。這次行程，攝影設(shè)備老周只帶了DOBBY和ROLLCAP，與其他旅行者不同，DOBBY讓老周從上帝視角領(lǐng)略了西藏的神秘與魅力。
“一座高原，一個西藏，十萬邊疆，五百山水，三千佛唱。”西藏獨有的美讓老周陶醉，同時也伴隨著嚴(yán)重的高原反應(yīng)：頭疼，心慌，呼吸困難，每一次飛起DOBBY，老周都要小心翼翼克服身體的不適。
DOBBY的限高海拔其實只有3000米，幾個月前有個飛友曾經(jīng)在五千多米海拔處成功的飛起DOBBY拍照，創(chuàng)下記錄，這一次，老周不但在這里成功的飛起了DOBBY，更是一次又一次的用DOBBY記錄了他們的旅行。鶯飛草長，青天在上，白云涌動，雪山綿長，牧民喇嘛，身邊的摯友，老周用他的DOBBY，創(chuàng)造了一個全新的奇跡。
視頻https://v.qq.com/x/page/v0388xk75qf.html
DOBBY & ROLLCAP 拍攝
幾天前與老周溝通的時候，他正在陪老婆逛街，他說：“自己的夢想實現(xiàn)了，現(xiàn)在要好好兒陪陪老婆，實現(xiàn)老婆的夢想。”回到的平凡世界的老周依舊是柴米油鹽，家長里短，兢兢業(yè)業(yè)的工作。
我們曾走過無數(shù)地方和無盡歲月，每個夢想都通往不同世界，老周的故事，會一直繼續(xù)，而你的故事，現(xiàn)在正是起點。
Canvas中，線的默認(rèn)顏色為黑色，寬度為lpx，但我們可以使用相關(guān)屬性為線添加不同的樣式。下面我們將從寬度、描邊顏色、端點形狀3方面詳細(xì)講解線條樣式的設(shè)置方法。
1.設(shè)置線條寬度
使用lineWidth屬性可以定義線的寬度，該屬性的取值為數(shù)值(不帶單位)，以像素為計量。設(shè)置線的寬度的示例代碼如下：
context.lineNidth='10';上述代碼中設(shè)置了線的寬度為10。
2.設(shè)置描邊顏色
使用strokeStyle屬性可以定義線的描邊顏色，該屬性的取值為十六進制顏色值或顏色的英文名。設(shè)置描邊顏色的示例代碼如下：
context.strokeStyle='4f00';
context.strokeStyle='red';在上述代碼中，兩種方式都可以用于設(shè)置線的描邊顏色為紅色。
3.設(shè)置端點形狀
默認(rèn)情況下，線的端點是方形的，通過lineCap屬性可以改變端點的形狀，示例代碼如下：
context.1ineCap=，屬性值'；lineCap屬性的取值有3個，具體如表所示。
lineCap屬性的取值
了解了設(shè)置線的樣式的基本方法后，下面演示如何為線設(shè)置樣式。
(1)創(chuàng)建C:icodekchapter02\demol3.html，創(chuàng)建畫布并為線設(shè)置寬度、顏色和端點形狀，具體代碼如下：
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Document</title>
</head>
<body>
<canvas id="cas" width="300" height="300">
您的測覽器不支持Canvas標(biāo)簽
</canvas>
<script>
var context=document.getElementById('cas').getContext('2d');
context.moveTo(10,10); // 定義初始位置
context.1ineTo(300,10); // 定義連線端點
context.lineWidth='10'; // 設(shè)置線的寬度
context.strokeStyle='red'; // 設(shè)置線的顏色
context.lineCap='round'; // 設(shè)置線的端點形狀
context.stroke(); // 定叉描邊
</script>
</body>
</html>上述代碼中，第15行代碼設(shè)置了線的寬度為10像素：第16行代碼設(shè)置了線的顏色為紅色;第17行代碼設(shè)置了線的端點為圓形。
(2)保存代碼，在瀏覽器中測試，頁面效果如圖所示。
設(shè)置線的寬度、顏色和端點形狀
頁面顯示一條紅色的線，說明我們已經(jīng)成功為線設(shè)置了樣式。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
