數(shù)據(jù)庫性能需求分析及評估模型

? ? ? ?數(shù)據(jù)庫作為應(yīng)用系統(tǒng)當(dāng)中最重要的一塊誉察,也是性能測試非常關(guān)注的一塊域帐,根據(jù)我自己的項目經(jīng)驗痒谴,和以往對應(yīng)用系統(tǒng)的性能需求分析和測試策略制定過程,總結(jié)一下如何開展數(shù)據(jù)庫系統(tǒng)的性能需求分析箱叁,以及制定數(shù)據(jù)庫能力評估模型墅垮。

一、數(shù)據(jù)庫性能需求制定

1蝌蹂、需求信息收集-任務(wù)/交易分布

(1)收集有哪些主要交易任務(wù)(與業(yè)務(wù)系統(tǒng)需求一致)

(2)在一天的某些特定時刻系統(tǒng)都有哪些主要操作噩斟,以及操作量

2、需求信息收集-交易混合圖

? ? ? 需要關(guān)注的信息有:

??? 高峰期有哪些操作孤个?

??? 中間件操作有多少?數(shù)據(jù)庫操作有多少沛简?

??? 如果任務(wù)失敗齐鲤,那么商業(yè)風(fēng)險有多少?

??? 有沒有涉及保密系數(shù)高的數(shù)據(jù)椒楣?

? ? ? 測試選型標(biāo)準(zhǔn):高吞吐量给郊、高I/O、高商業(yè)風(fēng)險

二捧灰、數(shù)據(jù)庫能力需求

1淆九、高吞吐量

? ? ? 滿足高并發(fā)下的大數(shù)據(jù)量交互需求,滿足數(shù)據(jù)備份或ETL過程的大數(shù)據(jù)量遷移毛俏。具體需求信息獲取參照以上數(shù)據(jù)庫應(yīng)用需求炭庙。

2、負(fù)載均衡

? ? ? 滿足高并發(fā)下數(shù)據(jù)庫的負(fù)載均衡能力煌寇,需求分析需要收集數(shù)據(jù)庫的部署架構(gòu)焕蹄、負(fù)載均衡策略等數(shù)據(jù)信息。

3阀溶、讀寫分離

? ? ? 獲取需求的要點是明確哪些是寫節(jié)點腻脏,哪些是讀節(jié)點,并且切換的策略什么银锻,數(shù)據(jù)同步的策略是什么永品。

4、分區(qū)分片(分庫分表)

? ? ? 獲取需求的要點是把握數(shù)據(jù)的垂直切換和水平分庫概念击纬。明確需要對哪些數(shù)據(jù)塊進(jìn)行切分鼎姐,分別分散到哪幾臺數(shù)據(jù)庫主機上;需要對哪些大表進(jìn)行數(shù)據(jù)水平切分,并且分布到哪些DB或table中症见。通過需求分析喂走,做出數(shù)據(jù)切分的合理性判斷,以及做出系統(tǒng)可測性的判斷谋作。

5芋肠、高并發(fā)

? ? ? 根據(jù)以上的數(shù)據(jù)庫應(yīng)用需求,進(jìn)一步制定數(shù)據(jù)庫的高并發(fā)需求遵蚜,估算出單臺數(shù)據(jù)庫的API接口壓力和需要滿足的并發(fā)能力帖池。

6、高可用性

? ? ? 高可用性可能也綜合涉及到數(shù)據(jù)的多項能力吭净,主要應(yīng)用的是集群技術(shù)睡汹,HA容錯及互備技術(shù),體現(xiàn)的是無故障運行寂殉。獲取需求的要點是明確高可用性技術(shù)架構(gòu)囚巴,了解HA采用的工作方式,以及掌握故障切換方法和數(shù)據(jù)一致性驗證需求友扰。

三彤叉、數(shù)據(jù)庫評估模型

(一)關(guān)鍵業(yè)務(wù)時間指標(biāo)

? ? ? ?在我們的印象中,應(yīng)用的關(guān)鍵業(yè)務(wù)能夠提供真正的用戶行為洞察——他們捕捉實時性能數(shù)據(jù)村怪,展現(xiàn)真實用戶在交互時的用戶體驗秽浇。衡量一個關(guān)鍵業(yè)務(wù)的性能包括捕捉交易的整體響應(yīng)時間以及測量其不同層面的響應(yīng)時間。這些時間都可以滿足你業(yè)務(wù)需要的基準(zhǔn)做比較甚负。

