資料庫分庫分表的應用場景及方法分析
阿新 • • 發佈：2019-02-09
flickr開發團隊在2010年撰文介紹了flickr使用的一種主鍵生成測策略，同時表示該方案在flickr上的實際執行效果也非常令人滿意。它與一般Sequence表方案有些類似，但卻很好地解決了效能瓶頸和單點問題，是一種非常可靠而高效的全域性主鍵生成方案。整體思想是：建立兩臺以上的資料庫ID生成伺服器，每個伺服器都有一張記錄各表當前ID的Sequence表，但是Sequence中ID增長的步長是伺服器的數量，起始值依次錯開，這樣相當於把ID的生成雜湊到了每個伺服器節點上。例如：如果我們設定兩臺資料庫ID生成伺服器，那麼就讓一臺的Sequence表的ID起始值為1,每次增長步長為2,另一臺的Sequence
優點：高可用、ID較簡潔
缺點：需要單獨的資料庫叢集
4.5 UID生成方案|組合UID
組合UID，是一種帶有業務屬性的UID方案，取UID的前N位，再通過業務屬性（其他主鍵）的二級制後N位來生成UID。例如：訂單UID=60位全域性唯一id+userid二進位制末4位（如userid=666，其二級製為：0000 0010 1001
1010 ，取1010），此時省的訂單id具有了使用者的基因，在制定分表分庫規則時，可以據此規則將同一使用者的訂單都放到同一張庫表中。
優點：
1.解決UUID無序的問題
2.可以滿足滿足業務屬性條件的資料都儲存在同一個庫表中，避免查詢時的“跨庫join”的情況。如分庫分表時滿足同一使用者生成的訂單都在同一個庫表中。