第1章 引言

隨著互聯(lián)網(wǎng)應(yīng)用的廣泛普及，海量數(shù)據(jù)的存儲(chǔ)和訪問(wèn)成為了系統(tǒng)設(shè)計(jì)的瓶頸問(wèn)題。對(duì)于一個(gè)大型的互聯(lián)網(wǎng)應(yīng)用，每天幾十億的PV無(wú)疑對(duì)數(shù)據(jù)庫(kù)造成了相當(dāng)高的負(fù)載。對(duì)于系統(tǒng)的穩(wěn)定性和擴(kuò)展性造成了極大的問(wèn)題。通過(guò)數(shù)據(jù)切分來(lái)提高網(wǎng)站性能，橫向擴(kuò)展數(shù)據(jù)層已經(jīng)成為架構(gòu)研發(fā)人員首選的方式。

• 水平切分?jǐn)?shù)據(jù)庫(kù)：可以降低單臺(tái)機(jī)器的負(fù)載，同時(shí)最大限度的降低了宕機(jī)造成的損失；
• 負(fù)載均衡策略：可以降低單臺(tái)機(jī)器的訪問(wèn)負(fù)載，降低宕機(jī)的可能性；
• 集群方案：解決了數(shù)據(jù)庫(kù)宕機(jī)帶來(lái)的單點(diǎn)數(shù)據(jù)庫(kù)不能訪問(wèn)的問(wèn)題；
• 讀寫(xiě)分離策略：最大限度了提高了應(yīng)用中讀取數(shù)據(jù)的速度和并發(fā)量；

第2章 基本原理和概念

什么是數(shù)據(jù)切分

"Shard" 這個(gè)詞英文的意思是"碎片"，而作為數(shù)據(jù)庫(kù)相關(guān)的技術(shù)用語(yǔ)，似乎最早見(jiàn)于大型多人在線角色扮演游戲中。"Sharding" 姑且稱之為"分片"。Sharding 不是一個(gè)某個(gè)特定數(shù)據(jù)庫(kù)軟件附屬的功能，而是在具體技術(shù)細(xì)節(jié)之上的抽象處理，是水平擴(kuò)展(Scale Out，亦或橫向擴(kuò)展、向外擴(kuò)展)的解決方案，其主要目的是為突破單節(jié)點(diǎn)數(shù)據(jù)庫(kù)服務(wù)器的 I/O 能力限制，解決數(shù)據(jù)庫(kù)擴(kuò)展性問(wèn)題。通過(guò)一系列的切分規(guī)則將數(shù)據(jù)水平分布到不同的DB或table中，在通過(guò)相應(yīng)的DB路由或者table路由規(guī)則找到需要查詢的具體的DB或者table，以進(jìn)行Query操作。“sharding”通常是指“水平切分”，這也是本文討論的重點(diǎn)。接下來(lái)舉個(gè)簡(jiǎn)單的例子：我們針對(duì)一個(gè)Blog應(yīng)用中的日志來(lái)說(shuō)明，比如日志文章（article）表有如下字段：

面對(duì)這樣的一個(gè)表，我們?cè)鯓忧蟹帜?#xff1f;怎樣將這樣的數(shù)據(jù)分布到不同的數(shù)據(jù)庫(kù)中的表中去呢？我們可以這樣做，將user_id為1～10000的所有的文章信息放入DB1中的article表中，將user_id為10001～20000的所有文章信息放入DB2中的 article表中，以此類推，一直到DBn。這樣一來(lái)，文章數(shù)據(jù)就很自然的被分到了各個(gè)數(shù)據(jù)庫(kù)中，達(dá)到了數(shù)據(jù)切分的目的。

接下來(lái)要解決的問(wèn)題就是怎樣找到具體的數(shù)據(jù)庫(kù)呢？其實(shí)問(wèn)題也是簡(jiǎn)單明顯的，既然分庫(kù)的時(shí)候我們用到了區(qū)分字段user_id，那么很自然，數(shù)據(jù)庫(kù)路由的過(guò)程當(dāng)然還是少不了user_id的。就是我們知道了這個(gè)blog的user_id，就利用這個(gè)user_id，利用分庫(kù)時(shí)候的規(guī)則，反過(guò)來(lái)定位具體的數(shù)據(jù)庫(kù)。比如user_id是234，利用剛才的規(guī)則，就應(yīng)該定位到DB1，假如user_id是12343，利用該才的規(guī)則，就應(yīng)該定位到DB2。以此類推，利用分庫(kù)的規(guī)則，反向的路由到具體的DB，這個(gè)過(guò)程我們稱之為“DB路由”。

