今天去面試了,問到關於每天入庫百萬訂單的問題,其中關於儲存來說,暫時分析如下:
面試官說他們目前一年有幾百億的訂單量,當然這個是怎麼統計的先不管;
如果使用mysql無疑對資料庫效能是乙個挑戰,可能用到的技術就是各種分庫分表一類的,但是面對這麼海量的資料,我想還是存放在分布式資料庫比較合適,例如使用hbase來儲存訂單;
那麼當前的解決方案是這樣:
1)mysql只負責充當乙個支援強事務的中轉資料庫;負責下單到完成訂單整個流程的參與者,依靠事務特性保證資料的一致性;
2)將歷史訂單或者是已經不需要強一致性流轉的訂單,統一轉移到hbase;
3)使用者查詢已完成或過期的訂單,通過hbase查詢展示;待付款未完成的可以依然查詢mysql.這樣既滿足場景業務,也支援了海量資料;
如有不妥及不成熟的地方,請指正;
utips面試小記
很快投了簡歷一兩天就接到面試的通知。突然有點慌了，演算法 資料結構 作業系統 計算機網路，雖然之前都學的還行，但是這學期沒怎麼接觸，大多數概念都是模模糊糊的，而應聘的linux後台開發，對於linux仍然處於入門階段，所以可以預想到面試應該會很慘了。面試我的是團隊創始人之一的周師兄。果然 慘了，好幾...
騰訊面試小記
實驗室一萬年不開一次會，偏偏今天要開會，而且時間和面試的時間還是衝突的，不管了，果斷去面試。路上的各種情況按下不表。908房間，進去是乙個30左右的小伙，人很和善。完了讓我做乙個自我介紹。以下是我記得的一些問題。1 指標和引用的區別是什麼？2 int const p const 這句語句的含義。co...
基於TableStore的海量電商訂單元資料管理
訂單系統存在於各行各業，如電商訂單 銀行流水 運營商話費賬單等，是乙個非常廣泛 通用的系統。對於這類系統，在過去十幾年發展中已經形成了經典的做法。但是隨著網際網路的發展，以及各企業對資料的重視，需要儲存和持久化的訂單量越來越大。資料的重視程度與資料規模的膨脹帶來了新的挑戰，原有的系統是否還能繼續滿足...