消息隊(duì)列之RocketMQ-事務(wù)消息

1、從本地事務(wù)到分布式事務(wù)

我們經(jīng)常支付寶轉(zhuǎn)賬余額寶，這是日常生活的一件普通小事，但是我們思考支付寶扣除轉(zhuǎn)賬的錢之后，如果系統(tǒng)掛掉怎么辦，這時(shí)余額寶賬戶并沒有增加相應(yīng)的金額，數(shù)據(jù)就會(huì)出現(xiàn)不一致狀況了。

上述場(chǎng)景在各個(gè)類型的系統(tǒng)中都能找到相似影子，比如在電商系統(tǒng)中，當(dāng)有用戶下單后，除了在訂單表插入一條記錄外，對(duì)應(yīng)商品表的這個(gè)商品數(shù)量必須減1吧，怎么保證？在搜索廣告系統(tǒng)中，當(dāng)用戶點(diǎn)擊某廣告后，除了在點(diǎn)擊事件表中增加一條記錄外，還得去商家賬戶表中找到這個(gè)商家并扣除廣告費(fèi)吧，怎么保證？

本質(zhì)上問題可以抽象為：當(dāng)一個(gè)表數(shù)據(jù)更新后，怎么保證另一個(gè)表的數(shù)據(jù)也必須要更新成功。

還是以支付寶轉(zhuǎn)賬余額寶為例（比如轉(zhuǎn)賬10000塊錢），假設(shè)有：

  • 支付寶賬戶表：A（id，userId，amount）
  • 余額寶賬戶表：B（id，userId，amount）

用戶的userId=1，從支付寶轉(zhuǎn)賬1萬塊錢到余額寶的動(dòng)作分為兩步：

  • 支付寶表扣除1萬：update A set amount=amount-10000 where userId=1;
  • 余額寶表增加1萬：update B set amount=amount+10000 where userId=1;

如何確保支付寶余額寶收支平衡呢？

如果是單機(jī)系統(tǒng)(數(shù)據(jù)庫實(shí)例也在同一個(gè)系統(tǒng)上)的話，我們可以用本地事務(wù)輕松解決：

Begin transaction 
  update A set amount=amount-10000 where userId=1;
 update B set amount=amount+10000 where userId=1;
End transaction 
commit;

如果系統(tǒng)規(guī)模較小，數(shù)據(jù)表都在一個(gè)數(shù)據(jù)庫實(shí)例上，上述本地事務(wù)方式可以很好地運(yùn)行，但是如果系統(tǒng)規(guī)模較大，比如支付寶賬戶表和余額寶賬戶表顯然不會(huì)在同一個(gè)數(shù)據(jù)庫實(shí)例上，他們往往分布在不同的物理節(jié)點(diǎn)上，這時(shí)本地事務(wù)已經(jīng)失去用武之地。

下面我們來看看比較主流的兩種方案：

1.1 兩階段提交協(xié)議

兩階段提交協(xié)議（Two-phase Commit，2PC）經(jīng)常被用來實(shí)現(xiàn)分布式事務(wù)。一般分為協(xié)調(diào)器TC和若干事務(wù)執(zhí)行者兩種角色，這里的事務(wù)執(zhí)行者就是具體的數(shù)據(jù)庫，協(xié)調(diào)器可以和事務(wù)執(zhí)行器在一臺(tái)機(jī)器上。

1.png

我們根據(jù)上面的圖來看看主要流程：

  • 我們的應(yīng)用程序（client）發(fā)起一個(gè)開始請(qǐng)求到TC（transaction）；
  • TC先將prepare消息寫到本地日志，之后向所有的Si發(fā)起prepare消息。以支付寶轉(zhuǎn)賬到余額寶為例，TC給A的prepare消息是通知支付寶數(shù)據(jù)庫相應(yīng)賬目扣款1萬，TC給B的prepare消息是通知余額寶數(shù)據(jù)庫相應(yīng)賬目增加1w。為什么在執(zhí)行任務(wù)前需要先寫本地日志，主要是為了故障后恢復(fù)用，本地日志起到現(xiàn)實(shí)生活中憑證的效果，如果沒有本地日志（憑證），出問題容易死無對(duì)證；
  • Si收到prepare消息后，執(zhí)行具體本機(jī)事務(wù)，但不會(huì)進(jìn)行commit，如果成功返回yes，不成功返回no。同理，返回前都應(yīng)把要返回的消息寫到日志里，當(dāng)作憑證。
  • TC收集所有執(zhí)行器返回的消息，如果所有執(zhí)行器都返回yes，那么給所有執(zhí)行器發(fā)生送commit消息，執(zhí)行器收到commit后執(zhí)行本地事務(wù)的commit操作；如果有任一個(gè)執(zhí)行器返回no，那么給所有執(zhí)行器發(fā)送abort消息，執(zhí)行器收到abort消息后執(zhí)行事務(wù)abort操作。