平常我們會(huì)自覺(jué)的按照范式來(lái)設(shè)計(jì)我們的數(shù)據(jù)庫(kù)，考慮到數(shù)據(jù)切分的DB設(shè)計(jì)，將違背這個(gè)通常的規(guī)矩和約束。為了切分，我們不得不在數(shù)據(jù)庫(kù)的表中出現(xiàn)冗余字段，用作區(qū)分字段或者叫做分庫(kù)的標(biāo)記字段。比如上面的article的例子中的user_id這樣的字段（當(dāng)然，剛才的例子并沒(méi)有很好的體現(xiàn)出user_id的冗余性，因?yàn)閡ser_id這個(gè)字段即使就是不分庫(kù)，也是要出現(xiàn)的，算是我們撿了便宜吧）。當(dāng)然冗余字段的出現(xiàn)并不只是在分庫(kù)的場(chǎng)景下才出現(xiàn)的，在很多大型應(yīng)用中，冗余也是必須的，這個(gè)涉及到高效DB的設(shè)計(jì)，本文不再贅述。

為什么要數(shù)據(jù)切分

上面對(duì)什么是數(shù)據(jù)切分做了個(gè)概要的描述和解釋，讀者可能會(huì)疑問(wèn)，為什么需要數(shù)據(jù)切分呢？像 Oracle這樣成熟穩(wěn)定的數(shù)據(jù)庫(kù)，足以支撐海量數(shù)據(jù)的存儲(chǔ)與查詢了？為什么還需要數(shù)據(jù)切片呢？

的確，Oracle的DB確實(shí)很成熟很穩(wěn)定，但是高昂的使用費(fèi)用和高端的硬件支撐不是每一個(gè)公司能支付的起的。試想一下一年幾千萬(wàn)的使用費(fèi)用和動(dòng)輒上千萬(wàn)元的小型機(jī)作為硬件支撐，這是一般公司能支付的起的嗎？即使就是能支付的起，假如有更好的方案，有更廉價(jià)且水平擴(kuò)展性能更好的方案，我們?yōu)槭裁床贿x擇呢？

我們知道每臺(tái)機(jī)器無(wú)論配置多么好它都有自身的物理上限，所以當(dāng)我們應(yīng)用已經(jīng)能觸及或遠(yuǎn)遠(yuǎn)超出單臺(tái)機(jī)器的某個(gè)上限的時(shí)候，我們惟有尋找別的機(jī)器的幫助或者繼續(xù)升級(jí)的我們的硬件，但常見(jiàn)的方案還是橫向擴(kuò)展，通過(guò)添加更多的機(jī)器來(lái)共同承擔(dān)壓力。我們還得考慮當(dāng)我們的業(yè)務(wù)邏輯不斷增長(zhǎng)，我們的機(jī)器能不能通過(guò)線性增長(zhǎng)就能滿足需求？Sharding可以輕松的將計(jì)算，存儲(chǔ)，I/O并行分發(fā)到多臺(tái)機(jī)器上，這樣可以充分利用多臺(tái)機(jī)器各種處理能力，同時(shí)可以避免單點(diǎn)失敗，提供系統(tǒng)的可用性，進(jìn)行很好的錯(cuò)誤隔離。

綜合以上因素，數(shù)據(jù)切分是很有必要的。 我們用免費(fèi)的MySQL和廉價(jià)的Server甚至是PC做集群，達(dá)到小型機(jī)+大型商業(yè)DB的效果，減少大量的資金投入，降低運(yùn)營(yíng)成本，何樂(lè)而不為呢？所以，我們選擇Sharding，擁抱Sharding。

怎么做到數(shù)據(jù)切分