? ? ? 如果你只想測量應(yīng)用的某個方面柬焕,關(guān)鍵業(yè)務(wù)流程是最佳選擇。雖然容器指標(biāo)可以提供豐富的信息梭域,可以幫助你確定何時自動縮放您的環(huán)境斑举,但業(yè)務(wù)流程交易還是決定著你的應(yīng)用性能最終效果。不管你作為什么規(guī)模公司的程序“猿”碰辅,都應(yīng)該首先關(guān)心你的用戶是否可以完成他們的關(guān)鍵業(yè)務(wù)流程懂昂。

? ? ? ?一旦你定義了整個關(guān)鍵業(yè)務(wù),性能好壞就是衡量整個應(yīng)用生態(tài)系統(tǒng)的最好標(biāo)準(zhǔn)没宾。我們需要設(shè)定低于平均關(guān)鍵業(yè)務(wù)響應(yīng)時間的交易為異常行為凌彬,這樣就能更好的觀察應(yīng)用的性能了,如下圖所示循衰。

? ? ? 那么問題來了铲敛,怎么設(shè)定關(guān)鍵業(yè)務(wù)的標(biāo)準(zhǔn)呢?

? ? ? 這里提供一個簡單的方法供大家參考:假設(shè)關(guān)鍵業(yè)務(wù)在周三13:00~14:00是一個常見的高峰会钝,那么選擇這個時段平均響應(yīng)時間作為標(biāo)準(zhǔn)伐蒋,等到下周三的同一個時段工三,再將這周的這個時段的所有關(guān)鍵業(yè)務(wù)平均響應(yīng)時間與前一周相比得到一個平均值,如此循環(huán)。通過這個機制,應(yīng)用可以隨時間而發(fā)展驯遇,而原始的關(guān)鍵業(yè)務(wù)數(shù)據(jù)也變得更有意義。關(guān)鍵業(yè)務(wù)的監(jiān)測是用戶體驗中最具反思性的測量方法掸读,因此它們是能捕捉到的最重要的指標(biāo)之一。

(二)SQL性能指標(biāo)

? ? ? 查詢的性能主要體現(xiàn)為SQL查詢緩慢和數(shù)據(jù)返回時間過長宏多。那么我們要怎么解決它呢儿惫?下面是測試需要重定關(guān)注的:

? ? ? 1、數(shù)據(jù)的查詢方式對傳輸效率的影響伸但,比如選用了更多的數(shù)據(jù):查詢返回的列太多的話會導(dǎo)致在選擇行和檢索數(shù)據(jù)時造成緩慢(如使用了SELECT*肾请,沒有列出所需的列)。此外更胖,在結(jié)果中列出所需的列铛铁,也能減少數(shù)據(jù)傳輸,有利于性能的提升却妨。

? ? ? 2避归、重點關(guān)注索引的應(yīng)用,對于只是訪問表中的幾個字段管呵,并且字段內(nèi)容較少,可以為這幾個字段單獨建立一個組合索引哺窄,這樣就可以直接只通過訪問索引得到數(shù)據(jù)捐下,一般索引占用的磁盤空間比表小很多,所以這種方式可以大大減少磁盤IO開銷萌业。

? ? ? 3坷襟、關(guān)注慢SQL執(zhí)行計劃及優(yōu)化:SQL執(zhí)行計劃是關(guān)系型數(shù)據(jù)庫最核心的技術(shù)之一,它表示SQL執(zhí)行時的數(shù)據(jù)訪問算法生年。當(dāng)業(yè)務(wù)需求越來越復(fù)雜婴程,表數(shù)據(jù)量越來越大,SQL也需要支持非常復(fù)雜的業(yè)務(wù)邏輯抱婉,但SQL的性能還需要提高档叔,因此,優(yōu)秀的關(guān)系型數(shù)據(jù)庫除了需要支持復(fù)雜的SQL語法及更多函數(shù)外蒸绩,還需要有一套優(yōu)秀的算法庫來提高SQL性能衙四。

