OLTP的承載

自己原文公眾號： https://mp.weixin.qq.com/s/FRcxNQGWjui2LCpOE8FaZA

前幾天和以前同事吃飯。他們也是剛畢業後不 久就跟著我，可以說是我帶的。現在都在各自領域負責技術。我問其中一個他們現在業務規模，他們峰值有1000筆秒。（這裡不方便說具體數字）你就算一天86400秒都是峰值那就9千萬筆交易。實際一定沒有9000萬，但是千萬級別一定有的。（一個Oracle的RAC一天做幾千萬真不叫事，當然其他的資料庫產品也有可能，我僅僅說設計的好的話，其他的資料庫也能支援）

     我想起我以前經歷過，我問一個系統的開發負責人，你們系統忙不忙？他說不忙，我說我看後臺你的總資金11億了。他說嗯，其中有一筆就1個億。這裡你可能覺得是笑話，但是我說的是衡量一個系統是不是繁忙不能看總成交額，而是應該看筆數。

    隨著每次付款聽到的，支付寶到賬，微信到賬，收錢吧到賬。這些都是OceanBase、TDSQL、Oracle（第三方支付以及聚合支付我猜還是Oracle的多）這些後臺的成交壓力。再簡化的流程也是要記錄，那年那月那日使用者A向使用者B付錢的insert，以及update減賬戶餘額，這兩步是少不了的。如果是支付寶、微信分別的內部轉還要去update對方餘額。如果是第三方的話，那麼第三方要去做update動作。

     做過計算機的都知道，買一塊餅乾（假如5元）和買一噸煤（假如5萬元）對系統的衝擊是一樣的。所以如果有兩個個系統說A系統一天交易額100億元，交易筆數100筆。B系統一天交易10億元，交易筆數1億筆。顯而易見B系統的壓力高，難度大。而A系統說實在的，一個人也做的過來。實在不行，那就2個人。

     所以我們不要聽每天的交易金額，而是應該看交易量，才是判斷系統負荷的標準。

    此外還要看。如果兩個外賣系統（場景和規模都差不多的前提下）外賣就是這樣。A系統用了1萬臺伺服器支援了現在業務，B系統用了10萬臺伺服器支援了現在業務。那麼顯然A系統的開發和運維水平高出B系統幾個檔次。因為他們用了更合理的資源，或者是最佳化的技術手段做到了同樣的效果。

    以前總有人問如何管理幾百個庫（首先阿里 騰訊這種上百萬臺資料庫的我管理不好，能力有限，有那個本事我就去那裡了）但是一般的企業上千個資料庫了不起了。一般都是幾十到上百。其實這種我還是有不少經驗的。

      遵守開發規範，合在一起就方便管理了。單機最好了（為了安全，高可用和容災也是要的）所以嚴謹一點說單套是最好了。

      因為我們大多數企業沒有每天1億筆訂單或者交易。而每秒1000對資料庫來說是沒有太大壓力的。

      你看12306春運，傳送旅客幾億人次，那就是幾億訂單啊。因為還有退改簽的再乘以30%吧。

      而支付寶 微信都有8-9億使用者。平均每人一天5筆左右交易吧。一天50億筆差不多吧。這種屬於極個別，我們不討論這個。

     想想以前我們做公安系統記錄人車，一天隨隨便便就是5000萬記錄，單機Oracle。還是X86伺服器。  一天一億記錄的時候是小型機。而這些新增的那就是交易筆數，就是系統壓力。