分庫(kù)分表場(chǎng)景&策略

原文地址:http://www.reibang.com/p/3f8395402f58

數(shù)據(jù)庫(kù)瓶頸

不管是 IO 瓶頸還是 CPU 瓶頸剩蟀,最終都會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的活躍連接數(shù)增加,進(jìn)而逼近甚至達(dá)到數(shù)據(jù)庫(kù)可承載的活躍連接數(shù)的閾值。

在業(yè)務(wù) Service 來(lái)看德绿, 就是可用數(shù)據(jù)庫(kù)連接少甚至無(wú)連接可用辕录,接下來(lái)就可以想象了(并發(fā)量、吞吐量缓熟、崩潰)累魔。

IO 瓶頸

第一種:磁盤讀 IO 瓶頸摔笤,熱點(diǎn)數(shù)據(jù)太多,數(shù)據(jù)庫(kù)緩存放不下垦写,每次查詢會(huì)產(chǎn)生大量的 IO吕世,降低查詢速度→分庫(kù)和垂直分表。

第二種:網(wǎng)絡(luò) IO 瓶頸梯投,請(qǐng)求的數(shù)據(jù)太多命辖,網(wǎng)絡(luò)帶寬不夠→分庫(kù)。

CPU 瓶頸

第一種:SQL 問(wèn)題:如 SQL 中包含 join分蓖,group by尔艇,order by,非索引字段條件查詢等么鹤,增加 CPU 運(yùn)算的操作→SQL 優(yōu)化终娃,建立合適的索引,在業(yè)務(wù) Service 層進(jìn)行業(yè)務(wù)計(jì)算蒸甜。

第二種:?jiǎn)伪頂?shù)據(jù)量太大棠耕,查詢時(shí)掃描的行太多,SQL 效率低柠新,增加 CPU 運(yùn)算的操作→水平分表窍荧。

分庫(kù)分表

水平分庫(kù)

概念:以字段為依據(jù),按照一定策略(hash恨憎、range等)搅荞,將一個(gè)庫(kù)中的數(shù)據(jù)拆分到多個(gè)庫(kù)中。

結(jié)果:

每個(gè)庫(kù)的結(jié)構(gòu)都一樣

每個(gè)庫(kù)中的數(shù)據(jù)不一樣框咙,沒有交集

所有庫(kù)的數(shù)據(jù)并集是全量數(shù)據(jù)

場(chǎng)景:系統(tǒng)絕對(duì)并發(fā)量上來(lái)了咕痛,分表難以根本上解決問(wèn)題,并且還沒有明顯的業(yè)務(wù)歸屬來(lái)垂直分庫(kù)的情況下喇嘱。

分析:庫(kù)多了茉贡,IO 和 CPU 的壓力自然可以成倍緩解。

水平分表

概念:以字段為依據(jù)者铜,按照一定策略(hash腔丧、range 等),講一個(gè)表中的數(shù)據(jù)拆分到多個(gè)表中作烟。

結(jié)果:

每個(gè)表的結(jié)構(gòu)都一樣愉粤。

每個(gè)表的數(shù)據(jù)不一樣,沒有交集拿撩,所有表的并集是全量數(shù)據(jù)衣厘。

場(chǎng)景:系統(tǒng)絕對(duì)并發(fā)量沒有上來(lái),只是單表的數(shù)據(jù)量太多,影響了 SQL 效率影暴,加重了 CPU 負(fù)擔(dān)错邦,以至于成為瓶頸,可以考慮水平分表型宙。

分析:單表的數(shù)據(jù)量少了撬呢,單次執(zhí)行 SQL 執(zhí)行效率高了,自然減輕了 CPU 的負(fù)擔(dān)妆兑。

垂直分庫(kù)

概念:以表為依據(jù)魂拦,按照業(yè)務(wù)歸屬不同,將不同的表拆分到不同的庫(kù)中

結(jié)果:

每個(gè)庫(kù)的結(jié)構(gòu)都不一樣搁嗓。

每個(gè)庫(kù)的數(shù)據(jù)也不一樣晨另,沒有交集。

所有庫(kù)的并集是全量數(shù)據(jù)谱姓。