數(shù)據(jù)切分可以是物理上的，對(duì)數(shù)據(jù)通過(guò)一系列的切分規(guī)則將數(shù)據(jù)分布到不同的DB服務(wù)器上，通過(guò)路由規(guī)則路由訪問(wèn)特定的數(shù)據(jù)庫(kù)，這樣一來(lái)每次訪問(wèn)面對(duì)的就不是單臺(tái)服務(wù)器了，而是N臺(tái)服務(wù)器，這樣就可以降低單臺(tái)機(jī)器的負(fù)載壓力。

數(shù)據(jù)切分也可以是數(shù)據(jù)庫(kù)內(nèi)的，對(duì)數(shù)據(jù)通過(guò)一系列的切分規(guī)則，將數(shù)據(jù)分布到一個(gè)數(shù)據(jù)庫(kù)的不同表中，比如將article分為article_001，article_002等子表，若干個(gè)子表水平拼合有組成了邏輯上一個(gè)完整的article表，這樣做的目的其實(shí)也是很簡(jiǎn)單的。舉個(gè)例子說(shuō)明，比如article表中現(xiàn)在有5000w條數(shù)據(jù)，此時(shí)我們需要在這個(gè)表中增加（insert）一條新的數(shù)據(jù)，insert完畢后，數(shù)據(jù)庫(kù)會(huì)針對(duì)這張表重新建立索引，5000w行數(shù)據(jù)建立索引的系統(tǒng)開(kāi)銷還是不容忽視的。但是反過(guò)來(lái)，假如我們將這個(gè)表分成100 個(gè)table呢，從article_001一直到article_100，5000w行數(shù)據(jù)平均下來(lái)，每個(gè)子表里邊就只有50萬(wàn)行數(shù)據(jù)，這時(shí)候我們向一張 只有50w行數(shù)據(jù)的table中insert數(shù)據(jù)后建立索引的時(shí)間就會(huì)呈數(shù)量級(jí)的下降，極大了提高了DB的運(yùn)行時(shí)效率，提高了DB的并發(fā)量。當(dāng)然分表的好處還不知這些，還有諸如寫(xiě)操作的鎖操作等，都會(huì)帶來(lái)很多顯然的好處。

綜上，分庫(kù)降低了單點(diǎn)機(jī)器的負(fù)載；分表，提高了數(shù)據(jù)操作的效率，尤其是Write操作的效率。行文至此我們依然沒(méi)有涉及到如何切分的問(wèn)題。接下來(lái)，我們將對(duì)切分規(guī)則進(jìn)行詳盡的闡述和說(shuō)明。

上文中提到，要想做到數(shù)據(jù)的水平切分，在每一個(gè)表中都要有相冗余字符作為切分依據(jù)和標(biāo)記字段，通常的應(yīng)用中我們選用user_id作為區(qū)分字段，基于此就有如下三種分庫(kù)的方式和規(guī)則：（當(dāng)然還可以有其他的方式）

(1)?號(hào)段分區(qū)

user_id為1～1000的對(duì)應(yīng)DB1，1001～2000的對(duì)應(yīng)DB2，以此類推；

優(yōu)點(diǎn)：可部分遷移

缺點(diǎn)：數(shù)據(jù)分布不均

(2)hash取模分區(qū)

對(duì)user_id進(jìn)行hash（或者如果user_id是數(shù)值型的話直接使用user_id 的值也可），然后用一個(gè)特定的數(shù)字，比如應(yīng)用中需要將一個(gè)數(shù)據(jù)庫(kù)切分成4個(gè)數(shù)據(jù)庫(kù)的話，我們就用4這個(gè)數(shù)字對(duì)user_id的hash值進(jìn)行取模運(yùn)算，也就是user_id%4,這樣的話每次運(yùn)算就有四種可能：結(jié)果為1的時(shí)候?qū)?yīng)DB1；結(jié)果為2的時(shí)候?qū)?yīng)DB2；結(jié)果為3的時(shí)候?qū)?yīng)DB3；結(jié)果為0的時(shí)候?qū)?yīng)DB4。這樣一來(lái)就非常均勻的將數(shù)據(jù)分配到4個(gè)DB中。

優(yōu)點(diǎn)：數(shù)據(jù)分布均勻

缺點(diǎn)：數(shù)據(jù)遷移的時(shí)候麻煩，不能按照機(jī)器性能分?jǐn)倲?shù)據(jù)

