分庫分表
隨著數(shù)據(jù)量的不斷增長，數(shù)據(jù)庫的發(fā)展主要經(jīng)歷以下幾個步驟：
- 1主-1從架構(gòu)
- 雙主-多從架構(gòu)，讀寫分離
- 表分區(qū)灯萍，提高并發(fā)
- 分表，提高并發(fā)
- Master更換SSD
- 分庫每聪，分表竟稳，提高并發(fā)
分庫分表實(shí)現(xiàn)過程
可以將業(yè)務(wù)庫劃分成16個庫，每個庫64個表進(jìn)行存儲熊痴，總共1024個表，MySQL單表性能超過千萬級別會導(dǎo)致性能嚴(yán)重下降聂宾，假設(shè)按千萬計(jì)算果善，最高可以存儲百億級數(shù)據(jù)量。隨著存儲問題的解決系谐，但復(fù)雜度會隨著增加：
多庫怎么保證生成的全局唯一ID
查詢復(fù)雜度的增加巾陕；
例如：商城購物的訂單中心，當(dāng)買家查詢訂單時纪他，應(yīng)該去哪個庫哪個表里查找鄙煤，賣家應(yīng)該去哪查；再大的存儲量茶袒，隨著數(shù)據(jù)量的增長梯刚，終究是會遇到瓶頸，該怎么擴(kuò)容薪寓。
全局唯一訂單號
采用Twitter snowflake方案亡资，全劇唯一ID生成由：時間戳+機(jī)器ID+自增序列（+userid后兩位）；
訂單的生成過程直接在應(yīng)用實(shí)例中生成向叉，直接在內(nèi)存中計(jì)算锥腻，且計(jì)算過程分散到每臺應(yīng)用實(shí)例中，解決性能問題母谎，userid后兩位在后面解釋瘦黑。
數(shù)據(jù)庫連接問題
分庫分表后，要連接數(shù)據(jù)庫變的復(fù)雜起來，分為兩種方案：
直連代碼適配模式
此種方式需要在應(yīng)用代碼中幸斥，自己計(jì)算訂單應(yīng)該進(jìn)入哪個庫匹摇，可取訂單的后兩位，先對庫16進(jìn)行取模睡毒，再對表64取模来惧，從而確定。優(yōu)點(diǎn)是直連數(shù)據(jù)庫性能更好演顾，缺點(diǎn)是代碼復(fù)雜度增加供搀。
通過中間價(jià)連接
服務(wù)中間價(jià)可以使用阿里的mycat連接，具體使用查看mycat文檔钠至。優(yōu)點(diǎn)：代碼實(shí)現(xiàn)簡單葛虐，跟分庫前差不多。
數(shù)據(jù)查詢操作
用戶需要查詢數(shù)據(jù)的時候棉钧，只有userid屿脐，并不知道數(shù)據(jù)存在哪個庫哪張表中，從每個庫每個表中遍歷一遍不現(xiàn)實(shí)宪卿。所以還要對唯一編號進(jìn)行改進(jìn)的诵，之前是：時間戳+機(jī)器ID+自增序列。現(xiàn)在此ID的后面加上userid的后兩位佑钾，時間戳+機(jī)器ID+自增序列+userid后兩位西疤。
例如：訂單入庫取模的后兩位即userid后兩位，即同一個買家的所有訂單都會存入同一個表中休溶，通過此設(shè)計(jì)買家即可找到訂單號應(yīng)該在哪個表中代赁。
擴(kuò)容問題
此方案已經(jīng)不是單純的通過訂單號查找訂單，還需要通過userid查找訂單兽掰，其次是訂單具有時間特性芭碍，用戶查詢的大部分都是最近的訂單，3月前的訂單很少會查看孽尽，所以不適合進(jìn)行擴(kuò)容窖壕，特別適合遷移歷史數(shù)據(jù)，將3個月前的數(shù)據(jù)遷移到歷史數(shù)據(jù)庫中泻云，從而解決容量增長的問題艇拍。
業(yè)務(wù)拆分
業(yè)務(wù)極其復(fù)雜，不只是訂單號的生成插入等宠纯，還要減庫存卸夕、支付等一系列的操作。所以應(yīng)該通過消息隊(duì)列將業(yè)務(wù)進(jìn)行拆分婆瓜，本步驟只做訂單生成的操作快集，通過消息隊(duì)列實(shí)現(xiàn)數(shù)據(jù)的最終一致性贡羔。
