《分布式數(shù)據(jù)庫系統(tǒng)原理》第一章 讀書筆記

引言

分布式數(shù)據(jù)庫系統(tǒng)(DDBS)概述

  • 結合了數(shù)據(jù)庫系統(tǒng)(database system)和計算機網(wǎng)絡(computer network)技術

  • 達到為對于數(shù)據(jù)的集中定義和集中管理的目的

  • 帶來了數(shù)據(jù)獨立性(data independence)
    分布式數(shù)據(jù)庫系統(tǒng)中數(shù)據(jù)庫系統(tǒng)技術計算機網(wǎng)絡技術兩者是否矛盾月弛?

  • 兩者各自強調(diào)什么滑凉?

    • 數(shù)據(jù)庫系統(tǒng)強調(diào)提供集中的、對于數(shù)據(jù)可控制的存取

    • 計算機網(wǎng)絡技術強調(diào)反對集中的工作模式

  • 將兩者結合的重要思想:

    • 數(shù)據(jù)庫技術最重要的目標是集成而不是集中

    • 集成和集中是兩個不同概念截粗,必要時會為了集成而放棄集中

分布式數(shù)據(jù)處理

本書中關于分布式處理的定義:

  • 使用的分布式計算系統(tǒng)(distributed computing system)的定義印蔗,要求它具備一定數(shù)量的自主式處理單元不一定同構),這些單元通過計算機網(wǎng)絡互連贤重,并且協(xié)同處理它們各自分配到的任務漾肮。

    • 這里的"處理單元"是指能夠執(zhí)行自己程序的計算裝置

根據(jù)什么分布?

  • 處理邏輯分布

  • 功能分布

    • 計算機系統(tǒng)的不同功能可以分派到不同的硬件或軟件部件上
  • 數(shù)據(jù)分布

    • 應用所使用的數(shù)據(jù)可以分派到若干處理站點上
  • 控制分布

    • 不同任務的控制執(zhí)行也可以分布灸眼,而不是由一個計算機系統(tǒng)完成卧檐。從分布式數(shù)據(jù)庫系統(tǒng)的觀點看,所有這些方式都是必要和重要的

為什么需要分布幢炸?

  • 使用一種分而治之的辦法應對今天所面臨的大規(guī)模數(shù)據(jù)管理問題

  • 把復雜的問題分割成更小的部分并把它們分配到不同的軟件群加以解決

  • 這些軟件群工作在不同的計算機上泄隔,它們形成一個系統(tǒng),運行在多個處理單元上宛徊,有效工作,完成一件共同的任務

什么是分布式數(shù)據(jù)庫系統(tǒng)逻澳?

分布式數(shù)據(jù)庫定義:

  • 一群分布在計算機網(wǎng)絡上闸天、邏輯上互相關聯(lián)的數(shù)據(jù)庫

數(shù)據(jù)發(fā)送的不同選擇

數(shù)據(jù)發(fā)送的不同選擇:

  • 發(fā)送方式 delivery mode

  • 頻率 frequence

  • 通信方法 communication methods

發(fā)送方式:

  • 內(nèi)拉(pull-only)

    • 由客戶端的發(fā)起請求,從服務器端拉取數(shù)據(jù)

    • 特點

      • 新數(shù)據(jù)到達或已有數(shù)據(jù)的更新不會通知客戶
  • 外推(push-only)

    • 由服務器發(fā)起斜做,將數(shù)據(jù)推送給客戶端
  • 混合(hybrid)

    • 把客戶端的內(nèi)拉和服務器端的外推結合起來

    • 實現(xiàn):

      • 連續(xù)查詢

        • 起初由客戶端發(fā)起內(nèi)拉

        • 而后服務器端將更新的數(shù)據(jù)外推給客戶端

