拆分業務和資料庫應用方案

前言

此篇文章將會介紹乙個在實際應用中的解決方案

這些方案是這些專案或者系統在當時的情況下做出的最優解，我會詳細介紹我們是面臨怎樣的問題並且怎樣解決這些問題，或許它不是最優或者是最合理的方式，但是這篇文章或許能為您帶來一些靈感。

此外，我發布的文章一定是在專案中使用過的解決方案，是經過時間驗證的，我們可以通過分析這些案例，來為我們下一次的方案提供正面或者反面教材。

如果您有更好的已經實際使用過的方案願意提供給我們，我們很高興為您的方案給與酬勞。

這個系統只是眾多業務系統中的乙個，並且處於所有資料流的末端，嚴格上來說他是乙個報表系統，在我接手時，它已經開發完成。

spring cloud + nacos + redis +mysql

我們大致上使用了以上工具構成了專案框架主題

我們需要新建一次考試，分配考場和考號，之後需要匯入學生的成績資料，通過演算法計算後生成學生的行為分析模型，通過這些行為模型，系統會提供給學生或者老師能夠使用的統計報表

5.面臨的問題詳情

1.資料業務流程完全寫死在**中，並沒有流程視覺化或者可操作的流程控制，導致後面接手的人員幾乎無法理解業務。

2.報表資料需要經過10張表的洗禮才能夠使用，其中牽扯的狀態不下十個，導致表之間的關係難以理解，並且排查資料生成的過程**現的問題難度很大。

3.在報表統計中常常需要關聯很多張表查詢才能得到全部範圍的資料或者部分資料，這讓查詢變得緩慢。

4.牽扯眾多的前置業務系統，通常該系統需要等待前置系統的業務資料生成，之後才能去獲取資料進行出來，系統之間的頻繁交換資料，導致了資料常常出現缺失或者其他異常情況，這讓這個系統十分的不穩定

5.業務介面的查詢源頭混亂，難以統一維護。

業務層面：

報表系統應該專注於他的報表業務，在生成報表資料的流程中，我們有很多步驟都巢狀了其他系統的資料，但是反觀一想，這些資料都是作為必須的前置條件，他們之間的聯絡相當緊密，但他們實質上能夠分離出來作為生成報表資料的第一步。

既然我們在業務上讓所有前置條件業務在概念上都歸為一步，那為什麼不能將下一步，也就是報表資料單獨成立一張表，這張表中只儲存已生成的未出現錯誤的報告呢？

1.我們決定把建立考試到演算法計算這個流程化零為整，他們都是同乙個工作，資料生成或者清洗

2.新建一張真正的報表表儲存靜態資料。

2.業務流程

3.核心說明

1.rep_detail表是一張非關係型的結構，他儲存的資料是每一次考試每一科目每個人的每道題的答題情況，在統計報表時，只需要切換欄位和資料範圍，就能得到業務介面想要的報表資料，他根本不需要與其他表進行連表查詢，所有的查詢入口都應該是eval_exam，在此處，我們甚至不需要去關心eval_exam_subject,因為我們的rep_detail中擁有eval_exam_subject中的一切。

2.既然現在我們無需擔心業務介面獲取資料的方式，那我們剩下的就是維護好核心演算法計算前的資料準備工作，準備好所需的資料並對他們進行清洗是乙個複雜並且帶有挑戰的業務。

3.在資料準備過程中幾乎沒有流程來控制業務，只有上一步的成功與否，更加利於排查錯誤。

1.主要問題

1.red_detail中常常一次考試便會生成幾十萬條資料，資料庫由此變得緩慢。

2.red_detail欄位的多樣性，讓業務sql變得複雜和難以理解。

2.如何解決問題

1.更換mysql資料庫引擎為myisam，此時我們的靜態表rep_detail不再需要事務來保證它的安全，因為它的資料經過預清洗保證了資料的有效性，從而讓新增資料變得更快。

2.增加mysql索引，讓複雜的查詢sql變得更快。

3.我們在**中的web層增加了redis，讓介面除第一次查詢之外均能保證響應速度（由於索引原因，第一次查詢最糟糕的介面最長等待時間為10s）。

4.我們的新設計和結構讓資料脫離了業務，也讓業務能夠離開資料，當介面變得難以維護時或者其他系統進行了大幅度的改動，這個介面的重寫工作為因為我們的設計變得輕鬆，新接手的人員只需要理解rep_detail的字段意思和介面業務，就能夠直接重寫介面，而不需要擔心其中會有某些沒注意到的業務細節或者與其他系統的關係。

資料庫拆分

一 水平切分是指，以某個欄位為依據 例如id 按照一定規則 例如取模 將乙個庫 表 上的資料拆分到多個庫 表 上，以降低單庫 表 大小，達到提公升效能的目的的方法，水平切分後，各個庫 表 的特點是 1 每個庫 表 的結構都一樣 2 每個庫 表 的資料都不一樣，沒有交集 3 所有庫 表 的並集是全量資...

資料庫拆分

1.第一步 採用分布式快取redis memcached等降低對資料庫的讀寫操作 2.第二步 如果快取使用過後，資料庫訪問量還是非常大，可以考慮資料庫讀寫分離原則。3.第三步 當我們使用讀寫分離 快取後 資料庫的壓力還是很大的時候，這就需要使用資料庫的拆分了。乙個資料庫由很多表構成，每個表對應著不同...

資料庫拆分

資料庫水平垂直拆分 當資料庫量非常大的時候，db已經成為系統瓶頸時就可以考慮進行水平垂直拆分了。水平拆分 一般水平拆分是根據表中的某乙個字段 主鍵id 進行取模處理，將表中的資料拆到多張表裡，這樣每張表的結構相同但資料不同。不但可以根據id取模分表也可以按時間分表，比如每月生成一張表。按照範圍分表也...