2020Kafka最新最全面試題!

1灭衷、請(qǐng)說(shuō)明什么是Apache Kafka?

Apache Kafka是由Apache開發(fā)的一種發(fā)布訂閱消息系統(tǒng)次慢,它是一個(gè)分布式的、分區(qū)的和可復(fù)制的提交日志服務(wù)翔曲。

2迫像、說(shuō)說(shuō)Kafka的使用場(chǎng)景?

①異步處理

②應(yīng)用解耦

③流量削峰

④日志處理

⑤消息通訊等瞳遍。

3闻妓、使用Kafka有什么優(yōu)點(diǎn)和缺點(diǎn)?

優(yōu)點(diǎn):

①支持跨數(shù)據(jù)中心的消息復(fù)制掠械;

②單機(jī)吞吐量:十萬(wàn)級(jí)由缆,最大的優(yōu)點(diǎn)注祖,就是吞吐量高;

③topic數(shù)量都吞吐量的影響:topic從幾十個(gè)到幾百個(gè)的時(shí)候,吞吐量會(huì)大幅度下降均唉。所以在同等機(jī)器下是晨,kafka盡量保證topic數(shù)量不要過(guò)多。如果要支撐大規(guī)模topic舔箭,需要增加更多的機(jī)器資源;

④時(shí)效性:ms級(jí);

⑤可用性:非常高罩缴,kafka是分布式的,一個(gè)數(shù)據(jù)多個(gè)副本层扶,少數(shù)機(jī)器宕機(jī)箫章,不會(huì)丟失數(shù)據(jù),不會(huì)導(dǎo)致不可用;

⑥消息可靠性:經(jīng)過(guò)參數(shù)優(yōu)化配置镜会,消息可以做到0丟失;

⑦功能支持:功能較為簡(jiǎn)單檬寂,主要支持簡(jiǎn)單的MQ功能,在大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算以及日志采集被大規(guī)模使用戳表。

缺點(diǎn):

①由于是批量發(fā)送桶至,數(shù)據(jù)并非真正的實(shí)時(shí); 僅支持統(tǒng)一分區(qū)內(nèi)消息有序扒袖,無(wú)法實(shí)現(xiàn)全局消息有序塞茅;

②有可能消息重復(fù)消費(fèi);

③依賴zookeeper進(jìn)行元數(shù)據(jù)管理季率,等等野瘦。

4、為什么說(shuō)Kafka性能很好飒泻,體現(xiàn)在哪里鞭光?

①順序讀寫

②零拷貝

③分區(qū)

④批量發(fā)送

⑤數(shù)據(jù)壓縮

5、請(qǐng)說(shuō)明什么是傳統(tǒng)的消息傳遞方法?

傳統(tǒng)的消息傳遞方法包括兩種:

排隊(duì):在隊(duì)列中泞遗,一組用戶可以從服務(wù)器中讀取消息惰许,每條消息都發(fā)送給其中一個(gè)人。

發(fā)布-訂閱:在這個(gè)模型中史辙,消息被廣播給所有的用戶汹买。

6、請(qǐng)說(shuō)明Kafka相對(duì)傳統(tǒng)技術(shù)有什么優(yōu)勢(shì)?

①快速:單一的Kafka代理可以處理成千上萬(wàn)的客戶端聊倔,每秒處理數(shù)兆字節(jié)的讀寫操作晦毙。

②可伸縮:在一組機(jī)器上對(duì)數(shù)據(jù)進(jìn)行分區(qū)

③和簡(jiǎn)化,以支持更大的數(shù)據(jù)

④持久:消息是持久性的耙蔑,并在集群中進(jìn)

⑤行復(fù)制见妒,以防止數(shù)據(jù)丟失。

⑥設(shè)計(jì):它提供了容錯(cuò)保證和持久性

7甸陌、解釋Kafka的Zookeeper是什么?我們可以在沒有Zookeeper的情況下使用Kafka嗎?

Zookeeper是一個(gè)開放源碼的须揣、高性能的協(xié)調(diào)服務(wù)盐股,它用于Kafka的分布式應(yīng)用。

不耻卡,不可能越過(guò)Zookeeper疯汁,直接聯(lián)系Kafka broker。一旦Zookeeper停止工作卵酪,它就不能服務(wù)客戶端請(qǐng)求涛目。