數(shù)據(jù)發(fā)送規(guī)律的頻率有三種典型的度量

  • 有周期(periodic)

    • 服務器端按照一定的時間間隔將數(shù)據(jù)推送給客戶端

    • 外推苞氮、內(nèi)拉都能定義為周期性的方式

  • 有條件(conditional)

    • 數(shù)據(jù)按照定義的條件發(fā)送,而不是重復的發(fā)送

    • 例子:

      • 僅當變化時才發(fā)送股票價格就是一個典型的有條件外推
  • 憑經(jīng)驗(ad-hoc)或不規(guī)則(irregular)

    • 憑經(jīng)驗的發(fā)送是不規(guī)則的瓤逼,且在大部分情況下是在基于內(nèi)拉式的系統(tǒng)里執(zhí)行

通信方法

指服務器和客戶端的對應關系笼吟,可以分為:

  • 單播(unicast)

    • 客戶和服務器之間的通信是一對一的:服務器按照某種頻率,采用特定的發(fā)送方式霸旗,僅把數(shù)據(jù)發(fā)送給一個客戶
  • 一對多(one-to-many)

    • 在一對多的情況下贷帮,如同它的名稱所說的那樣,服務器向許多客戶發(fā)出數(shù)據(jù)

      • 請注意诱告,我們這里沒有指定任何協(xié)議撵枢。一對多的通信可以使用多播或者廣播協(xié)議

DDBS的承諾

DDBS的四個基礎問題

  1. 分布及復制數(shù)據(jù)的透明管理

  2. 分布式事務提供可靠的數(shù)據(jù)存取

  3. 改進的性能

  4. 更為容易的系統(tǒng)擴展

分布及復制數(shù)據(jù)的透明管理

透明的含義

將系統(tǒng)的高層語義和底層的實現(xiàn)相分離。

  • 向用戶"隱藏"了系統(tǒng)實現(xiàn)的細節(jié)

  • 透明在這里可以理解為隱藏實現(xiàn)細節(jié)精居,以下各種名詞+透明锄禽,核心意思就是向用戶隱藏對應的名詞實現(xiàn)細節(jié)

為了讓分布式系統(tǒng)能夠處理分布、分片靴姿、復制的數(shù)據(jù)查詢需要應對幾種不同類型透明

  1. 數(shù)據(jù)獨立性

指用戶應用不會受到數(shù)據(jù)的定義的變化影響

  • 數(shù)據(jù)定義的兩個維度

    • 邏輯結構 通常稱為模式定義(schema definition)

    • 物理結構 通常稱為物理數(shù)據(jù)描述(physical data description)

  • 所以為了保證數(shù)據(jù)定義的透明沃但,就要保證數(shù)據(jù)的獨立性,按照數(shù)據(jù)定義的維度保證對應兩者的獨立性

    • 邏輯數(shù)據(jù)獨立性(logical data independence)

      • 是說用戶應用不受數(shù)據(jù)庫的邏輯結構(例如模式)變化的影響佛吓。
    • 物理數(shù)據(jù)獨立性(physical data independence)

      • 向用戶應用隱蔽了存儲結構的細節(jié)宵晚。當編寫用戶應用時垂攘,不會涉及物理存儲結構的細節(jié)
  1. 網(wǎng)絡透明(network transparency)或分布透明(distribution transparency)

用戶應當免于關心網(wǎng)絡的細節(jié),甚至可能不必關心網(wǎng)絡的存在坝疼,從DBMS的角度來說搜贤,分布透明要求用戶不必指出數(shù)據(jù)在哪里存放

分布透明除了指網(wǎng)絡,還有另外兩種透明:

  • 位置透明(location transparency)是指這樣的事實:

    • 用來執(zhí)行任務的命令既和數(shù)據(jù)的位置無關钝凶,也和由哪個系統(tǒng)完成無關
  • 命名透明(naming transparency)是指:

    • 對于數(shù)據(jù)庫里的每個對象都提供一個唯一的名字仪芒。如果沒有命名透明,用戶需要把位置名稱(或一個標識符)放入對象名稱內(nèi)
  1. 復制透明

復制

  • 這里指分布式系統(tǒng)中數(shù)據(jù)的復制耕陷,即副本的概念

