EOS 源碼解析什麼是 read only 模式

時間 2019-11-10

標籤 eos 源碼解析什麼 read 模式简体版

原文原文鏈接

你們以前使用 mongodb_plugin 、mysql_plugin 或其餘數據持久化插件的時候，可能會發現 transaction 和 trace 的數據重複duplicate ( 多機環境下)。在最初的時候只能在持久化的時候作去重處理，但 EOS 以後已經推出了 read only 模式，能夠避免數據出現 duplicate 的狀況，但筆者發現不少人不知道有這種模式，也不清楚這種狀況的發生由來。接下來咱們來分析下爲何會出現這種狀況，以及 read only 模式起到了什麼做用。mysql

首先 read only 模式不能用於出塊節點，因此咱們以一個同步節點的立場來說述。

寫一個持久化插件，咱們必需要有數據源，也就是這幾個信號，咱們從這裏獲取數據，這裏使用的是觀察者模式，每當信號源有新數據 emit 的時候就會調用咱們定義的函數，具體觀察者模式的實如今這裏就不描述了，參考 mongodb_plugin 代碼。

signal<void(const signed_block_ptr&)>         pre_accepted_block;
signal<void(const block_state_ptr&)>          accepted_block_header;
signal<void(const block_state_ptr&)>          accepted_block;
signal<void(const block_state_ptr&)>          irreversible_block;
signal<void(const transaction_metadata_ptr&)> accepted_transaction;
signal<void(const transaction_trace_ptr&)>    applied_transaction;
signal<void(const header_confirmation&)>      accepted_confirmation;

出現重複的會是 accepted_transaction 和 applied_transaction 這個信號源，因此咱們重點介紹它。sql

咱們會在 controller.push_transaction 發現這兩個函數的觸發。mongodb

transaction_trace_ptr push_transaction( const transaction_metadata_ptr& trx,
                                        fc::time_point deadline,
                                        uint32_t billed_cpu_time_us,
                                        bool explicit_billed_cpu_time = false )
{
   // ...

         // call the accept signal but only once for this transaction
         if (!trx->accepted) {
            trx->accepted = true;
            emit( self.accepted_transaction, trx);
         }

         emit(self.applied_transaction, trace);

   // ...
} /// push_transaction

OK, 看到這一步咱們就知道 push_transaction 執行了 2 次一樣的 trx 纔會致使這2個信號 duplicate。api

爲何會執行 2 次呢？微信

trx 是經過什麼來廣播的呢，塊廣播以及交易廣播, 那咱們從這入手。網絡

交易廣播
每一個節點會接受全網上的交易，嘗試執行，若是成功，則他繼續向其餘節點廣播這個交易多線程

// net_plugin.cpp
void net_plugin_impl::handle_message( connection_ptr c, const packed_transaction &msg) {
   // ...

   // read only 模式不接受廣播交易
   if( cc.get_read_mode() == eosio::db_read_mode::READ_ONLY ) {
      fc_dlog(logger, "got a txn in read-only mode - dropping");
      return;
   }
   
   // ...

   // 接受交易， 並執行 push  transaction
   spatcher->recv_transaction(c, tid);
   chain_plug->accept_transaction(msg, [=](const static_variant<fc::exception_ptr, transaction_trace_ptr>& result) {
      if (result.contains<fc::exception_ptr>()) {
         peer_dlog(c, "bad packed_transaction : ${m}", ("m",result.get<fc::exception_ptr>()->what()));
      } else {
         auto trace = result.get<transaction_trace_ptr>();
         if (!trace->except) {
            fc_dlog(logger, "chain accepted transaction");
            dispatcher->bcast_transaction(msg);
            return;
         }

         peer_elog(c, "bad packed_transaction : ${m}", ("m",trace->except->what()));
      }

      dispatcher->rejected_transaction(tid);
   });
}

// chain plugin.cpp
void chain_plugin::accept_transaction(const chain::packed_transaction& trx, next_function<chain::transaction_trace_ptr> next) {
   // 至關於往該節點 push transaction
   my->incoming_transaction_async_method(std::make_shared<packed_transaction>(trx), false, std::forward<decltype(next)>(next));
}

第一次 push_transaction 的執行找到啦。app

塊廣播
接下來看塊廣播，在網絡上廣播的交易，最終是會被出塊節點打包( 執行失敗的例外)，每一個節點都要去同步塊，接受一個打包好的區塊，執行 apply_block 函數。async