TC或Si把發(fā)送或接收到的消息先寫到日志里，主要是為了故障后恢復(fù)用。如某一Si從故障中恢復(fù)后，先檢查本機(jī)的日志，如果已收到commit，則提交，如果abort則回滾。如果是yes，則再向TC詢問一下，確定下一步。如果什么都沒有，則很可能在prepare階段Si就崩潰了，因此需要回滾。

現(xiàn)如今實(shí)現(xiàn)基于兩階段提交的分布式事務(wù)也沒那么困難了，如果使用java，那么可以使用開源軟件atomikos來快速實(shí)現(xiàn)。

不過但凡使用過的上述兩階段提交的同學(xué)都可以發(fā)現(xiàn)性能實(shí)在是太差，根本不適合高并發(fā)的系統(tǒng)。為什么？

  • 兩階段提交涉及多次節(jié)點(diǎn)間的網(wǎng)絡(luò)通信，通信時(shí)間太長
  • 事務(wù)時(shí)間相對(duì)于變長了，鎖定的資源的時(shí)間也變長了，造成資源等待時(shí)間也增加好多

正是由于分布式事務(wù)存在很嚴(yán)重的性能問題，大部分高并發(fā)服務(wù)都在避免使用，往往通過其他途徑來解決數(shù)據(jù)一致性問題。

1.2 使用消息隊(duì)列來避免分布式事務(wù)

如果仔細(xì)觀察生活的話，生活的很多場(chǎng)景已經(jīng)給了我們提示。

比如在北京很有名的姚記炒肝點(diǎn)了炒肝并付了錢后，他們并不會(huì)直接把你點(diǎn)的炒肝給你，而是給你一張小票，然后讓你拿著小票到出貨區(qū)排隊(duì)去取。為什么他們要將付錢和取貨兩個(gè)動(dòng)作分開呢？原因很多，其中一個(gè)很重要的原因是為了使他們接待能力增強(qiáng)（并發(fā)量更高）。

還是回到我們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉(zhuǎn)賬服務(wù)也是如此，當(dāng)支付寶賬戶扣除1萬后，我們只要生成一個(gè)憑證（消息）即可，這個(gè)憑證（消息）上寫著“讓余額寶賬戶增加1萬”，只要這個(gè)憑證（消息）能可靠保存，我們最終是可以拿著這個(gè)憑證（消息）讓余額寶賬戶增加1萬的，即我們能依靠這個(gè)憑證（消息）完成最終一致性。

那么我們?nèi)绾慰煽勘４鎽{證（消息）有兩種方法：

1.2.1 業(yè)務(wù)與消息耦合的方式

支付寶在完成扣款的同時(shí)，同時(shí)記錄消息數(shù)據(jù)，這個(gè)消息數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)保存在同一數(shù)據(jù)庫實(shí)例里（消息記錄表表名為message）。

Begin transaction 
       update A set amount=amount-10000 where userId=1; 
       insert into message(userId, amount,status) values(1, 10000, 1); 
End transaction 
commit;

上述事務(wù)能保證只要支付寶賬戶里被扣了錢，消息一定能保存下來。

當(dāng)上述事務(wù)提交成功后，我們通過實(shí)時(shí)消息服務(wù)將此消息通知余額寶，余額寶處理成功后發(fā)送回復(fù)成功消息，支付寶收到回復(fù)后刪除該條消息數(shù)據(jù)。

