本章介紹分布式架構(gòu)的底層技術(shù)。主要說明面試過程中可能被問到的技術(shù)點(diǎn)。
分庫分表Sharding
垂直切分，也就是因?yàn)楸矶喽鴶?shù)據(jù)多，將關(guān)系緊密（比如統(tǒng)一模塊）的表切分出來放到一個(gè)服務(wù)器中
水平切分，表不多，而是表中數(shù)據(jù)量龐大，也就是把表的數(shù)據(jù)按照某種規(guī)則切分到多個(gè)服務(wù)器中
現(xiàn)實(shí)中多是這兩種的混合
事務(wù)問題
解決方案一：使用分布式事務(wù)；優(yōu)點(diǎn)是，由數(shù)據(jù)庫管理，簡單有效；缺點(diǎn)是，性能代價(jià)高
解決方案二：將分布式事務(wù)拆分成單個(gè)數(shù)據(jù)庫的小事務(wù)，通過程序來總控各個(gè)小事務(wù)；優(yōu)點(diǎn)，性能好一些；缺點(diǎn)，代碼耦合高
跨節(jié)點(diǎn)join的問題
只要是進(jìn)行切分，跨節(jié)點(diǎn)Join問題不可避免。但良好的設(shè)計(jì)和切分可以減少此類情況的發(fā)生
普遍的解決方案是分兩次查詢，第一次查詢找出關(guān)聯(lián)數(shù)據(jù)的ID，然后根據(jù)這些ID發(fā)起第二次的查詢
跨節(jié)點(diǎn)的count、order by、group by以及聚合函數(shù)問題
這是一類問題，因?yàn)樗鼈兌夹枰谌繑?shù)據(jù)進(jìn)行計(jì)算，而多數(shù)的代理都不會(huì)自動(dòng)處理合并工作
解決方案與跨節(jié)點(diǎn)Join一樣，分別在各個(gè)節(jié)點(diǎn)得到結(jié)果后在應(yīng)用程序進(jìn)行合并，不同的是每個(gè)節(jié)點(diǎn)的查詢可以并行執(zhí)行
數(shù)據(jù)遷移、容量規(guī)劃、擴(kuò)容的問題
ID問題
一旦數(shù)據(jù)庫被切分到多個(gè)物理節(jié)點(diǎn)上，我們將不能再依賴數(shù)據(jù)庫自身的主鍵生成機(jī)制。一方面，某個(gè)分區(qū)數(shù)據(jù)庫自生成的ID無法保證全局唯一性；另一方面，應(yīng)用程序在插入數(shù)據(jù)之前要先獲取到ID，以便對SQL進(jìn)行路由
以下是常見的主鍵生成策略
UUID，簡單，但是數(shù)據(jù)過長，占空間，而且建索引和基于索引進(jìn)行查詢都有性能問題
基于數(shù)據(jù)庫維護(hù)一個(gè)Sequence表，表的壓力會(huì)很大，而且有單點(diǎn)問題，一旦發(fā)生故障，整個(gè)應(yīng)用程序?qū)o法使用
Twitter的分布式自增ID算法Snowflake
跨節(jié)點(diǎn)的排序分頁
一般來說，分頁時(shí)需要按照指定字段進(jìn)行排序。當(dāng)排序字段就是分片字段時(shí)，我們根據(jù)分片規(guī)則可以比較容易定位到指定的分片，當(dāng)排序字段不是分片字段時(shí)，情況就比較復(fù)雜了。為了最終結(jié)果的準(zhǔn)確性，我們需要在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，并將不同分片的結(jié)果集進(jìn)行匯總和再次排序，最后再返回給用戶
如果只是取第一頁的數(shù)據(jù)，看起來對性能的影響并不大。但是，如果取第10頁的數(shù)據(jù)，情況將復(fù)雜的多。
因?yàn)楦鞣制?jié)點(diǎn)的數(shù)據(jù)都是隨機(jī)的，為了排序的準(zhǔn)確性，必須把所有分片節(jié)點(diǎn)的前N頁數(shù)據(jù)都排序好后做合并，最后再進(jìn)行整體的排序。特別的消耗資源，分頁頁碼越大，性能越差。
解決方案如下：
在前端做分頁，并且限定只能看前n的數(shù)據(jù)
如果是后臺(tái)程序要獲取分頁數(shù)據(jù)，可以加大page size，比如獲取5000條記錄，有效減少分頁數(shù)
分庫設(shè)計(jì)時(shí)，配套大數(shù)據(jù)平臺(tái)匯總所有分庫的記錄，有些分頁查詢可以走大數(shù)據(jù)平臺(tái)
分庫數(shù)量
分庫數(shù)量和彈庫能處理的記錄數(shù)有關(guān)，一般來說，MySql單庫超過5000萬條記錄，Oracle單庫超過1億條記錄，DB壓力就很大。一般建議初次分庫數(shù)量為4-8個(gè)庫
XA規(guī)范
主要定義了（全局）事務(wù)管理器（Transaction Manager）和（局部）資源管理器（Resource Manager）之間的接口。XA接口是雙向的系統(tǒng)接口，在事務(wù)管理器和一個(gè)或多個(gè)資源管理器之間形成通信橋梁
事務(wù)管理器控制著全局事務(wù)，管理事務(wù)生命周期，并協(xié)調(diào)資源
資源管理器負(fù)責(zé)控制和管理實(shí)際資源
JTA（Java Transaction API）
Java平臺(tái)上的事務(wù)規(guī)范，它僅定義了接口，具體實(shí)現(xiàn)則由具體的提供商來實(shí)現(xiàn)
兩階段提交
第一階段，準(zhǔn)備階段：事務(wù)協(xié)調(diào)者（事務(wù)管理器）給每個(gè)參與者（資源管理器）發(fā)送Prepare消息，每個(gè)參與者要么直接返回失敗，要么在本地執(zhí)行事務(wù)，寫本地的redo和undo日志，但不提交
第二階段，提交階段：如果協(xié)調(diào)者收到了參與者的失敗消息或者超時(shí)，直接給每個(gè)參與者發(fā)送回滾（Rollback）消息，否則，發(fā)送Commit消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行回滾或提交操作，并釋放所有事務(wù)處理過程中的鎖資源
優(yōu)點(diǎn)：效率高
缺點(diǎn)：當(dāng)事務(wù)的并發(fā)量達(dá)到一定數(shù)量時(shí)，會(huì)出現(xiàn)大量的事務(wù)積壓甚至出現(xiàn)死鎖，系統(tǒng)性能會(huì)嚴(yán)重下降
一階段提交（Best Efforts 1PC模式）
就是從應(yīng)用程序向數(shù)據(jù)庫發(fā)出請求到數(shù)據(jù)庫完成提交或回滾之后將結(jié)果返回給應(yīng)用程序的過程，非常直白
事務(wù)補(bǔ)償機(jī)制
像Best Efforts 1PC模式，前提是應(yīng)用程序能獲取所有的數(shù)據(jù)源，然后使用同一個(gè)事務(wù)管理器（指Spring的事務(wù)管理器）管理事務(wù)，最典型的應(yīng)用場景是數(shù)據(jù)庫sharding
對于那些基于WebService、RPC、JMS等高度自治的分布式系統(tǒng)接口，Best Efforts 1PC無能為力，可以通過事務(wù)補(bǔ)償機(jī)制來實(shí)現(xiàn)最終一致性
創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開啟，新人活動(dòng)云服務(wù)器買多久送多久。
重慶分公司
重慶分公司