(3)在認(rèn)證庫(kù)中保存數(shù)據(jù)庫(kù)配置

就是建立一個(gè)DB，這個(gè)DB單獨(dú)保存user_id到DB的映射關(guān)系，每次訪問(wèn)數(shù)據(jù)庫(kù)的時(shí)候都要先查詢一次這個(gè)數(shù)據(jù)庫(kù)，以得到具體的DB信息，然后才能進(jìn)行我們需要的查詢操作。

優(yōu)點(diǎn)：靈活性強(qiáng)，一對(duì)一關(guān)系

缺點(diǎn)：每次查詢之前都要多一次查詢，性能大打折扣

以上就是通常的開(kāi)發(fā)中我們選擇的三種方式，有些復(fù)雜的項(xiàng)目中可能會(huì)混合使用這三種方式。 通過(guò)上面的描述，我們對(duì)分庫(kù)的規(guī)則也有了簡(jiǎn)單的認(rèn)識(shí)和了解。當(dāng)然還會(huì)有更好更完善的分庫(kù)方式，還需要我們不斷的探索和發(fā)現(xiàn)。

第3章 本課題研究的基本輪廓

分布式數(shù)據(jù)方案提供功能如下：

（1）提供分庫(kù)規(guī)則和路由規(guī)則（RouteRule簡(jiǎn)稱RR）；

（2）引入集群（Group）的概念，保證數(shù)據(jù)的高可用性；

（3）引入負(fù)載均衡策略（LoadBalancePolicy簡(jiǎn)稱LB）；

（4）引入集群節(jié)點(diǎn)可用性探測(cè)機(jī)制，對(duì)單點(diǎn)機(jī)器的可用性進(jìn)行定時(shí)的偵測(cè)，以保證LB策略的正確實(shí)施，以確保系統(tǒng)的高度穩(wěn)定性；

（5）引入讀/寫(xiě)分離，提高數(shù)據(jù)的查詢速度；

僅僅是分庫(kù)分表的數(shù)據(jù)層設(shè)計(jì)也是不夠完善的，當(dāng)我們采用了數(shù)據(jù)庫(kù)切分方案，也就是說(shuō)有N臺(tái)機(jī)器組成了一個(gè)完整的DB 。如果有一臺(tái)機(jī)器宕機(jī)的話，也僅僅是一個(gè)DB的N分之一的數(shù)據(jù)不能訪問(wèn)而已，這是我們能接受的，起碼比切分之前的情況好很多了，總不至于整個(gè)DB都不能訪問(wèn)。

一般的應(yīng)用中，這樣的機(jī)器故障導(dǎo)致的數(shù)據(jù)無(wú)法訪問(wèn)是可以接受的，假設(shè)我們的系統(tǒng)是一個(gè)高并發(fā)的電子商務(wù)網(wǎng)站呢？單節(jié)點(diǎn)機(jī)器宕機(jī)帶來(lái)的經(jīng)濟(jì)損失是非常嚴(yán)重的。也就是說(shuō)，現(xiàn)在我們這樣的方案還是存在問(wèn)題的，容錯(cuò)性能是經(jīng)不起考驗(yàn)的。當(dāng)然了，問(wèn)題總是有解決方案的。我們引入集群的概念，在此我稱之為Group，也就是每一個(gè)分庫(kù)的節(jié)點(diǎn)我們引入多臺(tái)機(jī)器，每臺(tái)機(jī)器保存的數(shù)據(jù)是一樣的，一般情況下這多臺(tái)機(jī)器分?jǐn)傌?fù)載，當(dāng)出現(xiàn)宕機(jī)情況，負(fù)載均衡器將分配負(fù)載給這臺(tái)宕機(jī)的機(jī)器。這樣一來(lái)，就解決了容錯(cuò)性的問(wèn)題。