Zookeeper主要用于在集群中不同節(jié)點(diǎn)之間進(jìn)行通信

在Kafka中,它被用于提交偏移量凛澎,因此如果節(jié)點(diǎn)在任何情況下都失敗了,它都可以從之前提交的偏移量中獲取

除此之外估蹄,它還執(zhí)行其他活動(dòng)塑煎,如: leader檢測(cè)、分布式同步臭蚁、配置管理最铁、識(shí)別新節(jié)點(diǎn)何時(shí)離開或連接、集群垮兑、節(jié)點(diǎn)實(shí)時(shí)狀態(tài)等等冷尉。

8、解釋Kafka的用戶如何消費(fèi)信息?

在Kafka中傳遞消息是通過(guò)使用sendfile API完成的系枪。它支持將字節(jié)從套接口轉(zhuǎn)移到磁盤,通過(guò)內(nèi)核空間保存副本,并在內(nèi)核用戶之間調(diào)用內(nèi)核骏掀。

9斗躏、解釋如何提高遠(yuǎn)程用戶的吞吐量?

如果用戶位于與broker不同的數(shù)據(jù)中心,則可能需要調(diào)優(yōu)套接口緩沖區(qū)大小衬浑,以對(duì)長(zhǎng)網(wǎng)絡(luò)延遲進(jìn)行攤銷捌浩。

10、解釋一下工秩,在數(shù)據(jù)制作過(guò)程中尸饺,你如何能從Kafka得到準(zhǔn)確的信息?

在數(shù)據(jù)中,為了精確地獲得Kafka的消息助币,你必須遵循兩件事: 在數(shù)據(jù)消耗期間避免重復(fù)浪听,在數(shù)據(jù)生產(chǎn)過(guò)程中避免重復(fù)。

這里有兩種方法奠支,可以在數(shù)據(jù)生成時(shí)準(zhǔn)確地獲得一個(gè)語(yǔ)義:

每個(gè)分區(qū)使用一個(gè)單獨(dú)的寫入器馋辈,每當(dāng)你發(fā)現(xiàn)一個(gè)網(wǎng)絡(luò)錯(cuò)誤,檢查該分區(qū)中的最后一條消息倍谜,以查看您的最后一次寫入是否成功

在消息中包含一個(gè)主鍵(UUID或其他)迈螟,并在用戶中進(jìn)行反復(fù)制

11叉抡、解釋如何減少ISR中的擾動(dòng)?broker什么時(shí)候離開ISR?

ISR是一組與leaders完全同步的消息副本,也就是說(shuō)ISR中包含了所有提交的消息答毫。ISR應(yīng)該總是包含所有的副本褥民,直到出現(xiàn)真正的故障。如果一個(gè)副本從leader中脫離出來(lái)洗搂,將會(huì)從ISR中刪除消返。

12、Kafka為什么需要復(fù)制?

Kafka的信息復(fù)制確保了任何已發(fā)布的消息不會(huì)丟失耘拇,并且可以在機(jī)器錯(cuò)誤撵颊、程序錯(cuò)誤或更常見些的軟件升級(jí)中使用。

13惫叛、如果副本在ISR中停留了很長(zhǎng)時(shí)間表明什么?

如果一個(gè)副本在ISR中保留了很長(zhǎng)一段時(shí)間倡勇,那么它就表明,跟蹤器無(wú)法像在leader收集數(shù)據(jù)那樣快速地獲取數(shù)據(jù)嘉涌。

14妻熊、請(qǐng)說(shuō)明如果首選的副本不在ISR中會(huì)發(fā)生什么?

如果首選的副本不在ISR中,控制器將無(wú)法將leadership轉(zhuǎn)移到首選的副本仑最。

15扔役、有可能在生產(chǎn)后發(fā)生消息偏移嗎?

在大多數(shù)隊(duì)列系統(tǒng)中,作為生產(chǎn)者的類無(wú)法做到這一點(diǎn)警医,它的作用是觸發(fā)并忘記消息亿胸。broker將完成剩下的工作,比如使用id進(jìn)行適當(dāng)?shù)脑獢?shù)據(jù)處理预皇、偏移量等损敷。

作為消息的用戶,你可以從Kafka