場(chǎng)景:系統(tǒng)絕對(duì)并發(fā)量上來(lái)了,并且可以抽象出單獨(dú)的業(yè)務(wù)模塊的情況下刨晴。

分析:到這一步屉来,基本上就可以服務(wù)化了。例如:隨著業(yè)務(wù)的發(fā)展狈癞,一些公用的配置表茄靠、字典表等越來(lái)越多,這時(shí)可以將這些表拆到單獨(dú)的庫(kù)中蝶桶,甚至可以服務(wù)化慨绳。再者,隨著業(yè)務(wù)的發(fā)展孵化出了一套業(yè)務(wù)模式真竖,這時(shí)可以將相關(guān)的表拆到單獨(dú)的庫(kù)中脐雪,甚至可以服務(wù)化。

垂直分表

概念:以字段為依據(jù)恢共,按照字段的活躍性战秋,將表中字段拆到不同的表中(主表和擴(kuò)展表)。

結(jié)果:

每個(gè)表的結(jié)構(gòu)不一樣讨韭。

每個(gè)表的數(shù)據(jù)也不一樣脂信,一般來(lái)說(shuō),每個(gè)表的字段至少有一列交集透硝,一般是主鍵狰闪,用于關(guān)聯(lián)數(shù)據(jù)。

所有表的并集是全量數(shù)據(jù)濒生。

場(chǎng)景:系統(tǒng)絕對(duì)并發(fā)量并沒有上來(lái)埋泵,表的記錄并不多,但是字段多罪治,并且熱點(diǎn)數(shù)據(jù)和非熱點(diǎn)數(shù)據(jù)在一起秋泄,單行數(shù)據(jù)所需的存儲(chǔ)空間較大琐馆,以至于數(shù)據(jù)庫(kù)緩存的數(shù)據(jù)行減少,查詢時(shí)回去讀磁盤數(shù)據(jù)產(chǎn)生大量隨機(jī)讀 IO恒序,產(chǎn)生 IO 瓶頸瘦麸。

分析:

可以用列表頁(yè)和詳情頁(yè)來(lái)幫助理解。垂直分表的拆分原則是將熱點(diǎn)數(shù)據(jù)(可能經(jīng)常會(huì)查詢的數(shù)據(jù))放在一起作為主表歧胁,非熱點(diǎn)數(shù)據(jù)放在一起作為擴(kuò)展表滋饲,這樣更多的熱點(diǎn)數(shù)據(jù)就能被緩存下來(lái),進(jìn)而減少了隨機(jī)讀 IO喊巍。拆了之后屠缭,要想獲取全部數(shù)據(jù)就需要關(guān)聯(lián)兩個(gè)表來(lái)取數(shù)據(jù)。但記住千萬(wàn)別用 Join崭参,因?yàn)?Join 不僅會(huì)增加 CPU 負(fù)擔(dān)并且會(huì)將兩個(gè)表耦合在一起(必須在一個(gè)數(shù)據(jù)庫(kù)實(shí)例上)呵曹。關(guān)聯(lián)數(shù)據(jù)應(yīng)該在 Service 層進(jìn)行,分別獲取主表和擴(kuò)展表的數(shù)據(jù)何暮,然后用關(guān)聯(lián)字段關(guān)聯(lián)得到全部數(shù)據(jù)奄喂。

分庫(kù)分表帶來(lái)的問(wèn)題

事務(wù)一致性問(wèn)題

①分布式事務(wù)

當(dāng)更新內(nèi)容同時(shí)存在于不同庫(kù)找那個(gè),不可避免會(huì)帶來(lái)跨庫(kù)事務(wù)問(wèn)題海洼】缧拢跨分片事務(wù)也是分布式事務(wù),沒有簡(jiǎn)單的方案坏逢,一般可使用“XA 協(xié)議”和“兩階段提交”處理域帐。

分布式事務(wù)能最大限度保證了數(shù)據(jù)庫(kù)操作的原子性。但在提交事務(wù)時(shí)需要協(xié)調(diào)多個(gè)節(jié)點(diǎn)是整,推后了提交事務(wù)的時(shí)間點(diǎn)肖揣,延長(zhǎng)了事務(wù)的執(zhí)行時(shí)間,導(dǎo)致事務(wù)在訪問(wèn)共享資源時(shí)發(fā)生沖突或死鎖的概率增高浮入。