數(shù)據(jù)復制透明

  • 即是否向用戶隱藏副本的存在掂名,而不是副本的位置,副本位置屬于網(wǎng)絡透明范疇
  1. 分片透明

分片的兩種方式:

  • 水平分片(horizontal fragmentation)

    • 按照行拆分
  • 垂直分片(vertical fragmentation)

    • 按照列拆分

怎么理解分片透明

將數(shù)據(jù)分片后哟沫,對于用戶端的查詢是基于原先完整關系上的查詢饺蔑,而在DDBS中需要轉換這種查詢,將最初關系查詢轉換成基于分片后的查詢

分布式事務提供的可靠性

事務(transaction)是一個一致和可靠計算的基本單元嗜诀,由作為原子單元執(zhí)行的一系列數(shù)據(jù)庫操作組成猾警。

事務的核心就是保證數(shù)據(jù)的一致性

  • 即使是在多個事務并發(fā)執(zhí)行(有時稱為并發(fā)透明(concurrency transparency))的情況下,在發(fā)生故障的情況下也可以把數(shù)據(jù)庫從一個一致的狀態(tài)轉變到另一個一致的狀態(tài)(也稱為故障原子性(failure atomicity))

  • 提供完全事務支持的DBMS即使是而臨系統(tǒng)故障隆敢,只要事務是正確的发皿,即遵守為數(shù)據(jù)庫所聲明的完整性規(guī)則,也可以保證用戶并發(fā)事務的執(zhí)行不會違反數(shù)據(jù)庫的一致性

改進的性能

分布式數(shù)據(jù)庫性能的改進來源于兩點:

  • 本地化(localization)

    • 這就帶來了兩個潛在的好處:

      • 由于每個站點僅僅處理數(shù)據(jù)庫的一小部分拂蝎,對CPU和I/O的服務競爭不會有集中式數(shù)據(jù)庫那樣激烈穴墅。

      • 本地化減少了通常由廣域網(wǎng)帶來的遠程訪問的延時(例如,在基于衛(wèi)星的系統(tǒng)中温自,最小的雙向消息傳播的時間大約為1秒)玄货。

    • 大多數(shù)分布式DBMS按照從數(shù)據(jù)本地化中獲得最大利益的思路來構造。

      • 減少競爭和減少通信額外開銷的完全好處只有通過數(shù)據(jù)的正確劃分和數(shù)據(jù)庫的分布才能取得悼泌。
  • 查詢之間的和查詢內(nèi)的并行化

    • 查詢之間的并行化

      • 來自于同時執(zhí)行多個查詢的能力
    • 查詢內(nèi)的并行

      • 是通過把單個查詢分解成若干個子查詢松捉,讓每個子查詢在不同的站點上執(zhí)行,訪問分布式數(shù)據(jù)庫的不同部分券躁。

更為容易的系統(tǒng)擴展

分布式環(huán)境更為容易適應不斷增長的數(shù)據(jù)規(guī)模惩坑。主要的系統(tǒng)變更很少發(fā)生,通過增加處理和存儲的能力即可做到系統(tǒng)擴展也拜。顯然以舒,不可能在能力上做到線性增長,這是由于分布產(chǎn)生的額外開銷的緣故慢哈。但是蔓钟,獲得能力上顯著的提高還是完全可以的。

分布帶來的復雜性