如上圖所示，整個(gè)數(shù)據(jù)層有Group1，Group2，Group3三個(gè)集群組成，這三個(gè)集群就是數(shù)據(jù)水平切分的結(jié)果，當(dāng)然這三個(gè)集群也就組成了一個(gè)包含完整數(shù)據(jù)的DB。每一個(gè)Group包括1個(gè)Master（當(dāng)然Master也可以是多個(gè)）和 N個(gè)Slave，這些Master和Slave的數(shù)據(jù)是一致的。 比如Group1中的一個(gè)slave發(fā)生了宕機(jī)現(xiàn)象，那么還有兩個(gè)slave是可以用的，這樣的模型總是不會(huì)造成某部分?jǐn)?shù)據(jù)不能訪問(wèn)的問(wèn)題，除非整個(gè) Group里的機(jī)器全部宕掉，但是考慮到這樣的事情發(fā)生的概率非常小（除非是斷電了，否則不易發(fā)生吧）。

在沒(méi)有引入集群以前，我們的一次查詢的過(guò)程大致如下：請(qǐng)求數(shù)據(jù)層，并傳遞必要的分庫(kù)區(qū)分字段 （通常情況下是user_id）。數(shù)據(jù)層根據(jù)區(qū)分字段Route到具體的DB，在這個(gè)確定的DB內(nèi)進(jìn)行數(shù)據(jù)操作。

這是沒(méi)有引入集群的情況，當(dāng)時(shí)引入集群會(huì) 是什么樣子的呢？我們的路由器上規(guī)則和策略其實(shí)只能路由到具體的Group，也就是只能路由到一個(gè)虛擬的Group，這個(gè)Group并不是某個(gè)特定的物理服務(wù)器。接下來(lái)需要做的工作就是找到具體的物理的DB服務(wù)器，以進(jìn)行具體的數(shù)據(jù)操作。

基于這個(gè)環(huán)節(jié)的需求，我們引入了負(fù)載均衡器的概念 （LB），負(fù)載均衡器的職責(zé)就是定位到一臺(tái)具體的DB服務(wù)器。具體的規(guī)則如下：負(fù)載均衡器會(huì)分析當(dāng)前sql的讀寫(xiě)特性，如果是寫(xiě)操作或者是要求實(shí)時(shí)性很強(qiáng)的操作的話，直接將查詢負(fù)載分到Master，如果是讀操作則通過(guò)負(fù)載均衡策略分配一個(gè)Slave。

我們的負(fù)載均衡器的主要研究方向也就是負(fù)載分發(fā)策略，通常情況下負(fù)載均衡包括隨機(jī)負(fù)載均衡和加權(quán)負(fù)載均衡。隨機(jī)負(fù)載均衡很好理解，就是從N個(gè)Slave中隨機(jī)選取一個(gè)Slave。這樣的隨機(jī)負(fù)載均衡是不考慮機(jī)器性能的，它默認(rèn)為每臺(tái)機(jī)器的性能是一樣的。假如真實(shí)的情況是這樣的，這樣做也是無(wú)可厚非的。假如實(shí)際情況并非如此呢？每個(gè)Slave的機(jī)器物理性能和配置不一樣的情況，再使用隨機(jī)的不考慮性能的負(fù)載均衡，是非常不科學(xué)的，這樣一來(lái)會(huì)給機(jī)器性能差的機(jī)器帶來(lái)不必要的高負(fù)載，甚至帶來(lái)宕機(jī)的危險(xiǎn)，同時(shí)高性能的數(shù)據(jù)庫(kù)服務(wù)器也不能充分發(fā)揮其物理性能。基于此考慮從，我們引入了加權(quán)負(fù)載均衡，也就是在我們的系統(tǒng)內(nèi)部通過(guò)一定的接口，可以給每臺(tái)DB服務(wù)器分配一個(gè)權(quán)值，然后再運(yùn)行時(shí)LB根據(jù)權(quán)值在集群中的比重，分配一定比例的負(fù)載給該DB服務(wù)器。當(dāng)然這樣的概念的引入，無(wú)疑增大了系統(tǒng)的復(fù)雜性和可維護(hù)性。有得必有失，我們也沒(méi)有辦法逃過(guò)的。