隨著數(shù)據(jù)庫(kù)節(jié)點(diǎn)的增多许饿,這種趨勢(shì)會(huì)越來(lái)越嚴(yán)重,從而成為系統(tǒng)在數(shù)據(jù)庫(kù)層面上水平擴(kuò)展的枷鎖舵盈。

②最終一致性

對(duì)于那些性能要求很高陋率,但對(duì)一致性要求不高的系統(tǒng),往往不苛求系統(tǒng)的實(shí)時(shí)一致性秽晚,只要在允許的時(shí)間段內(nèi)達(dá)到最終一致性即可瓦糟,可采用事務(wù)補(bǔ)償?shù)姆绞健?/p>

與事務(wù)在執(zhí)行中發(fā)生錯(cuò)誤立刻回滾的方式不同,事務(wù)補(bǔ)償是一種事后檢查補(bǔ)救的措施赴蝇,一些常見的實(shí)現(xiàn)方法有:對(duì)數(shù)據(jù)進(jìn)行對(duì)賬檢查菩浙,基于日志進(jìn)行對(duì)比,定期同標(biāo)準(zhǔn)數(shù)據(jù)來(lái)源進(jìn)行同步等。

跨節(jié)點(diǎn)關(guān)聯(lián)查詢 Join 問(wèn)題

切分之前劲蜻,系統(tǒng)中很多列表和詳情表的數(shù)據(jù)可以通過(guò) Join 來(lái)完成陆淀,但是切分之后,數(shù)據(jù)可能分布在不同的節(jié)點(diǎn)上先嬉,此時(shí) Join 帶來(lái)的問(wèn)題就比較麻煩了轧苫,考慮到性能,盡量避免使用 Join 查詢疫蔓。

解決的一些方法:

①全局表

全局表含懊,也可看做“數(shù)據(jù)字典表”,就是系統(tǒng)中所有模塊都可能依賴的一些表衅胀,為了避免庫(kù) Join 查詢岔乔,可以將這類表在每個(gè)數(shù)據(jù)庫(kù)中都保存一份。這些數(shù)據(jù)通常很少修改滚躯,所以不必?fù)?dān)心一致性的問(wèn)題雏门。

②字段冗余

一種典型的反范式設(shè)計(jì),利用空間換時(shí)間掸掏,為了性能而避免 Join 查詢茁影。

例如,訂單表在保存 userId 的時(shí)候阅束,也將 userName 也冗余的保存一份,這樣查詢訂單詳情順表就可以查到用戶名 userName茄唐,就不用查詢買家 user 表了息裸。

但這種方法適用場(chǎng)景也有限,比較適用依賴字段比較少的情況沪编,而冗余字段的一致性也較難保證呼盆。

③數(shù)據(jù)組裝

在系統(tǒng) Service 業(yè)務(wù)層面,分兩次查詢蚁廓,第一次查詢的結(jié)果集找出關(guān)聯(lián)的數(shù)據(jù) id访圃,然后根據(jù) id 發(fā)起器二次請(qǐng)求得到關(guān)聯(lián)數(shù)據(jù),最后將獲得的結(jié)果進(jìn)行字段組裝相嵌。這是比較常用的方法腿时。

④ER 分片

關(guān)系型數(shù)據(jù)庫(kù)中,如果已經(jīng)確定了表之間的關(guān)聯(lián)關(guān)系(如訂單表和訂單詳情表)饭宾,并且將那些存在關(guān)聯(lián)關(guān)系的表記錄存放在同一個(gè)分片上批糟,那么就能較好地避免跨分片 Join 的問(wèn)題。

可以在一個(gè)分片內(nèi)進(jìn)行 Join看铆,在 1:1 或 1:n 的情況下徽鼎,通常按照主表的 ID 進(jìn)行主鍵切分。

跨節(jié)點(diǎn)分頁(yè)、排序否淤、函數(shù)問(wèn)題

跨節(jié)點(diǎn)多庫(kù)進(jìn)行查詢時(shí)悄但,會(huì)出現(xiàn) limit 分頁(yè)、order by 排序等問(wèn)題石抡。