broker中獲得補(bǔ)償深啤。如果你注視SimpleConsumer類拗馒,你會(huì)注意到它會(huì)獲取包括偏移量作為列表的MultiFetchResponse對(duì)象。此外溯街,當(dāng)你對(duì)Kafka消息進(jìn)行迭代時(shí)诱桂,你會(huì)擁有包括偏移量和消息發(fā)送的MessageAndOffset對(duì)象。

16呈昔、Kafka的設(shè)計(jì)時(shí)什么樣的呢挥等?

Kafka將消息以topic為單位進(jìn)行歸納

將向Kafka topic發(fā)布消息的程序成為producers. 將預(yù)訂topics并消費(fèi)消息的程序成為consumer.

Kafka以集群的方式運(yùn)行,可以由一個(gè)或多個(gè)服務(wù)組成堤尾,每個(gè)服務(wù)叫做一個(gè)broker.

producers通過(guò)網(wǎng)絡(luò)將消息發(fā)送到Kafka集群肝劲,集群向消費(fèi)者提供消息

17、數(shù)據(jù)傳輸?shù)氖挛锒x有哪三種?

(1)最多一次:

消息不會(huì)被重復(fù)發(fā)送辞槐,最多被傳輸一次掷漱,但也有可能一次不傳輸

(2)最少一次: 消息不會(huì)被漏發(fā)送,最少被傳輸一次榄檬,但也有可能被重復(fù)傳輸.

(3)精確的一次(Exactly once): 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅僅被傳輸一次卜范,這是大家所期望的

18、Kafka判斷一個(gè)節(jié)點(diǎn)是否還活著有那兩個(gè)條件鹿榜?

(1)節(jié)點(diǎn)必須可以維護(hù)和ZooKeeper的連接海雪,Zookeeper通過(guò)心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連接

(2)如果節(jié)點(diǎn)是個(gè)follower,他必須能及時(shí)的同步leader的寫操作,延時(shí)不能太久

19舱殿、producer是否直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點(diǎn))奥裸?

producer直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點(diǎn)),不需要在多個(gè)節(jié)點(diǎn)進(jìn)行分發(fā)沪袭,為了幫助producer做到這點(diǎn)刺彩,所有的Kafka節(jié)點(diǎn)都可以及時(shí)的告知:哪些節(jié)點(diǎn)是活動(dòng)的,目標(biāo)topic目標(biāo)分區(qū)的leader在哪枝恋。這樣producer就可以直接將消息發(fā)送到目的地了。

20嗡害、Kafa consumer是否可以消費(fèi)指定分區(qū)消息焚碌?

Kafa

consumer消費(fèi)消息時(shí),向broker發(fā)出"fetch"請(qǐng)求去消費(fèi)特定分區(qū)的消息霸妹,consumer指定消息在日志中的偏移量(offset)十电,就可以消費(fèi)從這個(gè)位置開始的消息,customer擁有了offset的控制權(quán)叹螟,可以向后回滾去重新消費(fèi)之前的消息鹃骂,這是很有意義的

21、Kafka消息是采用Pull模式罢绽,還是Push模式畏线?

Kafka最初考慮的問(wèn)題是,customer應(yīng)該從brokes拉取消息還是brokers將消息推送到consumer良价,也就是pull還push寝殴。在這方面,Kafka遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計(jì):producer將消息推送到broker明垢,consumer從broker拉取消息一些消息系統(tǒng)比如Scribe和Apache

Flume采用了push模式蚣常,將消息推送到下游的consumer。這樣做有好處也有壞處:由broker決定消息推送的速率痊银,對(duì)于不同消費(fèi)速率的consumer就不太好處理了抵蚊。消息系統(tǒng)都致力于讓consumer以最大的速率最快速的消費(fèi)消息,但不幸的是,push模式下贞绳,當(dāng)broker推送的速率遠(yuǎn)大于consumer消費(fèi)的速率時(shí)谷醉,consumer恐怕就要崩潰了。最終Kafka還是選取了傳統(tǒng)的pull模式

Pull模式的另外一個(gè)好處是consumer可以自主決定是否批量的從broker拉取數(shù)據(jù)熔酷。Push模式必須在不知道下游consumer消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條消息還是緩存之后批量推送孤紧。如果為了避免consumer崩潰而采用較低的推送速率,將可能導(dǎo)致一次只推送較少的消息而造成浪費(fèi)拒秘。Pull模式下号显,consumer就可以根據(jù)自己的消費(fèi)能力去決定這些策略