? ? ? 4、關(guān)注批處理對性能影響:讀取大量的數(shù)據(jù)或生產(chǎn)復(fù)雜的分析報告時通常都是在批量操作患亿。這些操作是資源密集型传蹈,可能會影響在線用戶的性能。想要解決這個問題需要將這些操作在低負(fù)載下進(jìn)行,如在夜間惦界;或使用單獨的數(shù)據(jù)庫來處理和分析報告挑格。

(三)鎖及粒度

? ? ? 數(shù)據(jù)庫一般都允許多用戶的存在,多個用戶同時活動必然會導(dǎo)致沖突沾歪,然而正常工作中這種情況又無法避免漂彤,所以測試需要關(guān)注的是鎖的應(yīng)用與性能的平衡關(guān)系:

? ? ? 1、頁/行鎖定:當(dāng)一個用戶試圖讀取另一個用戶正在修改的數(shù)據(jù)瞬逊,或修改另一個用戶正在讀取的數(shù)據(jù)時显歧,又或者嘗試修改另一個事務(wù)正在嘗試修改的數(shù)據(jù)時,就會出現(xiàn)并發(fā)問題确镊。這時候資源就會被鎖定士骤。

? ? ? 可以鎖定的資源在粒度(granularity)上差異很大。從細(xì)(行)到粗(數(shù)據(jù)庫)蕾域。細(xì)粒度鎖允許更大的數(shù)據(jù)庫并發(fā)拷肌,因為用戶能對某些未鎖定的行執(zhí)行查詢。然而旨巷,每個由數(shù)據(jù)庫系統(tǒng)產(chǎn)生的鎖都需要內(nèi)存巨缘,所以數(shù)以千計獨立的行級別的鎖也會影響數(shù)據(jù)庫的性能。粗粒度的鎖降低了并發(fā)性采呐,同時消耗的資源也較少若锁。

? ? ? 2、死鎖:死鎖是數(shù)據(jù)庫性能的重量級殺手之一斧吐,然而死鎖卻是不同事務(wù)之間搶占數(shù)據(jù)資源造成的又固。死鎖耗時耗資源,然而在大型數(shù)據(jù)庫中煤率,高并發(fā)帶來的死鎖是不可避免的仰冠,所以我們只能讓其變的更少。

①按照同一順序訪問數(shù)據(jù)庫資源

②保持事務(wù)的簡短蝶糯,盡量不要讓一個事務(wù)處理過于復(fù)雜的讀寫操作洋只。事務(wù)過于復(fù)雜,占用資源會增多昼捍,處理時間增長识虚,容易與其它事務(wù)沖突,提升死鎖概率端三。

③盡量不要在事務(wù)中要求用戶響應(yīng)舷礼,比如修改新增數(shù)據(jù)之后再完成整個事務(wù)的提交,這樣延長事務(wù)占用資源的時間郊闯,也會提升死鎖概率妻献。

④盡量減少數(shù)據(jù)庫的并發(fā)量(通過優(yōu)化架構(gòu)實現(xiàn))蛛株。

⑤盡可能使用分區(qū)表,分區(qū)視圖育拨,把數(shù)據(jù)放置在不同的磁盤和文件組中谨履,分散訪問保存在不同分區(qū)的數(shù)據(jù),減少因為表中放置鎖而造成的其它事務(wù)長時間等待熬丧。

⑥避免占用時間很長并且關(guān)系表復(fù)雜的數(shù)據(jù)操作笋粟。

⑦使用較低的隔離級別,使用較低的隔離級別比使用較高的隔離級別持有共享鎖的時間更短析蝴。這樣就減少了鎖爭用害捕。

(四)硬件資源指標(biāo)

? ? ? 然而并不是所有的數(shù)據(jù)庫性能問題都是來自數(shù)據(jù)庫本身,我們?nèi)粘9ぷ髦凶畛R姷牧硪粋€情景就是數(shù)據(jù)庫的硬件有若干問題闷畸,這里我們簡單的介紹一下可能會出現(xiàn)的情況尝盼,畢竟市面上有已經(jīng)有很多工具可以監(jiān)測這些問題了。

1佑菩、沒有足夠的CPU或CPU速度太慢:更多的CPU可以分擔(dān)服務(wù)器的負(fù)載盾沫,從而提高性能。