有了分庫(kù)，有了集群，有了負(fù)載均衡器，是不是就萬(wàn)事大吉了呢？ 事情遠(yuǎn)沒(méi)有我們想象的那么簡(jiǎn)單。雖然有了這些東西，基本上能保證我們的數(shù)據(jù)層可以承受很大的壓力，但是這樣的設(shè)計(jì)并不能完全規(guī)避數(shù)據(jù)庫(kù)宕機(jī)的危害。假如Group1中的slave2 宕機(jī)了，那么系統(tǒng)的LB并不能得知，這樣的話其實(shí)是很危險(xiǎn)的，因?yàn)長(zhǎng)B不知道，它還會(huì)以為slave2為可用狀態(tài)，所以還是會(huì)給slave2分配負(fù)載。這樣一來(lái)，問(wèn)題就出來(lái)了，客戶端很自然的就會(huì)發(fā)生數(shù)據(jù)操作失敗的錯(cuò)誤或者異常。

這樣是非常不友好的！怎樣解決這樣的問(wèn)題呢？ 我們引入集群節(jié)點(diǎn)的可用性探測(cè)機(jī)制?，或者是可用性的數(shù)據(jù)推送機(jī)制。這兩種機(jī)制有什么不同呢？首先說(shuō)探測(cè)機(jī)制吧，顧名思義，探測(cè)即使，就是我的數(shù)據(jù)層客戶端，不定時(shí)對(duì)集群中各個(gè)數(shù)據(jù)庫(kù)進(jìn)行可用性的嘗試，實(shí)現(xiàn)原理就是嘗試性鏈接，或者數(shù)據(jù)庫(kù)端口的嘗試性訪問(wèn)，都可以做到。

那數(shù)據(jù)推送機(jī)制又是什么呢？其實(shí)這個(gè)就要放在現(xiàn)實(shí)的應(yīng)用場(chǎng)景中來(lái)討論這個(gè)問(wèn)題了，一般情況下應(yīng)用的DB 數(shù)據(jù)庫(kù)宕機(jī)的話我相信DBA肯定是知道的，這個(gè)時(shí)候DBA手動(dòng)的將數(shù)據(jù)庫(kù)的當(dāng)前狀態(tài)通過(guò)程序的方式推送到客戶端，也就是分布式數(shù)據(jù)層的應(yīng)用端，這個(gè)時(shí)候在更新一個(gè)本地的DB狀態(tài)的列表。并告知LB，這個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)不能使用，請(qǐng)不要給它分配負(fù)載。一個(gè)是主動(dòng)的監(jiān)聽(tīng)機(jī)制，一個(gè)是被動(dòng)的被告知的機(jī)制。兩者各有所長(zhǎng)。但是都可以達(dá)到同樣的效果。這樣一來(lái)剛才假設(shè)的問(wèn)題就不會(huì)發(fā)生了，即使就是發(fā)生了，那么發(fā)生的概率也會(huì)降到最低。

上面的文字中提到的Master和Slave ，我們并沒(méi)有做太多深入的講解。一個(gè)Group由1個(gè)Master和N個(gè)Slave組成。為什么這么做呢？其中Master負(fù)責(zé)寫(xiě)操作的負(fù)載，也就是說(shuō)一切寫(xiě)的操作都在Master上進(jìn)行，而讀的操作則分?jǐn)偟絊lave上進(jìn)行。這樣一來(lái)的可以大大提高讀取的效率。在一般的互聯(lián)網(wǎng)應(yīng)用中，經(jīng)過(guò)一些數(shù)據(jù)調(diào)查得出結(jié)論，讀/寫(xiě)的比例大概在 10：1左右 ，也就是說(shuō)大量的數(shù)據(jù)操作是集中在讀的操作，這也就是為什么我們會(huì)有多個(gè)Slave的原因。

但是為什么要分離讀和寫(xiě)呢？熟悉DB的研發(fā)人員都知道，寫(xiě)操作涉及到鎖的問(wèn)題，不管是行鎖還是表鎖還是塊鎖，都是比較降低系統(tǒng)執(zhí)行效率的事情。我們這樣的分離是把寫(xiě)操作集中在一個(gè)節(jié)點(diǎn)上，而讀操作其其他 的N個(gè)節(jié)點(diǎn)上進(jìn)行，從另一個(gè)方面有效的提高了讀的效率，保證了系統(tǒng)的高可用性。

?

原文：

http://zhengdl126.iteye.com/blog/419850

轉(zhuǎn)載于:https://www.cnblogs.com/bangaj/p/6087523.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的数据库水平切分的实现原理解析——分库，分表，主从，集群，负载均衡器（转）...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。