資訊專欄INFORMATION COLUMN
摘要：個人對分布式系統的涉及很感興趣，但分布式系統涉及的知識非常多，剛開始學習時也是各個點分散的學習。前兩天對于數據拆分這一塊做了一個總結，因此記錄下來。
個人對分布式系統的涉及很感興趣，但分布式系統涉及的知識非常多，剛開始學習時也是各個點分散的學習。前兩天對于數據拆分這一塊做了一個總結，因此記錄下來。
技術出現的原因都是為了解決問題，本文章也是按照這個思路去探討的。
為什么需要將數據庫內的數據進行拆分一臺機器的處理能力有限，當數據量大了后性能下降，而且硬件單機成本不高。
如何拆分垂直分庫(根據業務單元的不同把表分到不同的主機，單臺機器能夠處理的請求數量有限)
水平分表(當一張表的數據多了之后查詢效率就會很慢，可以根據字段范圍劃分不同的表，學生表的id字段，1~10000分為一張表，10000~20000分為另一張表)
拆分帶來的問題單機ACID打破，引入了分布式事務(難點)
join操作困難，查詢跨庫
自增id受到困難
解決方案
分布式事務：兩階段提交(2pc),大概意思就是分布式系統中有一個事務管理器(TM),執行分布式事務時向每個資源申請，資源返回全都OK后再向每個資源提交事務，同樣等待每個資源返回OK后就完成事務，其中任何一個環節出現erro則回滾。 壞處很明顯性能太差，高并發系統根本不能使用。
業界現使用消息隊列來解決分布式事務(RocketMQ)具體步驟如下：
1.MQ發送方發送消息到MQServer
2.MQServer接收并回應,表明以成功到達
3.MQ發送方Commit本地事務
4.若Commit成功則通知MQServer該消息可被消費，失敗則表明該消息應被丟棄
5.若MQ發送方超時未對MQServer發送狀態，則主動回查事務狀態
跨庫join操作：轉化為多個數據庫的查詢，我們設計數據庫時也應盡量避免產生跨庫操作。
自增id：多帶帶做一個id生成器的服務，對于每次請求還可以分配一段id，減少請求次數，增加速度。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/68040.html
摘要：為了幫助用戶更好地完成消費決策閉環，馬蜂窩上線了大交通業務。現在，用戶在馬蜂窩也可以完成購買機票火車票等操作。第二階段架構轉變及服務化初探從年開始，整個大交通業務開始從架構向服務化演變。 交通方式是用戶旅行前要考慮的核心要素之一。為了幫助用戶更好地完成消費決策閉環，馬蜂窩上線了大交通業務。現在，用戶在馬蜂窩也可以完成購買機票、火車票等操作。 與大多數業務系統相同，我們一樣經歷著從無到有...
閱讀 1890·2021-11-24 09:39
閱讀 2535·2021-10-14 09:43
閱讀 3318·2021-10-08 10:10
閱讀 2266·2021-09-22 15:54
閱讀 2340·2019-08-29 17:20
閱讀 1573·2019-08-28 18:14
閱讀 2374·2019-08-26 13:28
閱讀 1111·2019-08-26 12:16