1.2.2 業(yè)務(wù)與消息解耦方式

上述保存消息的方式使得消息數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)緊耦合在一起，從架構(gòu)上看不夠優(yōu)雅，而且容易誘發(fā)其他問題。為了解耦，可以采用以下方式。

  • 支付寶在扣款事務(wù)提交之前，向?qū)崟r(shí)消息服務(wù)請(qǐng)求發(fā)送消息，實(shí)時(shí)消息服務(wù)只記錄消息數(shù)據(jù)，而不真正發(fā)送，只有消息發(fā)送成功后才會(huì)提交事務(wù)；
  • 當(dāng)支付寶扣款事務(wù)被提交成功后，向?qū)崟r(shí)消息服務(wù)確認(rèn)發(fā)送。只有在得到確認(rèn)發(fā)送指令后，實(shí)時(shí)消息服務(wù)才真正發(fā)送該消息；
  • 當(dāng)支付寶扣款事務(wù)提交失敗回滾后，向?qū)崟r(shí)消息服務(wù)取消發(fā)送。在得到取消發(fā)送指令后，該消息將不會(huì)被發(fā)送；
  • 對(duì)于那些未確認(rèn)的消息或者取消的消息，需要有一個(gè)消息狀態(tài)確認(rèn)系統(tǒng)定時(shí)去支付寶系統(tǒng)查詢這個(gè)消息的狀態(tài)并進(jìn)行更新。為什么需要這一步驟，舉個(gè)例子：假設(shè)在第2步支付寶扣款事務(wù)被成功提交后，系統(tǒng)掛了，此時(shí)消息狀態(tài)并未被更新為“確認(rèn)發(fā)送”，從而導(dǎo)致消息不能被發(fā)送。

優(yōu)點(diǎn)是消息數(shù)據(jù)獨(dú)立存儲(chǔ)，降低業(yè)務(wù)系統(tǒng)與消息系統(tǒng)間的耦合；缺點(diǎn)是一次消息發(fā)送需要兩次請(qǐng)求，業(yè)務(wù)處理服務(wù)需要實(shí)現(xiàn)消息狀態(tài)回查接口。

還有一個(gè)很嚴(yán)重的問題就是消息重復(fù)投遞，以我們支付寶轉(zhuǎn)賬到余額寶為例，如果相同的消息被重復(fù)投遞兩次，那么我們余額寶賬戶將會(huì)增加2萬而不是1萬了。

為什么相同的消息會(huì)被重復(fù)投遞？比如余額寶處理完消息msg后，發(fā)送了處理成功的消息給支付寶，正常情況下支付寶應(yīng)該要?jiǎng)h除消息msg，但如果支付寶這時(shí)候悲劇的掛了，重啟后一看消息msg還在，就會(huì)繼續(xù)發(fā)送消息msg。

解決方法很簡單，在余額寶這邊增加消息應(yīng)用狀態(tài)表，通俗來說就是個(gè)賬本，用于記錄消息的消費(fèi)情況，每次來一個(gè)消息，在真正執(zhí)行之前，先去消息應(yīng)用狀態(tài)表中查詢一遍，如果找到說明是重復(fù)消息，丟棄即可，如果沒找到才執(zhí)行，同時(shí)插入到消息應(yīng)用狀態(tài)表（同一事務(wù)）。

for each msg in queue 

Begin transaction 

  select count(*) as cnt from message_apply where msg_id=msg.msg_id; 

  if cnt==0 then 

    update B set amount=amount+10000 where userId=1; 

    insert into message_apply(msg_id) values(msg.msg_id); 

End transaction 

commit;

1.3 進(jìn)一步分析

為了方便大家理解，我們?cè)賮砼e一個(gè)銀行轉(zhuǎn)賬的示例：

比如，Bob向Smith轉(zhuǎn)賬100塊。

在單機(jī)環(huán)境下，執(zhí)行事務(wù)的情況，大概是下面這個(gè)樣子：

2.png

當(dāng)用戶增長到一定程度，Bob和Smith的賬戶及余額信息已經(jīng)不在同一臺(tái)服務(wù)器上了，那么上面的流程就變成了這樣：

3.png

