資訊專欄INFORMATION COLUMN
摘要：分表字段的選擇。問題產生之前提到在分表應用上線前我們需要將原有表的數據遷移到新表中，這樣才能保證業務不受影響。雖說凌晨的業務量下降，但依然有少部分的請求過來，也會出現各種數據庫異常。
前言
本篇是上一篇《一次分表踩坑實踐的探討》，所以還沒看過的朋友建議先看上文。
還是先來簡單回顧下上次提到了哪些內容：
分表策略：哈希、時間歸檔等。
分表字段的選擇。
數據遷移方案。
而本篇文章的背景是在我們上線這段時間遇到的一些問題并嘗試解決的方案。
問題產生之前提到在分表應用上線前我們需要將原有表的數據遷移到新表中，這樣才能保證業務不受影響。
所以我們多帶帶寫了一個遷移應用，它負責將大表中的數據遷移到 64 張分表，而再遷移過程中產生的數據畢竟是少數，最后在上線當晚再次遷移過去即可。
一切想的很美好，當這個應用上線后卻發現沒這么簡單。
數據庫負載升高首先第一個問題是數據庫自己就頂不住了，在我們上這個遷移程序之前數據庫的壓力本身就比較大，這個應用一上去就成了最后一根稻草。
最后導致的結果是：所有連接了數據庫的程序大部分的操作都出現超時，獲取不到數據庫連接等一系列的異常。
最后沒辦法我們只能把這個應用放到凌晨執行，但其實后面觀察發現依然不行。
雖說凌晨的業務量下降，但依然有少部分的請求過來，也會出現各種數據庫異常。
再一個是遷移程序的效率也非常低下，按照這樣是速度，我們預估了一下遷移時間，大約需要 10 幾天才能把三張最大的表（3、4億的數據）遷移到分表中。
于是我們換了一個方案，將這個遷移程序在從庫中運行，最后再用運維的方法將分表直接導入進主庫。
因為從庫的壓力要比主庫小很多，對業務的影響很小，同時遷移的效率也要快很多。
即便是這樣也花了一晚上+一個白天的時間才將一張 1億的數據遷移完成，但是業務上的壓力越來越大，數據量再不斷新增，這個效率依然不夠。
兼容方案最終沒辦法只有想一個不遷移數據的方案，但是新產生的數據還是往分表里寫，至少保證大表的數據不再新增。
但這樣對于以前的數據咋辦呢？總不能不讓看了吧。
其實對于數據的操作無非就分為增刪改查，就這四種操作來看看如何兼容。
新增新增最簡單，所有的數據根據分表規則直接寫入新表，這樣可以保證老表的數據不再新增。
刪除刪除就要比新增稍微復雜一些，比如用戶想要刪除他個人產生的一條信息（比如說是訂單數據），有可能這個數據在新表也可能在老表。
所以刪除時優先刪除新表（畢竟新產生的數據訪問的頻次越高），如果刪除失敗再從老表刪除一次。
修改而修改同理，同樣的會不確定數據存在于哪里，所以先要修改新表，失敗后再次修改老表。
查詢查詢相對就要復雜一些了，因為這些大表的數據大部分都是存放一個用戶產生的多條記錄（比如一個用戶的訂單信息）。
這時在頁面上通常都會有分頁，并且按照時間進行排序。
麻煩的地方就出在這里：既然是要分頁那就有可能出現要查詢一部分分表數據和原來的大表數據做組合。
所以這里的查詢其實分為三種情況。
首先查詢的時候要計算這個用戶所在分表中的數據可以分為幾頁。
第一步首先判斷當前頁是否可以在分表中全部獲取，如果可以則直接從分表中取出數據返回（假設分頁中總共可以查詢 2 頁數據，當前為第 1 頁，那就全部取分表數據）。
如果不可以就要判斷當前頁數在分表中是否取不到任何一條數據，如果是則直接取老表數據（比如現在要取第 5 頁的數據，分表中一共才只有 2 頁數據，所以第 5 頁數據只能全部從老表中獲取）。
但如果分表和老表都存在一部分數據時，則需要同時取兩張表然后做一個匯總再返回。
這種邏輯只適用于根據分表字段進行查詢分頁的前提下
我想肯定會有朋友提出這樣是否會有性能問題？
同時如果在計算分表分頁數量時出現并發寫入的情況，導致分頁數量不準從而對后續的查詢出現影響該怎么處理？
首先第一個性能問題：
其實這個要看怎么取舍，為了這樣的兼容目的其實會比常規查詢多出幾個步驟：
判斷當前頁是否可以在分表中查詢。
當新老表中都有數據時候需要額外多查詢一張大表。
第一個判斷邏輯其實是在內存中計算，這個損耗我覺得完全可以忽略不計。
至于第二步確實會有損耗，畢竟多查了一張表。
但在分表之前所有的數據都是從老表中獲取的，當時的業務也沒有出現問題；現在多的只是查詢分表而已，但分表的數據量肯定要比大表小的多，而且有索引，所以這個效率也不會慢多少。
而且根據局部性原理及用戶的使用習慣來看，老表中的數據很少會去查詢，隨著時間的推移所有的數據肯定都會從分表中獲取，逐漸老表就會成為歷史表。
而第二個并發帶來的問題我覺得影響也不大，一定要這個分頁準的前提肯定得是加鎖了，但為了這樣一個不癢的小問題卻帶來性能的下降，我覺得是不劃算的。
而且后續我們也可以慢慢的將老表的數據遷移到新表，這樣就可以完全去掉這個兼容邏輯了，所有的數據都從分表中獲取。
總結還是之前那句話，這里的各種操作、方法不適合所有人，畢竟脫離場景都是耍牛氓。
比如分表搞的早，業務上允許一定的時間將數據遷移到分表那就不會有這次的兼容處理。
甚至一開始業務規劃合理、團隊架構師看的長遠，一來就將關鍵數據分表存儲那根本就不會有數據遷移這個流程（大廠有經驗的團隊可能，小公司小作坊都得靠自己摸索）。
這段期間也被數據庫折騰慘了，數據庫是最后一根稻草果然也不是瞎說的。
你的點贊與分享是對我最大的支持
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/77737.html
摘要：但對于整個事件流上的別的元素來說，執行順序還會受到另外一個因素的影響。以上面的場景為例，在捕獲階段執行的事件，如果執行，則事件流終止，不會到達目標階段，的世界則不會被執行執行結果為線上參考事件流 向dom綁定事件的事件的三種方式 行內綁定 按鈕 js內綁定 btnDom.onclick = function clickHandler() { console.log(click)...
摘要：前端渲染過程的二三事本文不會介紹整個前端渲染過程的步驟，只是記錄最近閱讀的文章的些許思考和感悟。那么現在我們可以明白這個問題的關鍵所在了，因為在大部分頁面中是擁有的，而由于其解析順序，那么在事件之前必定已經成功構造樹。 前端渲染過程的二三事 本文不會介紹整個前端渲染過程的步驟，只是記錄最近閱讀的文章的些許思考和感悟。（文章地址一（系列）,文章地址二） 希望大家在閱讀這篇文章之前能將上述...
摘要：規范定義來自于發布的一個規范。其中的字母是進制表示，大小寫無關。在里面的使用的例子其中，最后的個字符就是我電腦網卡的地址版本安全的安全的和基于時間的算法相同，但會把時間戳的前位置換為的或。 一、簡介 UUID，是Universally Unique Identifier的縮寫，UUID出現的目的，是為了讓分布式系統可以不借助中心節點，就可以生成UUID來標識一些唯一的信息； GUID，...
閱讀 992·2023-04-25 14:20
閱讀 1868·2021-11-24 10:20
閱讀 3765·2021-11-11 16:55
閱讀 2905·2021-10-14 09:42
閱讀 3466·2019-08-30 15:56
閱讀 1143·2019-08-30 15:55
閱讀 1063·2019-08-30 15:44
閱讀 771·2019-08-29 11:28