分布式環(huán)境下復雜性主要受到了三方面的影響:

  • 數(shù)據(jù)可以在分布的環(huán)境里復制卵贱。

    • 分布式數(shù)據(jù)可以設計成部分或全部的數(shù)據(jù)庫復制在計算機網(wǎng)絡的每個站點上滥沫。網(wǎng)絡的每個站點包含一個數(shù)據(jù)庫并不重要侣集,重要的問題是數(shù)據(jù)庫駐留在不止一個站點上。

    • 復制數(shù)據(jù)項的出發(fā)點是可靠性和性能的考慮兰绣,因此分布式數(shù)據(jù)庫系統(tǒng)要負責:

      • 選擇一個副本來響應搜索

      • 保證數(shù)據(jù)項的每個副本都會得到有效的更新世分。

  • 故障恢復

    • 如果正在更新時某些站點出現(xiàn)故障(例如,硬件或軟件的功能出現(xiàn)問題)缀辩,或者是通信故障(從而使得某些站點失去聯(lián)系)臭埋。在這種情況下,系統(tǒng)必須確保在故障恢復時將更新的效果反映到出現(xiàn)故障的站點或當時無法聯(lián)系的站點上臀玄。
  • 分布式環(huán)境中的事務同步

    • 因為每個站點不可能隨時知道其他站點上正在進行的操作瓢阴,這就使得多站點上的事務同步比集中式系統(tǒng)要困難得多

設 計 問 題

分布式數(shù)據(jù)庫設計

即如何將數(shù)據(jù)庫放置到分散的站點上

對于數(shù)據(jù)的放置存在兩種不同的選擇:

  • 劃分(partitioned)(或無重復(non-replicated))

    • 在劃分的方案下健无,數(shù)據(jù)被劃分成不同片段荣恐,分別存放在不同的節(jié)點上,每個節(jié)點上存放數(shù)據(jù)均不同
  • 重復(replicated)

    • 不同節(jié)點可以存放相同數(shù)據(jù)

分布式目錄管理

和數(shù)據(jù)放置問題相似累贤,目錄可以集中一個節(jié)點叠穆,可以分布在幾個節(jié)點

分布式查詢處理

這里涉及兩個算法:

  • 對查詢進行分析的算法

  • 將查詢轉換為數(shù)據(jù)操作的算法

這里的主要問題是當給出了代價的定義之后,如何確定在網(wǎng)絡上執(zhí)行每個查詢的策略:

分布式并發(fā)控制

并發(fā)控制不僅要考慮單個數(shù)據(jù)庫的完整性臼膏,而且還要考慮數(shù)據(jù)庫多個副本的一致性痹束。需要每個數(shù)據(jù)項的多個副本的值趨于一致的條件稱為相互一致性(mutual consistency)。

這一問題的解決方案太多太多讶请,總體上講存在兩大類通用的方法

  • 悲觀(pessimistic)方法

    • 在執(zhí)行用戶請求開始之前首先同步這些請求。
  • 樂觀(optimistic)方法

    • 首先執(zhí)行用戶請求屎媳,然后再檢查是否違反了數(shù)據(jù)庫的一致性夺溢。

    • 有兩個基本元語可供這兩種方法所使用。

      • 第一個基本元語是加鎖(locking)烛谊,它建立在對所訪問的數(shù)據(jù)的相互排斥的基礎之上风响。

      • 第二個元語是加時間戳(timestamping),它按照時間戳的順序執(zhí)行事務丹禀。

分布式死鎖管理

如果同步機制使用的是加鎖的方法,訪問同一組資源(即數(shù)據(jù))的用戶之間的競爭會導致死鎖状勤。

分布式數(shù)據(jù)庫的可靠性

我們必須提供一些機制來保證數(shù)據(jù)庫一致性,以及故障恢復双泪。

  • 一致性

    • 對分布式數(shù)據(jù)庫而言持搜,當發(fā)生故障導致不同的站點或者是停止運行,或者是不可訪問時焙矛,正常運行的站點上的數(shù)據(jù)庫仍然保持在一致和最新的狀態(tài)
  • 故障恢復

    • 當計算機系統(tǒng)或網(wǎng)絡從故障中恢復時葫盼,DDBMS應當能夠恢復,并且必須將故障站點的數(shù)據(jù)庫帶入到最新的狀態(tài)村斟。

      • 在出現(xiàn)網(wǎng)絡劃分的情況時贫导,這可能非常困難抛猫。因為站點被劃分成兩個或更多的小組,在這些小組之間無法通信孩灯。分布式可靠性協(xié)議是第12章的主題闺金。

復制