這時(shí)候你會(huì)發(fā)現(xiàn)，同樣是一個(gè)轉(zhuǎn)賬的業(yè)務(wù)，在集群環(huán)境下，耗時(shí)居然成倍的增長，這顯然是不能夠接受的。那如何來規(guī)避這個(gè)問題？

大事務(wù) = 小事務(wù) + 異步

將大事務(wù)拆分成多個(gè)小事務(wù)異步執(zhí)行。這樣基本上能夠?qū)⒖鐧C(jī)事務(wù)的執(zhí)行效率優(yōu)化到與單機(jī)一致。轉(zhuǎn)賬的事務(wù)就可以分解成如下兩個(gè)小事務(wù)：

4.png

圖中執(zhí)行本地事務(wù)（Bob賬戶扣款）和發(fā)送異步消息應(yīng)該保證同時(shí)成功或者同時(shí)失敗，也就是扣款成功了，發(fā)送消息一定要成功，如果扣款失敗了，就不能再發(fā)送消息。那問題是：我們是先扣款還是先發(fā)送消息呢？

首先看下先發(fā)送消息的情況，大致的示意圖如下：

5.png

存在的問題是：如果消息發(fā)送成功，但是扣款失敗，消費(fèi)端就會(huì)消費(fèi)此消息，進(jìn)而向Smith賬戶加錢。

先發(fā)消息不行，那就先扣款吧，大致的示意圖如下：

6.png

存在的問題跟上面類似：如果扣款成功，發(fā)送消息失敗，就會(huì)出現(xiàn)Bob扣錢了，但是Smith賬戶未加錢。

可能大家會(huì)有很多的方法來解決這個(gè)問題，比如：直接將發(fā)消息放到Bob扣款的事務(wù)中去，如果發(fā)送失敗，拋出異常，事務(wù)回滾。這樣的處理方式也符合“恰好”不需要解決的原則。

RocketMQ支持事務(wù)消息，下面來看看RocketMQ是怎樣來實(shí)現(xiàn)的?

7.png

RocketMQ第一階段發(fā)送Prepared消息時(shí)，會(huì)拿到消息的地址，第二階段執(zhí)行本地事物，第三階段通過第一階段拿到的地址去訪問消息，并修改消息的狀態(tài)。

細(xì)心的你可能又發(fā)現(xiàn)問題了，如果確認(rèn)消息發(fā)送失敗了怎么辦？RocketMQ會(huì)定期掃描消息集群中的事物消息，如果發(fā)現(xiàn)了Prepared消息，它會(huì)向消息發(fā)送端(生產(chǎn)者)確認(rèn)，Bob的錢到底是減了還是沒減呢？如果減了是回滾還是繼續(xù)發(fā)送確認(rèn)消息呢？

RocketMQ會(huì)根據(jù)發(fā)送端設(shè)置的策略來決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息。這樣就保證了消息發(fā)送與本地事務(wù)同時(shí)成功或同時(shí)失敗

2、實(shí)現(xiàn)細(xì)節(jié)

RocketMQ采用了2PC的思想來實(shí)現(xiàn)了提交事務(wù)消息，同時(shí)增加一個(gè)補(bǔ)償邏輯來處理二階段超時(shí)或者失敗的消息。

8.png

上圖說明了事務(wù)消息的大致方案，其中分為兩個(gè)流程：正常事務(wù)消息的發(fā)送及提交、事務(wù)消息的補(bǔ)償流程。

  • 事務(wù)消息發(fā)送及提交
    • (1) 發(fā)送消息（half消息）。
    • (2) 服務(wù)端響應(yīng)消息寫入結(jié)果。
    • (3) 根據(jù)發(fā)送結(jié)果執(zhí)行本地事務(wù)（如果寫入失敗，此時(shí)half消息對(duì)業(yè)務(wù)不可見，本地邏輯不執(zhí)行）。
    • (4) 根據(jù)本地事務(wù)狀態(tài)執(zhí)行Commit或者Rollback（Commit操作生成消息索引，消息對(duì)消費(fèi)者可見）
  • 補(bǔ)償流程
    • (1) 對(duì)沒有Commit/Rollback的事務(wù)消息（pending狀態(tài)的消息），從服務(wù)端發(fā)起一次“回查”
    • (2) Producer收到回查消息，檢查回查消息對(duì)應(yīng)的本地事務(wù)的狀態(tài)
    • (3) 根據(jù)本地事務(wù)狀態(tài)，重新Commit或者Rollback

