如何用低廉的成本高效提高事務吞吐量

昨天回去仔細又想了下覺得太啰嗦,幾句話概括: 利用好緩存提高查詢效率,在記憶體中完成事務,然後寫事務日志(此時寫完可以傳回結果),将一個事務簡化為一個寫的操作,另外再異步送出資料庫,此方法效率提高點在于,記憶體資料處理非常高效,整個事務隻有在寫日志時候才涉及磁盤操作.

背景:很多中小公司,在做業務開發的時候,不會考慮tps, 一般隻要開發出功能.但是業務增長時候tps是個瓶頸,我們常用關系型資料庫,吞吐量實在是小.在一個獨立的服務中或者說一個應用中,如何用低廉的成本高效提高tps, 為此我基于已有的經驗寫的這篇文章.小弟才疏學淺,不對的地方望指正,

思路來源于分布式事務,把一個事務拆分成若幹個微小事務,最小為一條語句增删查改. 用磁盤型的nosql來作為存儲, 事務控制由應用程式來做,在事務開始和結束的地方用唯一标記控制,标記這個事務執行狀态,并存儲執行資料的副本,結束時候記錄事務送出狀态.最後由專門的程式檢驗事務并同步到關系型資料庫(其實就是異步送出思想,隻是保證應用中資料是最新的,無法保證關系型資料庫中的資料最新,可以保證應用中的資料會最終同步到關系型資料庫中), 那麼這裡會有并發,并發的資料共享怎麼做? 讀到記憶體用鎖,從這個層面看, 事務就是記憶體事務,redis已經支援了簡單的事務,不同的是這裡強調事務完成時候就落地,控制,nosql隻是作為落地存儲提高效率, nosql還可以通過單獨的應用和關系型資料庫同步.注意,在事務送出到副本後同步到關系型資料庫是注意事務送出順序,這個可以很容易,比方說事務id是遞增,如此一來單機tps吞吐量輕松幾千.(資料來源一個簡單應用程式的改造,說不定上萬都有可能,實際資料是每秒不超過2k的通路,平常也就5百左右,線上單機達到幾百的tps,包括應用伺服器在内資源占用率不超過10%cpu,一個tps基本上包含若幹條查詢,和約2-5條插入或是更新).

我來形容下這個方法,這可以稱之為”土方法”, 其實作在很多解決方案了,分布式,服務拆分…等等,但是此方法短期對于應對是很有效的,第一他無需大改項目,隻是把資料驅動換一下(當然你要封裝一下資料事務驅動),第二.他能在短時間内不需要你學習新的技術棧(當然nosql你的會,這不算啥新技術棧吧).第三就是很高的運作效率了.

局限:第一.一旦完做成該模式後,采用該模式後,所有的資料操作必須通過同一個資料驅動應用對資料讀寫進行,無法并發,否則資料不一緻(自己分析的),第二.斷電後事務雖然不丢失,但是再次讀寫前必須等待目前副本中的事務送出完全.(沒送出完全時候,會産生資料不一緻,自己分析的)

非常适用的場景: 1比方說一個事務裡面有很多資料是插入記錄行的語句,比方說銀行轉賬需要插入很多記錄對于記錄這種資料量非常大,但是金錢相關的資料有時候又必須放到關系型資料庫中(當然也可以用其他存儲,但是别跟我說這些,那是因為你不了解銀行系統和傳統企業). 2對相同資料大量更新操作,

題外話:至于是什麼程式請不要深趴,太丢人,前端bug不斷通路後端,當然解決辦法是拿有效資料(排除一些時間戳等加密資料),然後md5,将其重複的找出丢棄,隻是這個問題産生後就想起怎麼解決并發時候事務吞吐量,并拿他實驗.另外,應用程式的副本資料需要删除(避免撐爆記憶體),應該由事務送出的程式通知删除