如果分布式數(shù)據(jù)庫是(部分或全部)復制的叉谜,則必須執(zhí)行保證副本一致性的協(xié)議羞延,即同一個數(shù)據(jù)項的拷貝要具有相同的值赂摆。

  • 副本一致性協(xié)議的兩種方式

    • 即時(eager)的赡突,即在事務完成之前強迫執(zhí)行一致性協(xié)議杨幼;

    • 惰性(lazy)的莲趣,即事務只更新一個拷貝(稱為主拷貝(master)扎酷,而在事務完成之后再把更新傳播給其他拷貝馒闷。第13章將討論復制協(xié)議尚卫。

問題之間的相互關系

自然归榕,這些問題不是互相孤立的。每個問題受到其他問題的影響吱涉,直至影響到解決這些問題的可行的方法刹泄,這正是本節(jié)所要討論的內(nèi)容。

分布式DBMS體系架構

本節(jié)為分布式數(shù)據(jù)庫DBMS給出三個參考體系架構

  • 客戶/服務器系統(tǒng)

  • P2P分布式DBMS

  • 多數(shù)據(jù)庫系統(tǒng)怎爵。

ANSI/SPARC體系架構

1.png

圖中有三種數(shù)據(jù)視圖:

  • 外部視圖(external view)特石,即終端用戶例如程序員所見到的視圖;

  • 內(nèi)部視圖(internal view)鳖链,即系統(tǒng)或機器所見的視圖姆蘸;

  • 概念視圖(conceptual view),即企業(yè)所見的視圖芙委。

這一體系架構的最底層是內(nèi)部視圖

  • 它處理數(shù)據(jù)的物理定義和組織逞敷。數(shù)據(jù)的位置以及不同的存儲設備,為了獲得并操縱數(shù)據(jù)所使用的機制等問題是這一層必須要考慮的灌侣。

另一個極端是

  • 外部視圖推捐,主要與用戶如何看待數(shù)據(jù)庫有關。個別用戶的視圖代表的是該用戶所存取的那部分數(shù)據(jù)侧啼,以及用戶看到的數(shù)據(jù)之間的關系牛柒。多個用戶可以共享同一個視圖,這些用戶的視圖構成了一個外部模式痊乾。

集中式DBMS的通用體系架構

DBMS是一個可由多個進程(事務(transaction))組成的程序皮壁,而這些進程又運行它們自己的數(shù)據(jù)庫程序。

DBMS要和另外兩個部件交互

  • 通信子系統(tǒng)

    • 通信子系統(tǒng)支持DBMS和其他子系統(tǒng)交互符喝,實現(xiàn)和應用之間的聯(lián)絡闪彼。

      • 例如,終端監(jiān)視器需要和DBMS聯(lián)絡以便運行交互式事務。
  • 操作系統(tǒng)畏腕。

    • 操作系統(tǒng)提供了 DBMS和計算機資源(處理器缴川、內(nèi)存、磁盤驅動器等等)之間的接口描馅。

集中式DBMS的功能層

40A5FD8A-59E2-49C7-A141-774D888934F6.png

圖中的箭頭指出了數(shù)據(jù)和控制流的方向把夸。自頂向下來看,這些層分別是界面铭污、控制恋日、編譯、執(zhí)行嘹狞、數(shù)據(jù)訪問以及一致性管理岂膳。

  • 界面層(interface layer)

    • 管理和應用交互的界面。
  • 控制層(control layer)

    • 通過在查詢中加入語義完整性謂詞授權謂詞完成對查詢的控制磅网。

    • 而這種語義完整性的限制授權是由說明性語言所定義的谈截,這會在第5章進行討論。

    • 這一層的輸出是用高級語言加以豐富的查詢涧偷。

  • 查詢處理層(query processing)(或編譯(compilation))

    • 把查詢映射成優(yōu)化后的低層操作的序列簸喂。

    • 這一層與性能有關,它把查詢分解成代數(shù)操作的樹結構并試圖尋找操作的“最優(yōu)”順序燎潮,它的結果保存在訪問計劃里喻鳄。

    • 這一層的輸出是底層代碼(代數(shù)操作)表示的查詢。

  • 執(zhí)行層(execution layer)

    • 指揮訪問計劃的執(zhí)行确封,包括事務管理(提交除呵,重做)以及代數(shù)操作的同步

    • 它通過調(diào)用數(shù)據(jù)訪問層的檢索和更新請求來解釋關系代數(shù)爪喘。

  • 數(shù)據(jù)訪問層(data access layer)

    • 管理實現(xiàn)文件索引的數(shù)據(jù)結構竿奏。

    • 它也管理緩沖區(qū)對最經(jīng)常訪問的數(shù)據(jù)進行快速緩存腥放。

    • 對于這一層的精心使用可以把對磁盤數(shù)據(jù)的讀寫降到最低。

  • 一致層(consistency layer)

    • 對并發(fā)控制進行管理绿语,同時記錄更新請求的日志秃症。

    • 這一層支持事務、系統(tǒng)吕粹、介質(zhì)的故障恢復种柑。

分布式DBMS體系架構的模型

DBMS的不同實現(xiàn)方式

ABECCFEA-D5FB-4083-B419-8EAA7FB3B41D.png

構造分布式DBMS有多種方法,該圖從以下幾個方面對系統(tǒng)進行刻畫:

  • 本地系統(tǒng)的自治性(Autonomy)匹耕;

  • 系統(tǒng)的分布(Distribution)聚请;

  • 系統(tǒng)的異構(Heterogeneity)。

自治性

這里所說的自治性(autonomy)是指對控制的分配,而不是數(shù)據(jù)的分配驶赏,它告訴我們在多大程度上每個單獨的DBMS能夠獨立地運行炸卑。

自治性可以這樣來加以說明【Du and Elmagarmid,1989】:

  • 設計自治:

    • 每個單獨的DBMS可以自由地選擇數(shù)據(jù)模型事務處理技術
  • 通信自治:

    • 每個單獨的DBMS可以自由地決定什么樣的信息可以提供給其他DBMS
  • 執(zhí)行自治:

    • 能夠用它自己的方式執(zhí)行提交事務

讓我們來看看如何使用這些特征來對DBMS進行分類:

  • 緊密集成(tight integration)煤傍,

    • 在多個數(shù)據(jù)管理程序中盖文,有一個管理程序負責對每一個用戶的請求處理進行控制,即使這個請求需要用到多個數(shù)據(jù)管理程序所提供的服務的情況下也是如此蚯姆。

    • 這種情況下五续,數(shù)據(jù)管理程序通常不會作為一個獨立的DBMS來運行。

  • 半自治系統(tǒng)(semiautonomous)

    • 它由獨立運行的DBMS組成龄恋,但是它們必須要加入一個聯(lián)盟才能實現(xiàn)本地數(shù)據(jù)的共享

    • 每一個這樣的DBMS要決定它擁有的數(shù)據(jù)的哪個部分可供其他DBMS使用疙驾。

    • 它們還不是全自治的系統(tǒng),因為對它們必須進行修改才能實現(xiàn)彼此間的信息交換.

  • 全孤立(total isolation)系統(tǒng)

    • 在這樣的系統(tǒng)里郭毕,每個DBMS都是獨立存在的它碎,它們既不知道其他DBMS的存在,也不知道如何和它們通信

    • 此時,涉及多個數(shù)據(jù)庫的用戶事務處理特別困雄铣卡,因為系統(tǒng)內(nèi)不存在對于個別DBMS執(zhí)行所施加的全局控制.

分布

前面討論的自治指的是對于控制的分配(或分散)链韭,而下面要討論的分布則指的是如何處理數(shù)據(jù)的間題。

對于DBMS,已經(jīng)有了幾種不同的分布方式.可把它們抽象為

  • 客戶/服務器(client/server)分布

    • 數(shù)據(jù)管理的任務集中在服務器端

    • 而客戶端則集中于提供包括用戶界面在內(nèi)的應用環(huán)境

    • 通信的任務則由客戶和服務器共同承擔

  • P2P(peer-to-peer)分布

    • 在P2P系統(tǒng)(peer-tbpeer systems)里不存在客戶端和服務器端機器這樣的差別

    • 每臺機器具備完整的DBMS功能煮落,同時可以和其他機器通信以完成査詢和事務的執(zhí)行

異構性

在本書中和這個問題較為密切的是

  • 數(shù)據(jù)模型

    • 用不同的建模工具表示數(shù)據(jù)就會產(chǎn)生異構敞峭,這是由各個數(shù)據(jù)模型先天的表達能力和局限性所造成的。
  • 查詢語言

    • 查詢語言方面的異構不僅與不同的模型采用完全不同的數(shù)據(jù)訪問的方式有關(從關系系統(tǒng)的一次一個集合蝉仇,到某些面向對象系統(tǒng)的一次一個紀錄)旋讹,而且還涉及語言的不同,即便是使用同一個模型也仍然會出現(xiàn)這個問題轿衔。

    • 雖然SQL現(xiàn)在是標準的關系查詢語言沉迹,但是對它的實現(xiàn)不盡相同,而每個商家的語言則會帶著略有不同的風格(有時甚至不同的語義害驹,從而產(chǎn)生不同的結果)鞭呕。

  • 事務管理的協(xié)議。

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末宛官,一起剝皮案震驚了整個濱河市葫松,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌底洗,老刑警劉巖腋么,帶你破解...
    沈念sama閱讀 206,482評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異亥揖,居然都是意外死亡珊擂,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,377評論 2 382
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來摧扇,“玉大人圣贸,你說我怎么就攤上這事“饨耍” “怎么了旁趟?”我有些...
    開封第一講書人閱讀 152,762評論 0 342
  • 文/不壞的土叔 我叫張陵,是天一觀的道長庇绽。 經(jīng)常有香客問我锡搜,道長,這世上最難降的妖魔是什么瞧掺? 我笑而不...
    開封第一講書人閱讀 55,273評論 1 279
  • 正文 為了忘掉前任耕餐,我火速辦了婚禮,結果婚禮上辟狈,老公的妹妹穿的比我還像新娘肠缔。我一直安慰自己,他們只是感情好哼转,可當我...
    茶點故事閱讀 64,289評論 5 373
  • 文/花漫 我一把揭開白布明未。 她就那樣靜靜地躺著,像睡著了一般壹蔓。 火紅的嫁衣襯著肌膚如雪趟妥。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,046評論 1 285
  • 那天佣蓉,我揣著相機與錄音披摄,去河邊找鬼。 笑死勇凭,一個胖子當著我的面吹牛疚膊,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播虾标,決...
    沈念sama閱讀 38,351評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼寓盗,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了璧函?” 一聲冷哼從身側響起贞让,我...
    開封第一講書人閱讀 36,988評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎柳譬,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體续镇,經(jīng)...
    沈念sama閱讀 43,476評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡美澳,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,948評論 2 324
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片制跟。...
    茶點故事閱讀 38,064評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡舅桩,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出雨膨,到底是詐尸還是另有隱情擂涛,我是刑警寧澤,帶...
    沈念sama閱讀 33,712評論 4 323
  • 正文 年R本政府宣布聊记,位于F島的核電站撒妈,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏排监。R本人自食惡果不足惜狰右,卻給世界環(huán)境...
    茶點故事閱讀 39,261評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望舆床。 院中可真熱鬧棋蚌,春花似錦、人聲如沸挨队。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,264評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽盛垦。三九已至湿弦,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間情臭,已是汗流浹背省撑。 一陣腳步聲響...
    開封第一講書人閱讀 31,486評論 1 262
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留俯在,地道東北人竟秫。 一個月前我還...
    沈念sama閱讀 45,511評論 2 354
  • 正文 我出身青樓,卻偏偏與公主長得像跷乐,于是被迫代替她去往敵國和親肥败。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 42,802評論 2 345