其中，補(bǔ)償階段用于解決消息Commit或者Rollback發(fā)生超時(shí)或者失敗的情況。

在RocketMQ事務(wù)消息的主要流程中，一階段的消息是如何做到對(duì)用戶不可見呢？RocketMQ事務(wù)消息的做法是：如果消息是half消息，將備份原消息的主題與消息消費(fèi)隊(duì)列，然后改變主題為RMQ_SYS_TRANS_HALF_TOPIC。由于消費(fèi)組未訂閱該主題，故消費(fèi)端無法消費(fèi)half類型的消息，然后RocketMQ會(huì)開啟一個(gè)定時(shí)任務(wù)，從Topic為RMQ_SYS_TRANS_HALF_TOPIC中拉取消息進(jìn)行消費(fèi)，根據(jù)生產(chǎn)者組獲取一個(gè)服務(wù)提供者發(fā)送回查事務(wù)狀態(tài)請(qǐng)求，根據(jù)事務(wù)狀態(tài)來決定是提交或回滾消息。

在完成一階段寫入一條對(duì)用戶不可見的消息后，二階段如果是Commit操作，則需要讓消息對(duì)用戶可見；如果是Rollback則需要撤銷一階段的消息。先說Rollback的情況。對(duì)于Rollback，本身一階段的消息對(duì)用戶是不可見的，其實(shí)不需要真正撤銷消息（實(shí)際上RocketMQ也無法去真正的刪除一條消息，因?yàn)槭琼樞驅(qū)懳募模５菂^(qū)別于這條消息沒有確定狀態(tài)（Pending狀態(tài)，事務(wù)懸而未決），需要一個(gè)操作來標(biāo)識(shí)這條消息的最終狀態(tài)。RocketMQ事務(wù)消息方案中引入了Op消息的概念，用Op消息標(biāo)識(shí)事務(wù)消息已經(jīng)確定的狀態(tài)（Commit或者Rollback）。如果一條事務(wù)消息沒有對(duì)應(yīng)的Op消息，說明這個(gè)事務(wù)的狀態(tài)還無法確定（可能是二階段失敗了）。引入Op消息后，事務(wù)消息無論是Commit或者Rollback都會(huì)記錄一個(gè)Op操作。Commit相對(duì)于Rollback只是在寫入Op消息前創(chuàng)建Half消息的索引。

9.png

如果在RocketMQ事務(wù)消息的二階段過程中失敗了，例如在做Commit操作時(shí)，出現(xiàn)網(wǎng)絡(luò)問題導(dǎo)致Commit失敗，那么需要通過一定的策略使這條消息最終被Commit。RocketMQ采用了一種補(bǔ)償機(jī)制，稱為“回查”。Broker端對(duì)未確定狀態(tài)的消息發(fā)起回查，將消息發(fā)送到對(duì)應(yīng)的Producer端（同一個(gè)Group的Producer），由Producer根據(jù)消息來檢查本地事務(wù)的狀態(tài)，進(jìn)而執(zhí)行Commit或者Rollback。Broker端通過對(duì)比Half消息和Op消息進(jìn)行事務(wù)消息的回查并且推進(jìn)CheckPoint（記錄那些事務(wù)消息的狀態(tài)是確定的）。

值得注意的是，rocketmq并不會(huì)無休止的的信息事務(wù)狀態(tài)回查，默認(rèn)回查15次，如果15次回查還是無法得知事務(wù)狀態(tài)，rocketmq默認(rèn)回滾該消息。

3、代碼實(shí)例

使用 TransactionMQProducer類創(chuàng)建生產(chǎn)者，并指定唯一的 ProducerGroup，就可以設(shè)置自定義線程池來處理這些檢查請(qǐng)求。