2殿漠、慢的磁盤沒有足夠的IOPS:磁盤性能可以描述為每秒輸入/輸出操作(IOPS)赴精,它表示每秒磁盤的吞吐量。

3绞幌、配置不正確的磁盤:數(shù)據(jù)庫需要效果明顯的磁盤訪問蕾哟,配置不正確的磁盤會造成相當(dāng)大的性能影響。

4莲蜘、沒有足夠的內(nèi)存:受限或不好的物理內(nèi)存影響數(shù)據(jù)庫性能渐苏,可用的內(nèi)存越多,性能越好菇夸。

(五)NoSQL

? ? ? NoSQL發(fā)展到今天,已經(jīng)有了很大的吸引力仪吧,因為它處理大規(guī)模數(shù)據(jù)和高并發(fā)的能力非常顯著庄新。但是,NoSQL卻很難測試薯鼠,也不容易監(jiān)控择诈。

1、NoSQL特性:關(guān)系型SQL已經(jīng)成熟出皇,有行業(yè)標(biāo)準(zhǔn)接口羞芍,但是每一個NoSQL都是獨一無二的存在,并且都不支持復(fù)雜的數(shù)據(jù)庫模型郊艘。所以簡潔荷科、有效唯咬、速度是它的業(yè)務(wù)應(yīng)用標(biāo)準(zhǔn)。

2畏浆、集群化和負(fù)載均衡:NoSQL數(shù)據(jù)庫相比關(guān)系型數(shù)據(jù)庫通常更多的是資源密集型胆胰。它們需要更多的內(nèi)存和內(nèi)存分配,集群化和分布式是評估要點刻获;

3蜀涨、擴展性要求:隨著數(shù)據(jù)庫的需求增加,硬件也必須擴展蝎毡,可擴展性是一項評估要點厚柳。

4、高可用性要求:可以說NoSQL對穩(wěn)定性的要求更為苛刻(因為它們有些是基于內(nèi)存的數(shù)據(jù)庫)沐兵,高可用性是重要評估點别垮。

5、監(jiān)控要求:相對于已經(jīng)成熟的關(guān)系SQL痒筒,NoSQL現(xiàn)在的監(jiān)控可以說是比較困難的宰闰,國內(nèi)也只有聽云一家公司能夠支持主流的Memcached, MongoDB, Redis等非關(guān)系型數(shù)據(jù)庫服務(wù)(但是NoSQL監(jiān)控部分要收費);ApplicationsManager也支持對Memcached, MongoDB,Redis簿透、HBase移袍、Oracle NoSQL的監(jiān)控(這些的監(jiān)控指標(biāo)還不夠豐富,有待完善)老充。

(六)擴展架構(gòu)模型

1葡盗、數(shù)據(jù)切分和分布式

數(shù)據(jù)切分可以是物理上的,對數(shù)據(jù)通過一系列的切分規(guī)則將數(shù)據(jù)分布到不同的DB服務(wù)器上啡浊,通過路由規(guī)則路由訪問特定的數(shù)據(jù)庫觅够,這樣一來每次訪問面對的就不是單臺服務(wù)器了,而是N臺服務(wù)器巷嚣,這樣就可以降低單臺機器的負(fù)載壓力喘先。數(shù)據(jù)切分也可以是數(shù)據(jù)庫內(nèi)的,對數(shù)據(jù)通過一系列的切分規(guī)則廷粒,將數(shù)據(jù)分布到一個數(shù)據(jù)庫的不同表中窘拯。

(1)數(shù)據(jù)垂直切分

數(shù)據(jù)的垂直切分,也可以稱之為縱向切分坝茎。將數(shù)據(jù)庫想象成為由很多個一大塊一大塊的“數(shù)據(jù)塊”(表)組成涤姊,我們垂直的將這些“數(shù)據(jù)塊”切開,然后將他們分散到多臺數(shù)據(jù)庫主機上面嗤放。這樣的切分方法就是一個垂直(縱向)的數(shù)據(jù)切分思喊。

(2)數(shù)據(jù)水平切分