Pull有個(gè)缺點(diǎn)是,如果broker沒有可供消費(fèi)的消息躺酒,將導(dǎo)致consumer不斷在循環(huán)中輪詢押蚤,直到新消息到t達(dá)。為了避免這點(diǎn)羹应,Kafka有個(gè)參數(shù)可以讓consumer阻塞知道新消息到達(dá)(當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)

22揽碘、Kafka存儲(chǔ)在硬盤上的消息格式是什么?

消息由一個(gè)固定長(zhǎng)度的頭部和可變長(zhǎng)度的字節(jié)數(shù)組組成园匹。頭部包含了一個(gè)版本號(hào)和CRC32校驗(yàn)碼雳刺。

?消息長(zhǎng)度: 4 bytes (value: 1+4+n)

?版本號(hào): 1 byte

?CRC校驗(yàn)碼: 4 bytes

?具體的消息: n bytes

23、Kafka高效文件存儲(chǔ)設(shè)計(jì)特點(diǎn):

(1).Kafka把topic中一個(gè)parition大文件分成多個(gè)小文件段裸违,通過(guò)多個(gè)小文件段掖桦,就容易定期清除或刪除已經(jīng)消費(fèi)完文件,減少磁盤占用供汛。

(2).通過(guò)索引信息可以快速定位message和確定response的最大大小枪汪。

(3).通過(guò)index元數(shù)據(jù)全部映射到memory,可以避免segment file的IO磁盤操作怔昨。

(4).通過(guò)索引文件稀疏存儲(chǔ)雀久,可以大幅降低index文件元數(shù)據(jù)占用空間大小。

24趁舀、Kafka 與傳統(tǒng)消息系統(tǒng)之間有三個(gè)關(guān)鍵區(qū)別

(1).Kafka 持久化日志赖捌,這些日志可以被重復(fù)讀取和無(wú)限期保留

(2).Kafka 是一個(gè)分布式系統(tǒng):它以集群的方式運(yùn)行,可以靈活伸縮矮烹,在內(nèi)部通過(guò)復(fù)制數(shù)據(jù)提升容錯(cuò)能力和高可用性

(3).Kafka 支持實(shí)時(shí)的流式處理

25巡蘸、Kafka創(chuàng)建Topic時(shí)如何將分區(qū)放置到不同的Broker中

?副本因子不能大于 Broker 的個(gè)數(shù);

?第一個(gè)分區(qū)(編號(hào)為0)的第一個(gè)副本放置位置是隨機(jī)從 brokerList 選擇的擂送;

?其他分區(qū)的第一個(gè)副本放置位置相對(duì)于第0個(gè)分區(qū)依次往后移悦荒。也就是如果我們有5個(gè)

Broker,5個(gè)分區(qū)嘹吨,假設(shè)第一個(gè)分區(qū)放在第四個(gè) Broker 上搬味,那么第二個(gè)分區(qū)將會(huì)放在第五個(gè) Broker 上;第三個(gè)分區(qū)將會(huì)放在第一個(gè)

Broker 上;第四個(gè)分區(qū)將會(huì)放在第二個(gè) Broker 上碰纬,依次類推萍聊;

?剩余的副本相對(duì)于第一個(gè)副本放置位置其實(shí)是由 nextReplicaShift 決定的,而這個(gè)數(shù)也是隨機(jī)產(chǎn)生的

26悦析、Kafka新建的分區(qū)會(huì)在哪個(gè)目錄下創(chuàng)建

在啟動(dòng)

Kafka 集群之前寿桨,我們需要配置好 log.dirs 參數(shù),其值是 Kafka

數(shù)據(jù)的存放目錄强戴,這個(gè)參數(shù)可以配置多個(gè)目錄亭螟,目錄之間使用逗號(hào)分隔,通常這些目錄是分布在不同的磁盤上用于提高讀寫性能骑歹。 當(dāng)然我們也可以配置

log.dir 參數(shù)预烙,含義一樣。只需要設(shè)置其中一個(gè)即可道媚。 如果 log.dirs 參數(shù)只配置了一個(gè)目錄扁掸,那么分配到各個(gè) Broker