void apply_block( const signed_block_ptr& b, controller::block_status s ) { try {
   try {
      // ...

      // 多線程簽名

      // ...

      transaction_trace_ptr trace;

      size_t packed_idx = 0;
      // 執行塊上的交易，更新該節點的狀態
      for( const auto& receipt : b->transactions ) {
         auto num_pending_receipts = pending->_pending_block_state->block->transactions.size();
         if( receipt.trx.contains<packed_transaction>() ) {
            trace = push_transaction( packed_transactions.at(packed_idx++), fc::time_point::maximum(), receipt.cpu_usage_us, true );
         } else if( receipt.trx.contains<transaction_id_type>() ) {
            trace = push_scheduled_transaction( receipt.trx.get<transaction_id_type>(), fc::time_point::maximum(), receipt.cpu_usage_us, true );
         } else {
            EOS_ASSERT( false, block_validate_exception, "encountered unexpected receipt type" );
         }

         // ...
      }

      //...
      return;
   } catch ( const fc::exception& e ) {
      edump((e.to_detail_string()));
      abort_block();
      throw;
   }
} FC_CAPTURE_AND_RETHROW() } /// apply_block

第二次執行 push transaction 也找到啦。函數

也就是一個 trx 在傳播到該節點的時候會被執行一次，trx 被打包後跟隨區塊到該節點又會被執行一次，這就形成 accepted_transaction 和 applied_transaction 這兩個信號重複，致使重複數據的產生。

解決問題
問題找到了，接下來解決問題。

出現兩次調用 push_transaction 的操做，那麼確定要禁掉其中一個，纔會使信號只觸發一次，那同步區塊的步驟確定不能禁掉，塊廣播和交易廣播，咱們只能選擇禁止交易廣播的執行，因此爲何出塊節點不能用 read only 模式( ps: 交易廣播都被你禁掉了，我還怎麼打包區塊？？？黑人問號臉)

交易廣播有 2 個途徑一個是接受鏈上的交易傳播，一個是經過 chain_api_plugin 的 push_transaction API 推送，因此禁掉這兩個就能夠了。沒錯， read only 模式的做用就是禁止 2 途徑。

// net_plugin.cpp
void net_plugin_impl::handle_message( connection_ptr c, const packed_transaction &msg) {
   // ...

   // read only 模式不接受廣播交易
   if( cc.get_read_mode() == eosio::db_read_mode::READ_ONLY ) {
      fc_dlog(logger, "got a txn in read-only mode - dropping");
      return;
   }
   
   // ...

   // 接受交易， 並執行 push  transaction
   spatcher->recv_transaction(c, tid);
   chain_plug->accept_transaction(msg, [=](const static_variant<fc::exception_ptr, transaction_trace_ptr>& result) {
      if (result.contains<fc::exception_ptr>()) {
         peer_dlog(c, "bad packed_transaction : ${m}", ("m",result.get<fc::exception_ptr>()->what()));
      } else {
         auto trace = result.get<transaction_trace_ptr>();
         if (!trace->except) {
            fc_dlog(logger, "chain accepted transaction");
            dispatcher->bcast_transaction(msg);
            return;
         }

         peer_elog(c, "bad packed_transaction : ${m}", ("m",trace->except->what()));
      }

      dispatcher->rejected_transaction(tid);
   });
}

// controller.cpp
transaction_trace_ptr controller::push_transaction( const transaction_metadata_ptr& trx, fc::time_point deadline, uint32_t billed_cpu_time_us ) {
   validate_db_available_size();
   // 若是是 read only 模式即中斷
   EOS_ASSERT( get_read_mode() != chain::db_read_mode::READ_ONLY, transaction_type_exception, "push transaction not allowed in read-only mode" );
   EOS_ASSERT( trx && !trx->implicit && !trx->scheduled, transaction_type_exception, "Implicit/Scheduled transaction not allowed" );
   return my->push_transaction(trx, deadline, billed_cpu_time_us, billed_cpu_time_us > 0 );
}

嗯，問題來了，如何開啓 read only 模式呢。

很簡單，在config.ini 加上read-mode = read-only 便可。

總結：

accepted_transaction 和 applied_transaction 信號重複的緣由在於 trx 被執行了兩次，即塊廣播與交易廣播，因此禁止交易廣播便可，但此時節點只供讀取數據，不能寫入數據。因此若是節點要來提供 push_transaction 這個 http api 的話不能開啓此模式。
trx 經過交易廣播在非出塊節點執行是爲了驗證該 trx 是否能合法執行，若是不能，則該節點不會向網絡傳播該交易
爲何單機模式不會出現信號重複，由於單機節點只有一個，不會出現塊傳播，只有交易傳播。
若是你要寫持久化插件，記得開啓 read only 模式，或者在持久化的時候去重。

有任何疑問或者想交流的朋友能夠加 EOS LIVE 小助手，備註 eos開發者拉您進 EOS LIVE DAPP 開發者社區微信羣哦。