? ? ? 數(shù)據(jù)的垂直切分基本上可以簡單的理解為按照表、按照模塊來切分?jǐn)?shù)據(jù)次酌,而水平切分就不再是按照表或者是功能模塊來切分了恨课。一般來說舆乔,簡單的水平切分主要是將某個訪問極其平凡的表再按照某個字段的某種規(guī)則來分散到多個表之中,每個表中包含一部分?jǐn)?shù)據(jù)庄呈。

除了垂直切分蜕煌、水平切分,還有其他的切分或分片方式诬留,如導(dǎo)出切分斜纪、混合切分。

(3)負(fù)載均衡和讀寫分離

一般是通過負(fù)載均衡器文兑,其職責(zé)就是定位到一臺具體的DB服務(wù)器盒刚。具體的規(guī)則如下:負(fù)載均衡器會分析當(dāng)前sql的讀寫特性,如果是寫操作或者是要求實時性很強的操作的話绿贞,直接將查詢負(fù)載分到Master因块,如果是讀操作則通過負(fù)載均衡策略分配一個Slave。

其中Master負(fù)責(zé)寫操作的負(fù)載籍铁,也就是說一切寫的操作都在Master上進(jìn)行涡上,而讀的操作則分?jǐn)偟絊lave上進(jìn)行。這樣一來的可以大大提高讀取的效率拒名。在一般的互聯(lián)網(wǎng)應(yīng)用中吩愧,經(jīng)過一些數(shù)據(jù)調(diào)查得出結(jié)論,讀/寫的比例大概在 10:1左右 增显,也就是說大量的數(shù)據(jù)操作是集中在讀的操作雁佳,這也就是為什么我們會有多個Slave的原因。

但是為什么要分離讀和寫呢同云?熟悉DB的技術(shù)人員都知道糖权,寫操作涉及到鎖的問題,不管是行鎖還是表鎖還是塊鎖炸站,都是會降低系統(tǒng)執(zhí)行的效率星澳。我們這樣的分離是把寫操作集中在一個節(jié)點上,而讀操作在其他的N個節(jié)點上進(jìn)行旱易,從另一個方面有效的提高了讀的效率募判,保證了系統(tǒng)的高可用性。

(4)分布式存儲

分布式存儲是將數(shù)據(jù)分散存儲在多臺獨立的設(shè)備上咒唆。傳統(tǒng)的網(wǎng)絡(luò)存儲系統(tǒng)采用集中的存儲服務(wù)器存放所有數(shù)據(jù),存儲服務(wù)器成為系統(tǒng)性能的瓶頸释液,也是可靠性和安全性的焦點全释,不能滿足大規(guī)模存儲應(yīng)用的需要。分布式網(wǎng)絡(luò)存儲系統(tǒng)采用可擴展的系統(tǒng)結(jié)構(gòu)误债,利用多臺存儲服務(wù)器分擔(dān)存儲負(fù)荷浸船,利用位置服務(wù)器定位存儲信息妄迁,它不但提高了系統(tǒng)的可靠性、可用性和存取效率李命,還易于擴展登淘。

分布式存儲利用的就是數(shù)據(jù)的切分,也叫數(shù)據(jù)分片封字,數(shù)據(jù)分片將達(dá)到以下三個目的:

??分布均勻黔州,即每臺設(shè)備上的數(shù)據(jù)量要盡可能相近;

??負(fù)載均衡阔籽,即每臺設(shè)備上的請求量要盡可能相近流妻;

??擴縮容時產(chǎn)生的數(shù)據(jù)遷移盡可能少。

? ? ? 有了分布式存儲笆制,就會有分布式計算绅这,這就是大數(shù)據(jù)的范疇了,在這里不多說在辆。

2证薇、Cache與Search的利用

(1)結(jié)合傳統(tǒng)關(guān)系型數(shù)據(jù)庫和NoSQL兩種類型數(shù)據(jù)庫的優(yōu)缺點,對于Oracle匆篓、Mysql這些數(shù)據(jù)庫浑度,可以通過引入Cache(Redis、Memcached)奕删,減少數(shù)據(jù)庫的訪問俺泣,增加性能(主要是解決傳統(tǒng)關(guān)系型數(shù)據(jù)庫的IO性能瓶頸,Cache都是基于內(nèi)存的完残,大大減少了磁盤讀寫)伏钠。特別說明一下,這里說的Cache不是指數(shù)據(jù)庫底層對應(yīng)的Cache緩存谨设,數(shù)據(jù)庫層次的緩存一般針對的是查詢內(nèi)容熟掂,而且粒度也太小,一般只有表中數(shù)據(jù)沒有變更的時候才發(fā)揮作用扎拣。我們這里說的Cache赴肚,是指外部引入的數(shù)據(jù)庫緩存。