分頁(yè)需要按照指定字段進(jìn)行排序檐嚣,當(dāng)排序字段就是分頁(yè)字段時(shí),通過(guò)分片規(guī)則就比較容易定位到指定的分片汁雷;當(dāng)排序字段非分片字段時(shí)净嘀,就變得比較復(fù)雜。

需要先在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回侠讯,然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序挖藏。

上圖只是取第一頁(yè)的數(shù)據(jù),對(duì)性能影響還不是很大厢漩。但是如果取得頁(yè)數(shù)很大膜眠,情況就變得復(fù)雜的多。

因?yàn)楦鞣制?jié)點(diǎn)中的數(shù)據(jù)可能是隨機(jī)的溜嗜,為了排序的準(zhǔn)確性宵膨,需要將所有節(jié)點(diǎn)的前N頁(yè)數(shù)據(jù)都排序好做合并,最后再進(jìn)行整體排序炸宵,這樣的操作很耗費(fèi) CPU 和內(nèi)存資源辟躏,所以頁(yè)數(shù)越大,系統(tǒng)性能就會(huì)越差土全。

在使用 Max捎琐、Min、Sum裹匙、Count 之類的函數(shù)進(jìn)行計(jì)算的時(shí)候瑞凑,也需要先在每個(gè)分片上執(zhí)行相應(yīng)的函數(shù),然后將各個(gè)分片的結(jié)果集進(jìn)行匯總再次計(jì)算概页。

全局主鍵避重問(wèn)題

在分庫(kù)分表環(huán)境中籽御,由于表中數(shù)據(jù)同時(shí)存在不同數(shù)據(jù)庫(kù)中,主鍵值平時(shí)使用的自增長(zhǎng)將無(wú)用武之地惰匙,某個(gè)分區(qū)數(shù)據(jù)庫(kù)自生成 ID 無(wú)法保證全局唯一技掏。

因此需要單獨(dú)設(shè)計(jì)全局主鍵,避免跨庫(kù)主鍵重復(fù)問(wèn)題项鬼。這里有一些策略:

①UUID

UUID 標(biāo)準(zhǔn)形式是 32 個(gè) 16 進(jìn)制數(shù)字零截,分為 5 段,形式是 8-4-4-4-12 的 36 個(gè)字符秃臣。

UUID 是最簡(jiǎn)單的方案涧衙,本地生成哪工,性能高,沒有網(wǎng)絡(luò)耗時(shí)弧哎,但是缺點(diǎn)明顯雁比,占用存儲(chǔ)空間多。

另外作為主鍵建立索引和基于索引進(jìn)行查詢都存在性能問(wèn)題撤嫩,尤其是 InnoDb 引擎下偎捎,UUID 的無(wú)序性會(huì)導(dǎo)致索引位置頻繁變動(dòng),導(dǎo)致分頁(yè)序攘。

②結(jié)合數(shù)據(jù)庫(kù)維護(hù)主鍵 ID 表

CREATETABLE`sequence`(`id`bigint(20)unsignedNOTNULLauto_increment,`stub`char(1)NOTNULLdefault'',PRIMARYKEY(`id`),UNIQUEKEY`stub`(`stub`))ENGINE=MyISAM;

stub 字段設(shè)置為唯一索引茴她,同一 stub 值在 sequence 表中只有一條記錄,可以同時(shí)為多張表生成ID程奠。

使用 MyISAM 引擎而不是 InnoDb丈牢,已獲得更高的性能。MyISAM 使用的是表鎖瞄沙,對(duì)表的讀寫是串行的己沛,所以不用擔(dān)心并發(fā)時(shí)兩次讀取同一個(gè) ID。

當(dāng)需要全局唯一的 ID 時(shí)距境,執(zhí)行:

REPLACE INTO sequence(stub)VALUES('a');SELECTLAST_INSERT_ID();

此方案較為簡(jiǎn)單申尼,但缺點(diǎn)較為明顯:存在單點(diǎn)問(wèn)題,強(qiáng)依賴 DB垫桂,當(dāng) DB 異常時(shí)师幕,整個(gè)系統(tǒng)不可用。配置主從可以增加可用性诬滩。另外性能瓶頸限制在單臺(tái) MySQL 的讀寫性能霹粥。