上的分區(qū)肯定只能在這個(gè)目錄下創(chuàng)建文件夾用于存放數(shù)據(jù)。 但是如果 log.dirs 參數(shù)配置了多個(gè)目錄最域,那么 Kafka

會(huì)在哪個(gè)文件夾中創(chuàng)建分區(qū)目錄呢谴分?答案是:Kafka 會(huì)在含有分區(qū)目錄最少的文件夾中創(chuàng)建新的分區(qū)目錄,分區(qū)目錄名為

Topic名+分區(qū)ID镀脂。注意牺蹄,是分區(qū)文件夾總數(shù)最少的目錄,而不是磁盤使用量最少的目錄狗热!也就是說(shuō),如果你給 log.dirs

參數(shù)新增了一個(gè)新的磁盤虑省,新的分區(qū)目錄肯定是先在這個(gè)新的磁盤上創(chuàng)建直到這個(gè)新的磁盤目錄擁有的分區(qū)目錄不是最少為止匿刮。

27、partition的數(shù)據(jù)如何保存到硬盤

topic中的多個(gè)partition以文件夾的形式保存到broker探颈,每個(gè)分區(qū)序號(hào)從0遞增熟丸,

且消息有序 Partition文件下有多個(gè)segment(xxx.index,xxx.log) segment 文件里的

大小和配置文件大小一致可以根據(jù)要求修改 默認(rèn)為1g

如果大小大于1g時(shí)伪节,會(huì)滾動(dòng)一個(gè)新的segment并且以上一個(gè)segment最后一條消息的偏移量命名

28光羞、kafka的ack機(jī)制

request.required.acks有三個(gè)值 0 1 -1

0:生產(chǎn)者不會(huì)等待broker的ack,這個(gè)延遲最低但是存儲(chǔ)的保證最弱當(dāng)server掛掉的時(shí)候就會(huì)丟數(shù)據(jù)

1:服務(wù)端會(huì)等待ack值 leader副本確認(rèn)接收到消息后發(fā)送ack但是如果leader掛掉后他不確保是否復(fù)制完成新leader也會(huì)導(dǎo)致數(shù)據(jù)丟失

-1:同樣在1的基礎(chǔ)上 服務(wù)端會(huì)等所有的follower的副本受到數(shù)據(jù)后才會(huì)受到leader發(fā)出的ack怀大,這樣數(shù)據(jù)不會(huì)丟失

29纱兑、Kafka的消費(fèi)者如何消費(fèi)數(shù)據(jù)

消費(fèi)者每次消費(fèi)數(shù)據(jù)的時(shí)候,消費(fèi)者都會(huì)記錄消費(fèi)的物理偏移量(offset)的位置 等到下次消費(fèi)時(shí)化借,他會(huì)接著上次位置繼續(xù)消費(fèi)潜慎。同時(shí)也可以按照指定的offset進(jìn)行重新消費(fèi)。

30、消費(fèi)者負(fù)載均衡策略

結(jié)合consumer的加入和退出進(jìn)行再平衡策略铐炫。

31垒手、kafka消息數(shù)據(jù)是否有序?

消費(fèi)者組里某具體分區(qū)是有序的倒信,所以要保證有序只能建一個(gè)分區(qū)科贬,但是實(shí)際這樣會(huì)存在性能問(wèn)題,具體業(yè)務(wù)具體分析后確認(rèn)鳖悠。

32榜掌、kafaka生產(chǎn)數(shù)據(jù)時(shí)數(shù)據(jù)的分組策略,生產(chǎn)者決定數(shù)據(jù)產(chǎn)生到集群的哪個(gè)partition中

每一條消息都是以(key,value)格式 Key是由生產(chǎn)者發(fā)送數(shù)據(jù)傳入 所以生產(chǎn)者(key)決定了數(shù)據(jù)產(chǎn)生到集群的哪個(gè)partition

33竞穷、kafka consumer 什么情況會(huì)觸發(fā)再平衡reblance?

①一旦消費(fèi)者加入或退出消費(fèi)組唐责,導(dǎo)致消費(fèi)組成員列表發(fā)生變化,消費(fèi)組中的所有消費(fèi)者都要執(zhí)行再平衡瘾带。