(2)通過引入Search(Lucene二蓝、Solr誉券、ElasticSearch),利用搜索引擎高效的全文索引和分詞算法刊愚,以及高效的數(shù)據(jù)檢索實現(xiàn)踊跟,來解決數(shù)據(jù)庫和傳統(tǒng)的Cache軟件完全無法解決的全文模糊搜索、分類統(tǒng)計查詢等功能鸥诽。

? ? ? 通過以上的數(shù)據(jù)庫性能評估模型分析商玫,我們就能把握數(shù)據(jù)庫系統(tǒng)將要有的性能能力箕憾,并分析具體的測試范圍和指標(biāo)評估范圍,以決定后期需要采用的測試方法拳昌、策略和工具袭异。畢竟性能不是靠測試和調(diào)優(yōu)出來的,是靠設(shè)計出來的炬藤,如果我們不了解數(shù)據(jù)庫的能力模型和相應(yīng)的架構(gòu)要求御铃,我們將很難深入開展相應(yīng)的性能測試和性能調(diào)優(yōu)工作。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末刻像,一起剝皮案震驚了整個濱河市畅买,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌细睡,老刑警劉巖谷羞,帶你破解...
    沈念sama閱讀 217,826評論 6 506
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異溜徙,居然都是意外死亡湃缎,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,968評論 3 395
  • 文/潘曉璐 我一進(jìn)店門蠢壹,熙熙樓的掌柜王于貴愁眉苦臉地迎上來嗓违,“玉大人,你說我怎么就攤上這事图贸□寮荆” “怎么了?”我有些...
    開封第一講書人閱讀 164,234評論 0 354
  • 文/不壞的土叔 我叫張陵疏日,是天一觀的道長偿洁。 經(jīng)常有香客問我,道長沟优,這世上最難降的妖魔是什么涕滋? 我笑而不...
    開封第一講書人閱讀 58,562評論 1 293
  • 正文 為了忘掉前任,我火速辦了婚禮挠阁,結(jié)果婚禮上宾肺,老公的妹妹穿的比我還像新娘。我一直安慰自己侵俗,他們只是感情好锨用,可當(dāng)我...
    茶點故事閱讀 67,611評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著隘谣,像睡著了一般增拥。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,482評論 1 302
  • 那天跪者,我揣著相機與錄音,去河邊找鬼熄求。 笑死渣玲,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的弟晚。 我是一名探鬼主播忘衍,決...
    沈念sama閱讀 40,271評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼卿城!你這毒婦竟也來了枚钓?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,166評論 0 276
  • 序言:老撾萬榮一對情侶失蹤瑟押,失蹤者是張志新(化名)和其女友劉穎搀捷,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體多望,經(jīng)...
    沈念sama閱讀 45,608評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡嫩舟,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,814評論 3 336
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了怀偷。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片家厌。...
    茶點故事閱讀 39,926評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖椎工,靈堂內(nèi)的尸體忽然破棺而出饭于,到底是詐尸還是另有隱情,我是刑警寧澤维蒙,帶...
    沈念sama閱讀 35,644評論 5 346
  • 正文 年R本政府宣布掰吕,位于F島的核電站,受9級特大地震影響木西,放射性物質(zhì)發(fā)生泄漏畴栖。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,249評論 3 329
  • 文/蒙蒙 一八千、第九天 我趴在偏房一處隱蔽的房頂上張望吗讶。 院中可真熱鬧,春花似錦恋捆、人聲如沸照皆。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,866評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽膜毁。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間瘟滨,已是汗流浹背候醒。 一陣腳步聲響...
    開封第一講書人閱讀 32,991評論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留杂瘸,地道東北人倒淫。 一個月前我還...
    沈念sama閱讀 48,063評論 3 370
  • 正文 我出身青樓,卻偏偏與公主長得像败玉,于是被迫代替她去往敵國和親敌土。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,871評論 2 354

推薦閱讀更多精彩內(nèi)容