public class TransactionProducer {
   public static void main(String[] args) throws MQClientException, InterruptedException {
       TransactionListener transactionListener = new TransactionListenerImpl();
       TransactionMQProducer producer = new TransactionMQProducer("please_rename_unique_group_name");
       ExecutorService executorService = new ThreadPoolExecutor(2, 5, 100, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(2000), new ThreadFactory() {
           @Override
           public Thread newThread(Runnable r) {
               Thread thread = new Thread(r);
               thread.setName("client-transaction-msg-check-thread");
               return thread;
           }
       });
       producer.setExecutorService(executorService);
       producer.setTransactionListener(transactionListener);
       producer.start();
       String[] tags = new String[] {"TagA", "TagB", "TagC", "TagD", "TagE"};
       for (int i = 0; i < 10; i++) {
           try {
               Message msg =
                   new Message("TopicTest1234", tags[i % tags.length], "KEY" + i,
                       ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
               SendResult sendResult = producer.sendMessageInTransaction(msg, null);
               System.out.printf("%s%n", sendResult);
               Thread.sleep(10);
           } catch (MQClientException | UnsupportedEncodingException e) {
               e.printStackTrace();
           }
       }
       for (int i = 0; i < 100000; i++) {
           Thread.sleep(1000);
       }
       producer.shutdown();
   }
}

當(dāng)發(fā)送half消息成功時(shí)，我們使用 executeLocalTransaction 方法來執(zhí)行本地事務(wù)。checkLocalTransaction 方法用于檢查本地事務(wù)狀態(tài)，并回應(yīng)消息隊(duì)列的檢查請(qǐng)求。

public class TransactionListenerImpl implements TransactionListener {
  private AtomicInteger transactionIndex = new AtomicInteger(0);
  private ConcurrentHashMap<String, Integer> localTrans = new ConcurrentHashMap<>();
  @Override
  public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
      int value = transactionIndex.getAndIncrement();
      int status = value % 3;
      localTrans.put(msg.getTransactionId(), status);
      return LocalTransactionState.UNKNOW;
  }
  @Override
  public LocalTransactionState checkLocalTransaction(MessageExt msg) {
      Integer status = localTrans.get(msg.getTransactionId());
      if (null != status) {
          switch (status) {
              case 0:
                  return LocalTransactionState.UNKNOW;
              case 1:
                  return LocalTransactionState.COMMIT_MESSAGE;
              case 2:
                  return LocalTransactionState.ROLLBACK_MESSAGE;
          }
      }
      return LocalTransactionState.COMMIT_MESSAGE;
  }
}

事務(wù)消息共有三種狀態(tài)，提交狀態(tài)、回滾狀態(tài)、中間狀態(tài)：

  • TransactionStatus.CommitTransaction: 提交事務(wù)，它允許消費(fèi)者消費(fèi)此消息。
  • TransactionStatus.RollbackTransaction: 回滾事務(wù)，它代表該消息將被刪除，不允許被消費(fèi)。
  • TransactionStatus.Unknown: 中間狀態(tài)，它代表需要檢查消息隊(duì)列來確定狀態(tài)。
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
    沈念sama閱讀 227,702評(píng)論 6贊 531
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場(chǎng)離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,143評(píng)論 3贊 415
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
    開封第一講書人閱讀 175,553評(píng)論 0贊 373
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長。 經(jīng)常有香客問我，道長，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 62,620評(píng)論 1贊 307
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 71,416評(píng)論 6贊 405
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著，像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 54,940評(píng)論 1贊 321
  • 城市分裂傳說
    那天，我揣著相機(jī)與錄音，去河邊找鬼。 笑死，一個(gè)胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播，決...
    沈念sama閱讀 43,024評(píng)論 3贊 440
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場(chǎng)噩夢(mèng)啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 42,170評(píng)論 0贊 287
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對(duì)情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個(gè)月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 48,709評(píng)論 1贊 333
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,597評(píng)論 3贊 354
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 42,784評(píng)論 1贊 369
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
    沈念sama閱讀 38,291評(píng)論 5贊 357
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,029評(píng)論 3贊 347
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,407評(píng)論 0贊 25
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,663評(píng)論 1贊 280
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 51,403評(píng)論 3贊 390
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 47,746評(píng)論 2贊 370