另有一種主鍵生成策略,類似 sequence 表方案碱呼,更好的解決了單點(diǎn)和性能瓶頸問(wèn)題蒙挑。

這一方案的整體思想是:建立 2 個(gè)以上的全局 ID 生成的服務(wù)器宗侦,每個(gè)服務(wù)器上只部署一個(gè)數(shù)據(jù)庫(kù)愚臀,每個(gè)庫(kù)有一張 sequence 表用于記錄當(dāng)前全局 ID。

表中增長(zhǎng)的步長(zhǎng)是庫(kù)的數(shù)量矾利,起始值依次錯(cuò)開姑裂,這樣就能將 ID 的生成散列到各個(gè)數(shù)據(jù)庫(kù)上。

這種方案將生成 ID 的壓力均勻分布在兩臺(tái)機(jī)器上男旗,同時(shí)提供了系統(tǒng)容錯(cuò)舶斧,第一臺(tái)出現(xiàn)了錯(cuò)誤,可以自動(dòng)切換到第二臺(tái)獲取 ID察皇。

但有幾個(gè)缺點(diǎn):系統(tǒng)添加機(jī)器茴厉,水平擴(kuò)展較復(fù)雜泽台;每次獲取 ID 都要讀取一次 DB,DB 的壓力還是很大矾缓,只能通過(guò)堆機(jī)器來(lái)提升性能怀酷。

③Snowflake 分布式自增 ID 算法

Twitter 的 Snowfalke 算法解決了分布式系統(tǒng)生成全局 ID 的需求,生成 64 位 Long 型數(shù)字嗜闻。

組成部分如下:

第一位未使用蜕依。

接下來(lái)的 41 位是毫秒級(jí)時(shí)間,41 位的長(zhǎng)度可以表示 69 年的時(shí)間琉雳。

5 位 datacenterId样眠,5 位 workerId。10 位長(zhǎng)度最多支持部署 1024 個(gè)節(jié)點(diǎn)翠肘。

最后 12 位是毫秒內(nèi)計(jì)數(shù)檐束,12 位的計(jì)數(shù)順序號(hào)支持每個(gè)節(jié)點(diǎn)每毫秒產(chǎn)生 4096 個(gè) ID 序列。

數(shù)據(jù)遷移锯茄、擴(kuò)容問(wèn)題

當(dāng)業(yè)務(wù)高速發(fā)展厢塘、面臨性能和存儲(chǔ)瓶頸時(shí),才會(huì)考慮分片設(shè)計(jì)肌幽,此時(shí)就不可避免的需要考慮歷史數(shù)據(jù)的遷移問(wèn)題晚碾。

一般做法是先讀出歷史數(shù)據(jù),然后按照指定的分片規(guī)則再將數(shù)據(jù)寫入到各分片節(jié)點(diǎn)中喂急。

此外還需要根據(jù)當(dāng)前的數(shù)據(jù)量個(gè) QPS格嘁,以及業(yè)務(wù)發(fā)展速度,進(jìn)行容量規(guī)劃廊移,推算出大概需要多少分片(一般建議單個(gè)分片的單表數(shù)據(jù)量不超過(guò) 1000W)糕簿。

什么時(shí)候考慮分庫(kù)分表

①能不分就不分

并不是所有表都需要切分,主要還是看數(shù)據(jù)的增長(zhǎng)速度狡孔。切分后在某種程度上提升了業(yè)務(wù)的復(fù)雜程度懂诗。不到萬(wàn)不得已不要輕易使用分庫(kù)分表這個(gè)“大招”,避免“過(guò)度設(shè)計(jì)”和“過(guò)早優(yōu)化”苗膝。

分庫(kù)分表之前殃恒,先盡力做力所能及的優(yōu)化:升級(jí)硬件、升級(jí)網(wǎng)絡(luò)辱揭、讀寫分離离唐、索引優(yōu)化等。當(dāng)數(shù)據(jù)量達(dá)到單表瓶頸后问窃,在考慮分庫(kù)分表亥鬓。

②數(shù)據(jù)量過(guò)大,正常運(yùn)維影響業(yè)務(wù)訪問(wèn)

這里的運(yùn)維是指:

對(duì)數(shù)據(jù)庫(kù)備份域庇,如果單表太大嵌戈,備份時(shí)需要大量的磁盤 IO 和網(wǎng)絡(luò) IO覆积。

對(duì)一個(gè)很大的表做 DDL,MySQL會(huì)鎖住整個(gè)表熟呛,這個(gè)時(shí)間會(huì)很長(zhǎng)技健,這段時(shí)間業(yè)務(wù)不能訪問(wèn)此表,影響很大惰拱。

大表經(jīng)常訪問(wèn)和更新雌贱,就更有可能出現(xiàn)鎖等待。

③隨著業(yè)務(wù)發(fā)展偿短,需要對(duì)某些字段垂直拆分

這里就不舉例了欣孤,在實(shí)際業(yè)務(wù)中都可能會(huì)碰到,有些不經(jīng)常訪問(wèn)或者更新頻率低的字段應(yīng)該從大表中分離出去昔逗。

④數(shù)據(jù)量快速增長(zhǎng)

隨著業(yè)務(wù)的快速發(fā)展降传,單表中的數(shù)據(jù)量會(huì)持續(xù)增長(zhǎng),當(dāng)性能接近瓶頸時(shí)勾怒,就需要考慮水平切分婆排,做分庫(kù)分表了。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末笔链,一起剝皮案震驚了整個(gè)濱河市段只,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌鉴扫,老刑警劉巖赞枕,帶你破解...
    沈念sama閱讀 222,946評(píng)論 6 518
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異坪创,居然都是意外死亡炕婶,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,336評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門莱预,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)柠掂,“玉大人,你說(shuō)我怎么就攤上這事依沮⊙恼辏” “怎么了?”我有些...
    開封第一講書人閱讀 169,716評(píng)論 0 364
  • 文/不壞的土叔 我叫張陵悉抵,是天一觀的道長(zhǎng)肩狂。 經(jīng)常有香客問(wèn)我摘完,道長(zhǎng)姥饰,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,222評(píng)論 1 300
  • 正文 為了忘掉前任孝治,我火速辦了婚禮列粪,結(jié)果婚禮上审磁,老公的妹妹穿的比我還像新娘。我一直安慰自己岂座,他們只是感情好态蒂,可當(dāng)我...
    茶點(diǎn)故事閱讀 69,223評(píng)論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著费什,像睡著了一般钾恢。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上鸳址,一...
    開封第一講書人閱讀 52,807評(píng)論 1 314
  • 那天瘩蚪,我揣著相機(jī)與錄音,去河邊找鬼稿黍。 笑死疹瘦,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的巡球。 我是一名探鬼主播言沐,決...
    沈念sama閱讀 41,235評(píng)論 3 424
  • 文/蒼蘭香墨 我猛地睜開眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼酣栈!你這毒婦竟也來(lái)了险胰?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 40,189評(píng)論 0 277
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤矿筝,失蹤者是張志新(化名)和其女友劉穎鸯乃,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體跋涣,經(jīng)...
    沈念sama閱讀 46,712評(píng)論 1 320
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡缨睡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,775評(píng)論 3 343
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了陈辱。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片奖年。...
    茶點(diǎn)故事閱讀 40,926評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖沛贪,靈堂內(nèi)的尸體忽然破棺而出陋守,到底是詐尸還是另有隱情,我是刑警寧澤利赋,帶...
    沈念sama閱讀 36,580評(píng)論 5 351
  • 正文 年R本政府宣布水评,位于F島的核電站,受9級(jí)特大地震影響媚送,放射性物質(zhì)發(fā)生泄漏中燥。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,259評(píng)論 3 336
  • 文/蒙蒙 一塘偎、第九天 我趴在偏房一處隱蔽的房頂上張望疗涉。 院中可真熱鬧拿霉,春花似錦、人聲如沸咱扣。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,750評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)闹伪。三九已至沪铭,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間偏瓤,已是汗流浹背伦意。 一陣腳步聲響...
    開封第一講書人閱讀 33,867評(píng)論 1 274
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留硼补,地道東北人驮肉。 一個(gè)月前我還...
    沈念sama閱讀 49,368評(píng)論 3 379
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像已骇,于是被迫代替她去往敵國(guó)和親离钝。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,930評(píng)論 2 361