一、分布式架構(gòu)詳解
1、分布式發(fā)展歷程
1.1 單點(diǎn)集中式
特點(diǎn)：App、DB、FileServer都部署在一臺(tái)機(jī)器上。并且訪問請(qǐng)求量較少
1.2 應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)拆分
特點(diǎn)：App、DB、FileServer分別部署在獨(dú)立服務(wù)器上。并且訪問請(qǐng)求量較少
1.3 使用緩存改善性能
特點(diǎn)：數(shù)據(jù)庫(kù)中頻繁訪問的數(shù)據(jù)存儲(chǔ)在緩存服務(wù)器中，減少數(shù)據(jù)庫(kù)的訪問次數(shù)，降低數(shù)據(jù)庫(kù)的壓力
1.4 應(yīng)用服務(wù)器集群
特點(diǎn)：多臺(tái)應(yīng)用服務(wù)器通過負(fù)載均衡同時(shí)對(duì)外提供服務(wù)，解決單臺(tái)服務(wù)器處理能力上限的問題
1.5 數(shù)據(jù)庫(kù)讀寫分離
特點(diǎn)：數(shù)據(jù)庫(kù)進(jìn)行讀寫分離(主從)設(shè)計(jì)，解決數(shù)據(jù)庫(kù)的處理壓力
1.6 反向代理和CDN加速
特點(diǎn)：采用反向代理和CDN加快系統(tǒng)的訪問速度
1.7 分布式文件系統(tǒng)和分布式數(shù)據(jù)庫(kù)
特點(diǎn)：數(shù)據(jù)庫(kù)采用分布式數(shù)據(jù)庫(kù)，文件系統(tǒng)采用分布式文件系統(tǒng)
隨著業(yè)務(wù)的發(fā)展，最終數(shù)據(jù)庫(kù)讀寫分離也將無法滿足需求，需要采用分布式數(shù)據(jù)庫(kù)和分布式文件系統(tǒng)來支撐
分布式數(shù)據(jù)庫(kù)是數(shù)據(jù)庫(kù)拆分后的最后方法，只有在單表規(guī)模非常龐大的時(shí)候才使用，更常用的數(shù)據(jù)庫(kù)拆分手段是業(yè)務(wù)分庫(kù)，將不同業(yè)務(wù)的數(shù)據(jù)庫(kù)部署在不同的機(jī)器上
二、 分布式技術(shù)詳解
1. 并發(fā)性
2. 分布性
大任務(wù)拆分成多個(gè)任務(wù)部署到多臺(tái)機(jī)器上對(duì)外提供服務(wù)
3. 缺乏全局時(shí)鐘
時(shí)間要統(tǒng)一
4. 對(duì)等性
一個(gè)服務(wù)部署在多臺(tái)機(jī)器上是一樣的，無任何差別
5. 故障肯定會(huì)發(fā)生
硬盤壞了 CPU燒了....
三、分布式事務(wù)
1. ACID
原子性(Atomicity)：一個(gè)事務(wù)(transaction)中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯(cuò)誤，會(huì)被恢復(fù)(Rollback)到事務(wù)開始前的狀態(tài)，就像這個(gè)事務(wù)從來沒有執(zhí)行過一樣。
一致性(Consistency)：在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫(kù)的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預(yù)設(shè)規(guī)則，這包含資料的精確度、串聯(lián)性以及后續(xù)數(shù)據(jù)庫(kù)可以自發(fā)性地完成預(yù)定的工作。
比如A有500元，B有300元，A向B轉(zhuǎn)賬100，無論怎么樣，A和B的總和總是800元
隔離性(Isolation)：數(shù)據(jù)庫(kù)允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)其數(shù)據(jù)進(jìn)行讀寫和修改的能力，隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級(jí)別，包括讀未提交(Read uncommitted)、讀提交(read committed)、可重復(fù)讀(repeatable read)和串行化(Serializable)。
持久性(Durability)：事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。
2. 2P/3P
2P= Two Phase commit 二段提交(RDBMS(關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng))經(jīng)常就是這種機(jī)制，保證強(qiáng)一致性)
3P= Three Phase commit 三段提交
說明：2P/3P是為了保證事務(wù)的ACID(原子性、一致性、隔離性、持久性)
2.1 2P的兩個(gè)階段
階段1：提交事務(wù)請(qǐng)求(投票階段)詢問是否可以提交事務(wù)
階段2：執(zhí)行事務(wù)提交(commit、rollback) 真正的提交事務(wù)
2.2 3P的三個(gè)階段
階段1：是否提交-詢問是否可以做事務(wù)提交
階段2：預(yù)先提交-預(yù)先提交事務(wù)
階段3：執(zhí)行事務(wù)提交(commit、rollback)真正的提交事務(wù)
說明：3P把2P的階段一拆分成了前面兩個(gè)階段
3. CAP理論
一致性(Consistency)：分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)保持一致
可用性(Availability)：任何一個(gè)節(jié)點(diǎn)掛了，其他節(jié)點(diǎn)可以繼續(xù)對(duì)外提供服務(wù)
分區(qū)容錯(cuò)性(網(wǎng)絡(luò)分區(qū))Partition tolerance：一個(gè)數(shù)據(jù)庫(kù)所在的機(jī)器壞了，如硬盤壞了，數(shù)據(jù)丟失了，可以新增一臺(tái)機(jī)器，然后從其他正常的機(jī)器把備份的數(shù)據(jù)同步過來
CAP理論的特點(diǎn)：CAP只能滿足其中2條
CA(放棄P)：將所有的數(shù)據(jù)放在一個(gè)節(jié)點(diǎn)。滿足一致性、可用性。
AP(放棄C)：放棄強(qiáng)一致性，用最終一致性來保證。
CP(放棄A)：一旦系統(tǒng)遇見故障，受到影響的服務(wù)器需要等待一段時(shí)間，在恢復(fù)期間無法對(duì)外提供服務(wù)。
舉例說明CAP理論：
有3臺(tái)機(jī)器分別有3個(gè)數(shù)據(jù)庫(kù)分別有兩張表,數(shù)據(jù)都是一樣的
Machine1-db1-tbl_person、tbl_order
Machine2-db2-tbl_person、tbl_order
Machine3-db3-tbl_person、tbl_order
1)當(dāng)向machine1的db1的表tbl_person、tbl_order插入數(shù)數(shù)據(jù)時(shí)，同時(shí)要把插入的數(shù)據(jù)同步到machine2、machine3，這就是一致性
2)當(dāng)其中的一臺(tái)機(jī)器宕機(jī)了，可以繼續(xù)對(duì)外提供服務(wù)，把宕機(jī)的機(jī)器重新啟動(dòng)起來可以繼續(xù)服務(wù)，這就是可用性
3)當(dāng)machine1的機(jī)器壞了，數(shù)據(jù)全部丟失了，不會(huì)有任何問題，因?yàn)閙achine2和machine3上還有數(shù)據(jù)，重新加一臺(tái)機(jī)器machine4，把machine2和machine3其中一臺(tái)機(jī)器的備份數(shù)據(jù)同步過來就可以了，這就是分區(qū)容錯(cuò)性
4. BASE理論
基本可用(bascially available)、軟狀態(tài)(soft state)、最終一致性(Eventually consistent)
基本可用：在分布式系統(tǒng)出現(xiàn)故障，允許損失部分可用性(服務(wù)降級(jí)、頁面降級(jí))
軟狀態(tài)：允許分布式系統(tǒng)出現(xiàn)中間狀態(tài)。而且中間狀態(tài)不影響系統(tǒng)的可用性。
1、這里的中間狀態(tài)是指不同的data replication之間的數(shù)據(jù)更新可以出現(xiàn)延時(shí)的最終一致性
2、如CAP理論里面的示例，當(dāng)向machine1的db1的表tbl_person、tbl_order插入數(shù)數(shù)據(jù)時(shí)，同時(shí)要把插入的數(shù)據(jù)同步到machine2、machine3，當(dāng)machine3的網(wǎng)絡(luò)有問題時(shí)，同步失敗，但是過一會(huì)網(wǎng)絡(luò)恢復(fù)了就同步成功了，這個(gè)同步失敗的狀態(tài)就稱為軟狀態(tài)，因?yàn)樽罱K還是同步成功了。
最終一致性：data replications經(jīng)過一段時(shí)間達(dá)到一致性。
5. Paxos算法
5.1 介紹Paxos算法之前我們先來看一個(gè)小故事
拜占庭將軍問題
拜占庭帝國(guó)就是5~15世紀(jì)的東羅馬帝國(guó)，拜占庭即現(xiàn)在土耳其的伊斯坦布爾。我們可以想象，拜占庭軍隊(duì)有許多分支，駐扎在敵人城外，每一分支由各自的將軍指揮。假設(shè)有11位將軍，將軍們只能靠通訊員進(jìn)行通訊。在觀察敵人以后，忠誠(chéng)的將軍們必須制訂一個(gè)統(tǒng)一的行動(dòng)計(jì)劃——進(jìn)攻或者撤退。然而，這些將軍里有叛徒，他們不希望忠誠(chéng)的將軍們能達(dá)成一致，因而影響統(tǒng)一行動(dòng)計(jì)劃的制訂與傳播。
問題是：將軍們必須有一個(gè)協(xié)議，使所有忠誠(chéng)的將軍們能夠達(dá)成一致，而且少數(shù)幾個(gè)叛徒不能使忠誠(chéng)的將軍們作出錯(cuò)誤的計(jì)劃——使有些將軍進(jìn)攻而另一些將軍撤退。
假設(shè)有9位忠誠(chéng)的將軍，5位判斷進(jìn)攻，4位判斷撤退，還有2個(gè)間諜惡意判斷撤退，雖然結(jié)果是錯(cuò)誤的撤退，但這種情況完全是允許的。因?yàn)檫@11位將軍依然保持著狀態(tài)一致性。
總結(jié)：
1)11位將軍進(jìn)攻城池
2)同時(shí)進(jìn)攻(議案、決議)、同時(shí)撤退(議案、決議)
3)不管撤退還是進(jìn)攻，必須半數(shù)的將軍統(tǒng)一意見才可以執(zhí)行
4)將軍里面有叛徒，會(huì)干擾決議生成
5.2 下面就來介紹一下Paxos算法
Google Chubby的作者M(jìn)ike Burrows說過這個(gè)世界上只有一種一致性算法，那就是Paxos，其它的算法都是殘次品。
Paxos：多數(shù)派決議(最終解決一致性問題)
Paxos算法有三種角色：Proposer，Acceptor，Learner
Proposer：提交者(議案提交者)
提交議案(判斷是否過半)，提交批準(zhǔn)議案(判斷是否過半)
Acceptor：接收者(議案接收者)
接受議案或者駁回議案，給proposer回應(yīng)(promise)
Learner：學(xué)習(xí)者(打醬油的)
如果議案產(chǎn)生，學(xué)習(xí)議案。
設(shè)定1：如果Acceptor沒有接受議案，那么他必須接受第一個(gè)議案
設(shè)定2：每個(gè)議案必須有一個(gè)編號(hào)，并且編號(hào)只能增長(zhǎng)，不能重復(fù)。越往后越大。
設(shè)定3：接受編號(hào)大的議案，如果小于之前接受議案編號(hào)，那么不接受
設(shè)定4：議案有2種(提交的議案，批準(zhǔn)的議案)
1)Prepare階段(議案提交)
a)Proposer希望議案V。首先發(fā)出Prepare請(qǐng)求至大多數(shù)Acceptor。Prepare請(qǐng)求內(nèi)容為序列號(hào)K
b)Acceptor收到Prepare請(qǐng)求為編號(hào)K后，檢查自己手里是否有處理過Prepare請(qǐng)求。
c)如果Acceptor沒有接受過任何Prepare請(qǐng)求，那么用OK來回復(fù)Proposer，代表Acceptor必須接受收到的第一個(gè)議案(設(shè)定1)
d)否則，如果Acceptor之前接受過任何Prepare請(qǐng)求(如：MaxN)，那么比較議案編號(hào)，如果K
e)如果K>=MaxN，那么檢查之前是否有批準(zhǔn)的議案，如果沒有則用OK來回復(fù)Proposer，并記錄K
f)如果K>=MaxN，那么檢查之前是否有批準(zhǔn)的議案，如果有則回復(fù)批準(zhǔn)的議案編號(hào)和議案內(nèi)容(如：
2)Accept階段(批準(zhǔn)階段)
a)Proposer收到過半Acceptor發(fā)來的回復(fù)，回復(fù)都是OK，且沒有附帶任何批準(zhǔn)過的議案編號(hào)和議案內(nèi)容。那么Proposer繼續(xù)提交批準(zhǔn)請(qǐng)求，不過此時(shí)會(huì)連議案編號(hào)K和議案內(nèi)容V一起提交(
b)Proposer收到過半Acceptor發(fā)來的回復(fù)，回復(fù)都是OK，且附帶批準(zhǔn)過的議案編號(hào)和議案內(nèi)容(
c)Proposer沒有收到過半Acceptor發(fā)來的回復(fù)，則修改議案編號(hào)K為K+1，并將編號(hào)重新發(fā)送給Acceptors(重復(fù)Prepare階段的過程)
d)Acceptor收到Proposer發(fā)來的Accept請(qǐng)求，如果編號(hào)K
e)Acceptor收到Proposer發(fā)來的Accept請(qǐng)求，如果編號(hào)K>=MaxN則批準(zhǔn)該議案，并設(shè)置手里批準(zhǔn)的議案為
f)經(jīng)過一段時(shí)間Proposer對(duì)比手里收到的Accept回復(fù)，如果超過半數(shù)，則結(jié)束流程(代表議案被批準(zhǔn))，同時(shí)通知Leaner可以學(xué)習(xí)議案。
g) 經(jīng)過一段時(shí)間Proposer對(duì)比手里收到的Accept回復(fù)，如果未超過半數(shù)，則修改議案編號(hào)重新進(jìn)入Prepare階段。
5.3 Paxos示例
示例1：先后提議的場(chǎng)景
角色：
proposer：參謀1，參謀2
acceptor：將軍1，將軍2，將軍3(決策者)
1)參謀1發(fā)起提議，派通信兵帶信給3個(gè)將軍，內(nèi)容為(編號(hào)1);
2)3個(gè)將軍收到參謀1的提議，由于之前還沒有保存任何編號(hào)，因此把(編號(hào)1)保存下來，避免遺忘;同時(shí)讓通信兵帶信回去，內(nèi)容為(ok);
3)參謀1收到至少2個(gè)將軍的回復(fù)，再次派通信兵帶信給3個(gè)將軍，內(nèi)容為(編號(hào)1，進(jìn)攻時(shí)間1);
4)3個(gè)將軍收到參謀1的時(shí)間，把(編號(hào)1，進(jìn)攻時(shí)間1)保存下來，避免遺忘;同時(shí)讓通信兵帶信回去，內(nèi)容為(Accepted);
5)參謀1收到至少2個(gè)將軍的(Accepted)內(nèi)容，確認(rèn)進(jìn)攻時(shí)間已經(jīng)被大家接收;
6)參謀2發(fā)起提議，派通信兵帶信給3個(gè)將軍，內(nèi)容為(編號(hào)2);
7)3個(gè)將軍收到參謀2的提議，由于(編號(hào)2)比(編號(hào)1)大，因此把(編號(hào)2)保存下來，避免遺忘;又由于之前已經(jīng)接受參謀1的提議，因此讓通信兵帶信回去，內(nèi)容為(編號(hào)1，進(jìn)攻時(shí)間1);
8)參謀2收到至少2個(gè)將軍的回復(fù)，由于回復(fù)中帶來了已接受的參謀1的提議內(nèi)容，參謀2因此不再提出新的進(jìn)攻時(shí)間，接受參謀1提出的時(shí)間;
示例2：交叉場(chǎng)景
角色：
proposer：參謀1，參謀2
acceptor：將軍1，將軍2，將軍3(決策者)
1)參謀1發(fā)起提議，派通信兵帶信給3個(gè)將軍，內(nèi)容為(編號(hào)1);
2)3個(gè)將軍的情況如下
a)將軍1和將軍2收到參謀1的提議，將軍1和將軍2把(編號(hào)1)記錄下來，如果有其他參謀提出更小的編號(hào)，將被拒絕;同時(shí)讓通信兵帶信回去，內(nèi)容為(ok);
b)負(fù)責(zé)通知將軍3的通信兵被抓，因此將軍3沒收到參謀1的提議;
3)參謀2在同一時(shí)間也發(fā)起了提議，派通信兵帶信給3個(gè)將軍，內(nèi)容為(編號(hào)2);
4)3個(gè)將軍的情況如下
a)將軍2和將軍3收到參謀2的提議，將軍2和將軍3把(編號(hào)2)記錄下來，如果有其他參謀提出更小的編號(hào)，將被拒絕;同時(shí)讓通信兵帶信回去，內(nèi)容為(ok);
b)負(fù)責(zé)通知將軍1的通信兵被抓，因此將軍1沒收到參謀2的提議;
5)參謀1收到至少2個(gè)將軍的回復(fù)，再次派通信兵帶信給有答復(fù)的2個(gè)將軍，內(nèi)容為(編號(hào)1，進(jìn)攻時(shí)間1);
6)2個(gè)將軍的情況如下
a)將軍1收到了(編號(hào)1，進(jìn)攻時(shí)間1)，和自己保存的編號(hào)相同，因此把(編號(hào)1，進(jìn)攻時(shí)間1)保存下來;同時(shí)讓通信兵帶信回去，內(nèi)容為(Accepted);
b)將軍2收到了(編號(hào)1，進(jìn)攻時(shí)間1)，由于(編號(hào)1)小于已經(jīng)保存的(編號(hào)2)，因此讓通信兵帶信回去，內(nèi)容為(Rejected，編號(hào)2);
7)參謀2收到至少2個(gè)將軍的回復(fù)，再次派通信兵帶信給有答復(fù)的2個(gè)將軍，內(nèi)容為(編號(hào)2，進(jìn)攻時(shí)間2);
8)將軍2和將軍3收到了(編號(hào)2，進(jìn)攻時(shí)間2)，和自己保存的編號(hào)相同，因此把(編號(hào)2，進(jìn)攻時(shí)間2)保存下來，同時(shí)讓通信兵帶信回去，內(nèi)容為(Accepted);
9)參謀2收到至少2個(gè)將軍的(Accepted)內(nèi)容，確認(rèn)進(jìn)攻時(shí)間已經(jīng)被多數(shù)派接受;
10)參謀1只收到了1個(gè)將軍的(Accepted)內(nèi)容，同時(shí)收到一個(gè)(Rejected，編號(hào)2);參謀1重新發(fā)起提議，派通信兵帶信給3個(gè)將軍，內(nèi)容為(編號(hào)3);
11)3個(gè)將軍的情況如下
a)將軍1收到參謀1的提議，由于(編號(hào)3)大于之前保存的(編號(hào)1)，因此把(編號(hào)3)保存下來;由于將軍1已經(jīng)接受參謀1前一次的提議，因此讓通信兵帶信回去，內(nèi)容為(編號(hào)1，進(jìn)攻時(shí)間1);
b)將軍2收到參謀1的提議，由于(編號(hào)3)大于之前保存的(編號(hào)2)，因此把(編號(hào)3)保存下來;由于將軍2已經(jīng)接受參謀2的提議，因此讓通信兵帶信回去，內(nèi)容為(編號(hào)2，進(jìn)攻時(shí)間2);
c)負(fù)責(zé)通知將軍3的通信兵被抓，因此將軍3沒收到參謀1的提議;
12)參謀1收到了至少2個(gè)將軍的回復(fù)，比較兩個(gè)回復(fù)的編號(hào)大小，選擇大編號(hào)對(duì)應(yīng)的進(jìn)攻時(shí)間作為最新的提議;參謀1再次派通信兵帶信給有答復(fù)的2個(gè)將軍，內(nèi)容為(編號(hào)3，進(jìn)攻時(shí)間2);
13)將軍1和將軍2收到了(編號(hào)3，進(jìn)攻時(shí)間2)，和自己保存的編號(hào)相同，因此保存(編號(hào)3，進(jìn)攻時(shí)間2)，同時(shí)讓通信兵帶信回去，內(nèi)容為(Accepted);
14)參謀1收到了至少2個(gè)將軍的(accepted)內(nèi)容，確認(rèn)進(jìn)攻時(shí)間已經(jīng)被多數(shù)派接受。
四. Zookeeper ZAB協(xié)議
Zookeeper Automic Broadcast(ZAB)，即Zookeeper原子性廣播，是Paxos經(jīng)典實(shí)現(xiàn)
術(shù)語：
quorum：集群過半數(shù)的集合
1. ZAB(zookeeper)中節(jié)點(diǎn)分四種狀態(tài)
looking：選舉Leader的狀態(tài)(崩潰恢復(fù)狀態(tài)下)
following：跟隨者(follower)的狀態(tài)，服從Leader命令
leading：當(dāng)前節(jié)點(diǎn)是Leader，負(fù)責(zé)協(xié)調(diào)工作。
observing：observer(觀察者)，不參與選舉，只讀節(jié)點(diǎn)。
2. ZAB中的兩個(gè)模式(ZK是如何進(jìn)行選舉的)
崩潰恢復(fù)、消息廣播
1)崩潰恢復(fù)
leader掛了，需要選舉新的leader
a.每個(gè)server都有一張選票，如(3,9)，選票投自己。
b.每個(gè)server投完自己后，再分別投給其他還可用的服務(wù)器。如把Server3的(3,9)分別投給Server4和Server5，一次類推
c.比較投票，比較邏輯：優(yōu)先比較Zxid，Zxid相同時(shí)才比較myid。比較Zxid時(shí)，大的做leader;比較myid時(shí)，小的做leader
d.改變服務(wù)器狀態(tài)(崩潰恢復(fù)->數(shù)據(jù)同步，或者崩潰恢復(fù)->消息廣播)
相關(guān)概念補(bǔ)充說明：
epoch周期值
acceptedEpoch(比喻：年號(hào))：follower已經(jīng)接受leader更改年號(hào)的(newepoch)提議。
currentEpoch(比喻：當(dāng)前的年號(hào))：當(dāng)前的年號(hào)
lastZxid：history中最近接收到的提議zxid(最大的值)
history：當(dāng)前節(jié)點(diǎn)接受到事務(wù)提議的log
Zxid數(shù)據(jù)結(jié)構(gòu)說明：
cZxid = 0x10000001b
64位的數(shù)據(jù)結(jié)構(gòu)
高32位：10000
Leader的周期編號(hào)+myid的組合
低32位：001b
事務(wù)的自增序列(單調(diào)遞增的序列)只要客戶端有請(qǐng)求，就+1
當(dāng)產(chǎn)生新Leader的時(shí)候，就從這個(gè)Leader服務(wù)器上取出本地log中最大事務(wù)Zxid，從里面讀出epoch+1，作為一個(gè)新epoch，并將低32位置0(保證id絕對(duì)自增)
2)消息廣播(類似2P提交)
a.Leader接受請(qǐng)求后，將這個(gè)請(qǐng)求賦予全局的唯一64位自增Id(zxid)。
b.將zxid作為議案發(fā)給所有follower。
c.所有的follower接受到議案后，想將議案寫入硬盤后，馬上回復(fù)Leader一個(gè)ACK(OK)。
d.當(dāng)Leader接受到合法數(shù)量(過半)Acks，Leader給所有follower發(fā)送commit命令。
e.follower執(zhí)行commit命令。
注意：到了這個(gè)階段，ZK集群才正式對(duì)外提供服務(wù)，并且Leader可以進(jìn)行消息廣播，如果有新節(jié)點(diǎn)加入，還需要進(jìn)行同步。
3)數(shù)據(jù)同步
a.取出Leader最大lastZxid(從本地log日志來)
b.找到對(duì)應(yīng)zxid的數(shù)據(jù)，進(jìn)行同步(數(shù)據(jù)同步過程保證所有follower一致)
c.只有滿足quorum同步完成，準(zhǔn)Leader才能成為真正的Leader
【責(zé)任編輯：武曉燕 TEL：（010）68476606】