②訂閱主題分區(qū)發(fā)生變化鼠哥,所有消費(fèi)者也都要再平衡。

34看政、描述下kafka consumer 再平衡步驟?

①關(guān)閉數(shù)據(jù)拉取線程朴恳,情空隊(duì)列和消息流,提交偏移量允蚣;

②釋放分區(qū)所有權(quán)于颖,刪除zk中分區(qū)和消費(fèi)者的所有者關(guān)系;

③將所有分區(qū)重新分配給每個(gè)消費(fèi)者嚷兔,每個(gè)消費(fèi)者都會(huì)分到不同分區(qū)森渐;

④將分區(qū)對(duì)應(yīng)的消費(fèi)者所有關(guān)系寫入ZK,記錄分區(qū)的所有權(quán)信息冒晰;

⑤重啟消費(fèi)者拉取線程管理器同衣,管理每個(gè)分區(qū)的拉取線程。

以上Kafka面試題部分來(lái)自網(wǎng)絡(luò)壶运,答案僅供參考耐齐,如果有不同的看法可以留言討論。死記硬背的方式不建議蒋情。如果您最近有面試到關(guān)于Kafka的面試題埠况,歡迎留言分享哦~

下面這份是我找到的另一篇Kafka面試資料,有需要的話點(diǎn)贊+關(guān)注棵癣,私信我就能獲取啦辕翰!


?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市狈谊,隨后出現(xiàn)的幾起案子金蜀,更是在濱河造成了極大的恐慌刷后,老刑警劉巖,帶你破解...
    沈念sama閱讀 212,383評(píng)論 6 493
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件渊抄,死亡現(xiàn)場(chǎng)離奇詭異尝胆,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī)护桦,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,522評(píng)論 3 385
  • 文/潘曉璐 我一進(jìn)店門含衔,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人二庵,你說(shuō)我怎么就攤上這事贪染。” “怎么了催享?”我有些...
    開封第一講書人閱讀 157,852評(píng)論 0 348
  • 文/不壞的土叔 我叫張陵杭隙,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我因妙,道長(zhǎng)痰憎,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,621評(píng)論 1 284
  • 正文 為了忘掉前任攀涵,我火速辦了婚禮铣耘,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘以故。我一直安慰自己蜗细,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,741評(píng)論 6 386
  • 文/花漫 我一把揭開白布怒详。 她就那樣靜靜地躺著炉媒,像睡著了一般。 火紅的嫁衣襯著肌膚如雪昆烁。 梳的紋絲不亂的頭發(fā)上吊骤,一...
    開封第一講書人閱讀 49,929評(píng)論 1 290
  • 那天,我揣著相機(jī)與錄音善玫,去河邊找鬼水援。 笑死密强,一個(gè)胖子當(dāng)著我的面吹牛茅郎,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播或渤,決...
    沈念sama閱讀 39,076評(píng)論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼系冗,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了薪鹦?” 一聲冷哼從身側(cè)響起掌敬,我...
    開封第一講書人閱讀 37,803評(píng)論 0 268
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤惯豆,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后奔害,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體楷兽,經(jīng)...
    沈念sama閱讀 44,265評(píng)論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,582評(píng)論 2 327
  • 正文 我和宋清朗相戀三年华临,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了芯杀。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 38,716評(píng)論 1 341
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡雅潭,死狀恐怖揭厚,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情扶供,我是刑警寧澤筛圆,帶...
    沈念sama閱讀 34,395評(píng)論 4 333
  • 正文 年R本政府宣布,位于F島的核電站椿浓,受9級(jí)特大地震影響太援,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜轰绵,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 40,039評(píng)論 3 316
  • 文/蒙蒙 一粉寞、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧左腔,春花似錦唧垦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,798評(píng)論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至鞭莽,卻和暖如春坊秸,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背澎怒。 一陣腳步聲響...
    開封第一講書人閱讀 32,027評(píng)論 1 266
  • 我被黑心中介騙來(lái)泰國(guó)打工褒搔, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人喷面。 一個(gè)月前我還...
    沈念sama閱讀 46,488評(píng)論 2 361
  • 正文 我出身青樓星瘾,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親惧辈。 傳聞我的和親對(duì)象是個(gè)殘疾皇子琳状,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,612評(píng)論 2 350