對于拆分的解決方案這塊,上節課我們講到了如何去拆分,然后拆分有些問題,引入了一系列的問題,比如說分布式事務的問題,關于分布式事務這個事啊,其實挺不好解決的,就是根據情況吧,咱們在這里說三個方案,你針對不同的場景去分析,然后你說業務邏輯很復雜的時候,你就采用SOA通用服務的形式,在service上加多個事務的切面,就可以去解決第二種情況就比如數據量非常大的時候,數據量大且邏輯復雜的時候,就是不僅僅是邏輯復雜了,并且數據量也很大,那你那個時候使用SOA服務,就不太好了,因為有個問題,早期的時候沒有SOA的這種dubbo,你可能就是一次http請求唄,其實就是類似于http請求的,你去訪問一個數據源的時候,你比如你一次dubbo請求,這是咱們的WEB程序,然后你要訪問對應的SOA服務,SOA端,訪問這里邊的某一個方法,你說你這個業務復雜沒什么,因為JAVA很快,但是如果你要是數據量大的時候,比如我這里request的信息非常多,就是幾十條,上百條,然后這邊肯定得處理啊,那這個過程就很慢了,再給你做出響應,你這個時候業務復雜并且數據量大的時候,不適合這個東西的,那應該采用什么方案呢,就是不用這個SOA了,我就采用中間庫的解決方案,就類似于兩個系統之間,我這個系統可以同步到數據庫上,他們兩個可以當做什么也沒有發生,如果我說的那種情況,定時可以把數據放到庫里,這個系統再定時的去這個庫里去取數據,這樣就很大了,能不能說只要關心自己的業務就行了,其實還有一種方案就是,這是一個系統,這是一個系統,我這邊就是我中間的數據庫,這邊有一個數據源數據庫,這是我們的系統B,這是我們的系統A,我自己也可以寫一個應用服務,這個worker服務是用來調度的,他主要是負責放在這里面,并且是負責把數據挖取出來,然后再放到這里,其實都可以,如果你性能不是要求這么高的話,數據量很大,實時性要求不是那么高的話,你可以用一個worker去做,去做這個協調,或者這里提供一個定時JOB,這里也提供一個定時JOB,這都行,就是類似于跨庫的物化視圖,也可以去做實時的更新,還有一種其他的,要求實時性非常高的怎么辦,你要求實時性非常高了,那你就得去寫第三方的中間件,依賴于第三方組件,zookeeper,或者你自己寫一個,或者是用這個netty,兩個系統直接通信,或者你要求非常實時,要求很實時,這幾種方案都不行,那你只能是rest服務了,提供接口,我這邊去調,前提是數據量一定別太大,第三種方案就是數據量別太大,數據量大的話還是要用中間件導一下是分布式怎么去解決 然后下面是跨節點join的問題,是一些合并啊,排序啊,分頁啊,這些東西怎么辦,通用的方案是把數據組織好,放到緩存中,關系型數據庫和緩存定時的去同步,然后你要求不是特別高的話,可以使用中間庫去解決,我們工作中就是用中間庫去解決跨節點join的問題,舉個例子,比如說這里有一個系統,里邊有一張表,然后我中間有一個數據庫,這里是A庫,這里是B庫,然后這里是C什么庫,我這里建一個物化視圖,咱們之前剛學,物化視圖把這里的數據同步過來,把這里的數據同步過來,只要兩邊有commit,我這邊物化視圖就刷新,由于物化視圖真正存在物理結構里,你如果并發太高的話,肯定扛不住,高不高怎么說呢,這個取決于什么呢,我覺得我們現在用的還可以,其實沒有什么大的問題,并發高的話就相當高了,幾萬次這個并發就比較高了,那就不太適合了,并發高的意思就是,這邊B系統一萬個用戶,10萬個用戶,10萬個用戶去修改這張表,并發高,這邊肯定需要實時的刷新,把心刷新的數據存在物理的磁盤里,包括這邊也再來多點,來個10萬個,就特別頻繁特別頻繁的,只要一commit,我這個物化視圖就得更新,并發不是特別高的情況下,數據量大,并發不是很高,所以你可以用物化視圖解決方案,ON COMMIT或者是 ON DEMAND,每一小時我就同步一下,每隔一小時我就刷一次,就是每隔一分鐘刷一次也可以,或者每隔一秒鐘你就刷一次,這都行,就是別一秒鐘數十萬的并發,ORACLE肯定是扛不住的,或者你用一些其他的工具,同步的工具,那個性能應該是可以的,應該是可以的,數據源管理的問題,我這個數據源一多,我這里怎么去管理呢,可以去使用第三方的MYCAT,目前并不是很成熟,以后咱們可以考慮去使用,或者是你是正常的,一個模塊你管理自己的數據源,這樣就可以了,大不了我在zookeeper上寫一個配置文件,把所有的數據源都列上來,提供一個公共的用戶,訪問界面,操作數據源的更新,修改,你要寫自己的一個小系統了,去維護這個數據源,也是可以的,這就是解決方案簡單的說一下,今天主要是講分區,

?

總結

以上是生活随笔為你收集整理的Oracle之垂直水平分库分表（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。