菜鸟架构笔记：上部
目錄
- 從零開始學(xué)架構(gòu)
- 李運(yùn)華|著
- 程序設(shè)計(jì)與架構(gòu)設(shè)計(jì)
- 架構(gòu)即人性！切勿好大喜功。
- 組件與模塊
- 框架Framework和架構(gòu)Architecture
- 高**的誤區(qū)
- 以史為鑒
- 架構(gòu)設(shè)計(jì)的主要目的
- 高屋建瓴，有的放矢，而非貪大求全
- 任務(wù)分配器與業(yè)務(wù)服務(wù)器
- 系統(tǒng)的高可用
- 數(shù)據(jù)+邏輯=業(yè)務(wù)
- CAP定理
- 高可用狀態(tài)決策
- 可擴(kuò)展性
- 創(chuàng)新
- 安全
- 規(guī)模
- 名詞解釋
- 規(guī)范
- 建筑
- 備選方案
- 關(guān)系數(shù)據(jù)庫
- CAP
- CAP理論的實(shí)踐
- 正常情況下，不存在CP和AP的選擇（即：當(dāng)P可以舍棄時(shí)），可以同時(shí)滿足CA。
- 分區(qū)期間（一年可能5分鐘（4個(gè)9）、50分鐘（5個(gè)9））
- BASE
- FMFA（Failure mode and effects analysis）故障模式與影響分析
- 存儲高可用
- 主備倒換（主讀寫，備備份）與主從倒換（主讀寫，從讀）
- 開源的數(shù)據(jù)集中集群
- 數(shù)據(jù)分散集群
- 分布式事務(wù)算法
- 分布式一致性算法
- 數(shù)據(jù)分區(qū)
- 復(fù)制規(guī)則
- 計(jì)算高可用
- 主備
- 主從
- 對稱集群與非對稱集群
- 業(yè)務(wù)高可用
- 異地多活設(shè)計(jì)步驟
- 3.數(shù)據(jù)同步
- 4.異常處理
從零開始學(xué)架構(gòu)
照著做，你也能成為架構(gòu)師
李運(yùn)華|著
技術(shù)成就夢想，堅(jiān)持就能成功
程序設(shè)計(jì)與架構(gòu)設(shè)計(jì)
程序設(shè)計(jì)的關(guān)鍵思維是邏輯和實(shí)現(xiàn)。
架構(gòu)設(shè)計(jì)的關(guān)鍵思維是判斷和取舍。
架構(gòu)即人性！切勿好大喜功。
三大原則：
《UNIX編程藝術(shù)》Kiss：KeepItSimple，Stupid！
系統(tǒng)是其內(nèi)部的諸多有關(guān)聯(lián)的個(gè)體按照相應(yīng)的規(guī)則
運(yùn)行出的具備新的能力的東西。
組件與模塊
從邏輯的角度來拆分系統(tǒng)得到的單元是模塊
從物理的角度來拆分系統(tǒng)得到的單元是組件
劃分模塊的主要目的是職責(zé)劃分
劃分組件的主要目的是單元復(fù)用
component組件，零件，屬于物理范疇。
框架Framework和架構(gòu)Architecture
不同角度理解問題，所抽象出的概念是不同的。
高**的誤區(qū)
不能一味的追求高性能、高可用和高擴(kuò)展！
Done is better than perfect!
以史為鑒
探索一個(gè)事務(wù)的目的，最好的方式就是去追尋這個(gè)事物出現(xiàn)的
歷史背景和推動因素。
屁股決定腦袋，位置決定想法。
事物的量級達(dá)到一定程度后，問題也會***變質(zhì)***。
模塊、對象再到組件，差別是隨著軟件的復(fù)雜度不斷增加，拆分
的粒度越來越粗，拆分的角度越來越高。
架構(gòu)設(shè)計(jì)的主要目的
是為了解決復(fù)雜度帶來的問題。
低成本是架構(gòu)設(shè)計(jì)的附加約束。
高屋建瓴，有的放矢，而非貪大求全
不同架構(gòu)應(yīng)該針對不同的復(fù)雜點(diǎn)。
任務(wù)分配器與業(yè)務(wù)服務(wù)器
任務(wù)分配隨著量級的增加，性能損耗越來越高，整體收益會大打折扣。
任務(wù)分解，拆大為小，進(jìn)而更容易找到關(guān)鍵性能點(diǎn)進(jìn)行突破，且不會
牽一發(fā)而動全身，方便調(diào)優(yōu)。
拆分后的子系統(tǒng)之間交流也有成本，所以拆分的粒度要適度。
系統(tǒng)的高可用
通過冗余實(shí)現(xiàn)無中斷。相當(dāng)于功能備份。
存儲高可用的難點(diǎn)不在于如何備份數(shù)據(jù)，而在于如何減少或規(guī)避數(shù)據(jù)不一致
對業(yè)務(wù)造成的影響。
數(shù)據(jù)+邏輯=業(yè)務(wù)
即便是毫秒級別的傳輸延時(shí)，也會照成數(shù)據(jù)的不一致，進(jìn)而導(dǎo)致業(yè)務(wù)出現(xiàn)問題。
CAP定理
consistency
available
partitionTolerance
存儲高可用不可能同時(shí)滿足一致性、可用性、分區(qū)容錯(cuò)性，最多滿足
其中兩個(gè)，在做架構(gòu)設(shè)計(jì)時(shí)要結(jié)合業(yè)務(wù)進(jìn)行取舍。由于網(wǎng)絡(luò)延時(shí)等不可避免，
所以通常在一致性與可用性之間進(jìn)行取舍。
高可用狀態(tài)決策
獨(dú)裁式：一個(gè)決策者與多個(gè)上報(bào)者
協(xié)商式：主從通信問題
民主式：投票選舉，腦裂混亂問題
可擴(kuò)展性
設(shè)計(jì)模式
正確預(yù)測變化，完美封裝變化。
唯一不變的是變化
變與不變，穩(wěn)定層與變化層的確立。
創(chuàng)新
小公司引入新技術(shù)，大公司創(chuàng)造新技術(shù)。
安全
功能上的安全，在攻與防的矛盾中逐步完善。
架構(gòu)上的安全
防火墻一般不適用海量用戶訪問與高并發(fā)。
運(yùn)營商或云服務(wù)商具備強(qiáng)大的帶寬和流量清洗能力。
規(guī)模
規(guī)模的線性增加帶來的是復(fù)雜度的指數(shù)增加。
數(shù)據(jù)越來越多，系統(tǒng)復(fù)雜度也會由量變帶來質(zhì)變。
大數(shù)據(jù)的三架馬車。
傳統(tǒng)mysql推薦單表5000萬行左右。
名詞解釋
CDN:Content Delivery Network
GSLB:Global Server Load Balance
規(guī)范
憑借個(gè)人經(jīng)驗(yàn)與感覺設(shè)計(jì)架構(gòu)。
積累自己的儲備庫。
大公司具備的平臺、資源和積累是架構(gòu)衍生的關(guān)鍵。
環(huán)境逼迫創(chuàng)新。
情境激活靈感。
建筑
對于建筑來說，永恒是主題。
對于軟件來說，變化是主題。
條條大路通羅馬，要綜合選擇。
備選方案
3-5個(gè)
幾乎沒有無暇的方案
如果你有一把錘子，那么所有的問題在你看來都是釘子。
不要被既有經(jīng)驗(yàn)局限。
備選階段關(guān)注技術(shù)選型，而不是技術(shù)細(xì)節(jié)。
360度環(huán)評：最簡派、最牛派、最熟派、領(lǐng)導(dǎo)派
極端情況的出現(xiàn)畢竟是小概率事件，留有較多余力的時(shí)候再去考慮。
舉例：
1.橫向擴(kuò)展
2.系統(tǒng)拆分
不同的方案，面對不同的公司情況，考慮問題的側(cè)重點(diǎn)應(yīng)該不同。
權(quán)值的設(shè)定應(yīng)該依具體情況而定。
按優(yōu)先級選擇。
詳細(xì)方案的設(shè)計(jì)階段可能顯露出備選方案中遺漏的關(guān)鍵點(diǎn)，進(jìn)而導(dǎo)致
備選方案全局否定。架構(gòu)師應(yīng)該在早期看的更深入。
海納百川，博采眾長。
關(guān)系數(shù)據(jù)庫
高性能數(shù)據(jù)庫集群：
- 讀寫分離：將訪問壓力分散到多個(gè)節(jié)點(diǎn)。主機(jī)讀寫，從機(jī)讀操作。
主從復(fù)制延遲問題：
1.寫操作后的讀操作指定發(fā)給主機(jī)。
2.從機(jī)讀取失敗后再讀一次主機(jī)，二次讀取會增加主機(jī)壓力。
3.關(guān)鍵業(yè)務(wù)全部指向主機(jī)，非關(guān)鍵業(yè)務(wù)由從機(jī)完成。 - 分庫分表：既分散訪問壓力，又分散存儲壓力。
join操作問題：無法使用join
事務(wù)問題：分布式事務(wù)解決方案性能不高。
成本問題：業(yè)務(wù)分庫一般后期進(jìn)行。前期業(yè)務(wù)規(guī)模小且不穩(wěn)定。 - 單表數(shù)據(jù)拆分的兩種方式：
垂直拆分：不常用的字段剝離出去。
水平拆分：如果單表行數(shù)超過5000萬，相對來說可以考慮拆分。
范圍路由：單表水平分段建議100萬到2000萬之間。
最后一張表可能導(dǎo)致分布不均。
Hash路由：所有表分布均勻，但后期擴(kuò)充要重分布。
配置路由：記錄拆分信息，利于擴(kuò)充，但多一次查詢。
拆分難點(diǎn)：粒度選取。
舉例：count()
拆分后的多個(gè)表求總記錄數(shù)，需要把每張表的count()
累加求和，性能會受到影響。引入記錄數(shù)表記錄當(dāng)前表
的行數(shù)，又會導(dǎo)致同步更新的問題，復(fù)雜度增加。
order by操作無法進(jìn)行，需要單表排序后引入中間件匯總排序。 - 讀寫分離實(shí)現(xiàn)：
程序代碼封裝：實(shí)現(xiàn)簡單，但每個(gè)語言都需要自己實(shí)現(xiàn)一次，無法通用。
如：TDDL（Taobao Distributed Data Layer）頭都大了！
中間件封裝：數(shù)據(jù)庫中間件對業(yè)務(wù)服務(wù)器提供的是標(biāo)準(zhǔn)SQL接口。
實(shí)現(xiàn)復(fù)雜，主從切換服務(wù)器無感知。
如：mysql-proxy、mysql-router、奇虎360的Atlas。 - NoSQL
關(guān)系數(shù)據(jù)庫的缺點(diǎn)：
1.無法存儲數(shù)據(jù)結(jié)構(gòu)，存儲的是行記錄。
2.schema擴(kuò)展不方便。擴(kuò)充列導(dǎo)致表長時(shí)間鎖定。
3.大數(shù)據(jù)場景下IO較高。即使是對某一列進(jìn)行統(tǒng)計(jì)，
關(guān)系數(shù)據(jù)庫也會將整行進(jìn)行讀取。
4.且全文搜索能力比較弱。
NoSQL！= no sql 而是 NoSQL = Not only sql
針對上述缺點(diǎn)常見的NoSql方案：
1.k-v存儲：Redis
2.文檔數(shù)據(jù)庫：MongoDB
3.列式數(shù)據(jù)庫：HBase
4.全文搜索引擎：Elasticsearch
1.Redis事務(wù)只支持I(是單進(jìn)程單線程的工作模式)和C，不支持
A(不支持回滾)和D.
2.no-schema的文檔數(shù)據(jù)庫，如JSON數(shù)據(jù)是自描述的，無需在使用前
定義字段，讀取一個(gè)JSON中的不存在的字段也不會導(dǎo)致SQL的語法錯(cuò)誤。
JSON比起先要執(zhí)行DDL的關(guān)系數(shù)據(jù)庫要方便更多。但某些對事務(wù)要求嚴(yán)格
的業(yè)務(wù)場景是不能使用文檔數(shù)據(jù)庫的。通常可以sql+noSql組合使用。
3.行式存儲可以同時(shí)高效讀取多個(gè)列，也可以同時(shí)在一行中對多個(gè)列進(jìn)行
寫操作。但在海量數(shù)據(jù)進(jìn)行統(tǒng)計(jì)的場景中并不適用。普通行式數(shù)據(jù)庫一般
壓縮率在3：1到5：1左右，而列式數(shù)據(jù)庫壓縮率一般在8：1到30：1左右。
4.全局搜索引擎技術(shù)原理：倒排索引。
正排索引：根據(jù)文檔名稱來查詢文檔內(nèi)容。
倒排索引：根據(jù)關(guān)鍵詞來查詢文檔內(nèi)容。
全文搜索引擎的索引對象是單詞和文檔，而關(guān)系數(shù)據(jù)庫的索引對象是鍵和行。
全文搜索引擎在支持關(guān)系型數(shù)據(jù)全文搜索時(shí)需要JSON(不唯一)與表對應(yīng)轉(zhuǎn)換。
Elasticsearch是分布式的文檔存儲數(shù)據(jù)庫。它能存儲和檢索復(fù)雜的數(shù)據(jù)結(jié)構(gòu)
————序列化稱為JSON文檔————以實(shí)時(shí)的方式。在Elasticsearch中，每個(gè)字
段的所有數(shù)據(jù)都是默認(rèn)被索引的。即每個(gè)字段都有為了快速索引設(shè)置的專用倒
排索引。而且，不像其他多數(shù)的數(shù)據(jù)庫，它能在相同的查詢中使用所有的倒排
索引，并以驚人的速度返回結(jié)果。 - 緩存
將可能重用的數(shù)據(jù)放到內(nèi)存中，一次生成，多次使用，避免每次使用都去訪問
存儲系統(tǒng)。
緩存穿透：故意訪問不存在的數(shù)據(jù)，空值替代。
生成緩存耗費(fèi)時(shí)間和資源，當(dāng)競爭對手故意爬取所有分頁時(shí)(通常
緩存前10頁比如)，會拖慢整體。
緩存雪崩：緩存失效后引起系統(tǒng)性能極具下降。
解決方法：1.更新鎖機(jī)制：加鎖保證只有一個(gè)線程進(jìn)行緩存更新。
2.后臺更新機(jī)制：后臺線程更新緩存而不是由業(yè)務(wù)線程更新緩存。
緩存本身的有效期設(shè)置為永久，后臺線程定時(shí)更新緩存。
定時(shí)讀取：頻繁查看被踢的數(shù)據(jù)，及時(shí)更新空值。
消息隊(duì)列通知：業(yè)務(wù)線程發(fā)現(xiàn)緩存丟失主動發(fā)消息
通知后臺線程更新緩存。相對簡單，且可以用于系統(tǒng)
預(yù)熱。
緩存熱點(diǎn)：某明星大咖的消息復(fù)制多份緩存，緩解服務(wù)器壓力。
PPC:Process per Connection,每次有new connection,then fork a new process. - some problems:
performance.
- solvable method:
1.prefork,which needs system solve “驚群” phenomenon.
2.TPC:Thread per Connection.
3.進(jìn)程池：
read操作改為非阻塞，然后進(jìn)程不斷地輪詢多個(gè)連接，
但這并不優(yōu)雅，且連接達(dá)到幾千上萬的時(shí)候，效率低下。
4.I/O多路復(fù)用結(jié)合線程池：Reactor 即：反應(yīng)堆（事件反應(yīng)）非阻塞
同步網(wǎng)絡(luò)模型
當(dāng)多個(gè)連接共用一個(gè)阻塞對象后，進(jìn)程只需要在一個(gè)阻塞對
象上等待，而無需再輪詢所有的連接。
當(dāng)某條連接有新的數(shù)據(jù)可以處理時(shí)，操作系統(tǒng)會通知進(jìn)程，
進(jìn)程從阻塞狀態(tài)返回，開始進(jìn)行業(yè)務(wù)處理。
Reactor模式也稱為Dispatcher模式，即：I/O多路復(fù)用
統(tǒng)一監(jiān)聽事件，收到事件后分配給某個(gè)進(jìn)程。
實(shí)用類型：單Reactor單進(jìn)程/單線程。
單Reactor多線程。
多Reactor多進(jìn)程/線程。
上述具體線程還是進(jìn)程依具體編程環(huán)境及平臺有
關(guān)。java一般使用多線程。
5.Proactor 前攝器 類比proactive主動的，主動器
Reactor：來了事件我通知你，你來處理。
Proactor：來了事件我來處理，處理完了我通知你。
解釋：”我“是操作系統(tǒng)，”事件“是新的連接、有數(shù)據(jù)可讀、數(shù)據(jù)可寫。
流程：
1.Proactor Initiator負(fù)責(zé)創(chuàng)建Proactor和Handler，并
將Proactor和Handler都通過Asynchronous Operation
Processor注冊到內(nèi)核。
2.Asynchronous Operation Processor負(fù)責(zé)處理注冊請
求，并完成I/O操作后通知Proactor。
3.Asynchronous Operation Processor完成I/O操作后
通知Proactor。
4.Proactor根據(jù)不同的事件類型回調(diào)不同的Handler進(jìn)行
業(yè)務(wù)處理。
5.Handler完成業(yè)務(wù)處理，Handler也可以注冊新的
Handler到內(nèi)核進(jìn)程。
目前windows下采用IOCP，而linux采用Reactor模式為主
因?yàn)閘inux下的AIO并不完善。
集群高性能：負(fù)載均衡不只是為了計(jì)算單元的負(fù)載達(dá)到均衡狀態(tài)，而是一種綜合的考慮。 - DNS負(fù)載均衡
地域級別的均衡。就近原則。 - 硬件負(fù)載均衡
集群級別負(fù)載均衡。昂貴，擴(kuò)展能力大。 - 軟件負(fù)載均衡
機(jī)器級別負(fù)載均衡。通過軟件實(shí)現(xiàn)負(fù)載均衡功能。 - 負(fù)載均衡算法
任務(wù)平分類：輪詢
負(fù)載均衡類：權(quán)重輪詢
性能最優(yōu)類：按服務(wù)器性能分配，適當(dāng)概率判斷服務(wù)器性能
Hash類：同IP或者同session id歸屬到同一服務(wù)器
CAP
- What is Partition Tolerance?
System continues to work despite message loss or partial failure.
The System will continue to function when network partitons occur.
- What is CP?當(dāng)發(fā)生分區(qū)時(shí)，返回錯(cuò)誤。
- What is AP?當(dāng)發(fā)生分區(qū)時(shí)，返回錯(cuò)誤值。
CAP理論的實(shí)踐
- 需要將系統(tǒng)內(nèi)的數(shù)據(jù)按照不同的應(yīng)用場景和要求進(jìn)行分類，每類數(shù)據(jù)選擇不同的的策略。
- 比如：用戶信息數(shù)據(jù)選擇AP，而用戶賬號數(shù)據(jù)選擇CP。
- AP相當(dāng)于是放寬了一致性的要求，可用就好。CP由于追求強(qiáng)一致性而導(dǎo)致不可用情況發(fā)生。
- CAP是忽略網(wǎng)絡(luò)延遲的。有時(shí)強(qiáng)一致性的要求導(dǎo)致只能單點(diǎn)寫入，其他節(jié)點(diǎn)備份，無法做到分布式情況下多點(diǎn)寫入。但并不意味著系統(tǒng)無法應(yīng)用分布式架構(gòu)，可以兩個(gè)節(jié)點(diǎn)各自負(fù)責(zé)一半業(yè)務(wù)，同時(shí)備份另一半。這樣即便其中一個(gè)節(jié)點(diǎn)發(fā)生故障，也只是影響一半的用戶。
正常情況下，不存在CP和AP的選擇（即：當(dāng)P可以舍棄時(shí)），可以同時(shí)滿足CA。
- 此情況我們需要考慮分區(qū)發(fā)生情況下的CP與AP的選擇，同時(shí)也要考慮P沒有發(fā)生情況下的CA的實(shí)現(xiàn)。
- 不同的數(shù)據(jù)CA實(shí)現(xiàn)方式可能不一樣，比如：用戶賬號數(shù)據(jù)可以采用消息隊(duì)列，因?yàn)榭梢员容^好的控制實(shí)時(shí)性。而用戶信息數(shù)據(jù)可以采用數(shù)據(jù)庫同步的方式來實(shí)現(xiàn)，因?yàn)閷?shí)現(xiàn)簡單。
分區(qū)期間（一年可能5分鐘（4個(gè)9）、50分鐘（5個(gè)9））
- 分區(qū)發(fā)生，則記錄相關(guān)日志。
- 分區(qū)故障解決后，系統(tǒng)根據(jù)日志進(jìn)行數(shù)據(jù)恢復(fù)。
- CAP關(guān)注的粒度是數(shù)據(jù)，而不是整個(gè)系統(tǒng)。
BASE
- Basically Available 登錄比注冊重要。
- Soft State 允許數(shù)據(jù)存在中間狀態(tài)（CAP理論中的數(shù)據(jù)不一致），但不影響系統(tǒng)整體可用性。
- Eventual Consistency 系統(tǒng)中的所有副本經(jīng)過一定時(shí)間后，最終能夠達(dá)到一致性的狀態(tài)。是對AP方案的一個(gè)補(bǔ)充。
FMFA（Failure mode and effects analysis）故障模式與影響分析
- 是一套分析和思考的方法，應(yīng)用于各個(gè)領(lǐng)域。
- 像登錄、注冊才是功能點(diǎn)。
- 故障模式關(guān)注現(xiàn)象和對應(yīng)影響，即便原因不同。盡量使用量化描述，而非泛化。
- 對于故障現(xiàn)象，殊途同歸，殊因同果，應(yīng)不同對待。
存儲高可用
主備倒換（主讀寫，備備份）與主從倒換（主讀寫，從讀）
- 問題關(guān)鍵點(diǎn)：狀態(tài)判斷、倒換決策和數(shù)據(jù)沖突修復(fù)。
- 互連式與中介式（MongoDB(A)）,還有模擬式（將備機(jī)模擬為客戶端進(jìn)而判別主機(jī)狀態(tài)）。
- 主主倒換需要雙向復(fù)制。
開源的數(shù)據(jù)集中集群
- ZooKeeper，ZAB協(xié)議，開源
數(shù)據(jù)分散集群
- 均衡性
- 容錯(cuò)性
- 可伸縮性
- Hadoop，Namenode是一個(gè)中心服務(wù)器，負(fù)責(zé)數(shù)據(jù)分區(qū)的分配。HDFS，master/slave.
分布式事務(wù)算法
- 2PC（Two-phase commit protocol）
- 提交請求階段，看看是否有No存在，都yes則提交執(zhí)行階段。
- 強(qiáng)一致性算法，簡單，但不好用。
- 3PC（Three-phase commit protocol）
- 在2PC中間插入一個(gè)準(zhǔn)備階段。
分布式一致性算法
- Paxos，state machine replication（active replication）各個(gè)節(jié)點(diǎn)間復(fù)制操作
- Raft，state machine replication（active replication）
- ZAB，primary backup（passive replication）Leader節(jié)點(diǎn)執(zhí)行操作，將執(zhí)行結(jié)果復(fù)制給其他節(jié)點(diǎn)。
數(shù)據(jù)分區(qū)
- 地理級別重大災(zāi)害規(guī)避風(fēng)險(xiǎn)。每個(gè)區(qū)域負(fù)責(zé)一部分?jǐn)?shù)據(jù)。
- 國家洲際間分區(qū)僅作為備份，而城市之間由于延遲低、業(yè)務(wù)相似，分區(qū)同時(shí)適合對外提供服務(wù)。
復(fù)制規(guī)則
- 集中式 所有分區(qū)將數(shù)據(jù)備份到備份中心。
- 互備式 形成閉合鏈，但如何加入新的一環(huán)。
- 獨(dú)立式 一對一，不同區(qū)域。
計(jì)算高可用
主備
冷備（未啟動）與 溫備（已啟動）
主從
從機(jī)也干活，主機(jī)有故障，從機(jī)升級主機(jī)（一般升級配置），新增從機(jī)。
對稱集群與非對稱集群
業(yè)務(wù)高可用
- 異地多活，把雞蛋放到多個(gè)籃子里。
- 優(yōu)先實(shí)現(xiàn)核心業(yè)務(wù)的異地多活架構(gòu)！
- 物理（地理等）因素導(dǎo)致無法很快。所以取舍：核心數(shù)據(jù)最終一致性。采用多種手段，保證絕大部分用戶的核心業(yè)務(wù)異地多活！
- 保證最終一致性，不保證實(shí)時(shí)一致性。
異地多活設(shè)計(jì)步驟
- 1.業(yè)務(wù)分級，根據(jù)不同標(biāo)準(zhǔn)不同情境（核心、訪問量、盈利）區(qū)分業(yè)務(wù)。
- 2.數(shù)據(jù)分類，根據(jù)（數(shù)據(jù)量、唯一性、實(shí)時(shí)性、可丟失性、可恢復(fù)性）
3.數(shù)據(jù)同步
- 存儲系統(tǒng)同步（延遲高）
- 消息隊(duì)列同步（無事務(wù)性和無時(shí)序性業(yè)務(wù)）
- 重復(fù)生成（如：cookie、session）
4.異常處理
- 多通道同步
- 同步和訪問結(jié)合：本地沒有去其他接口找。
- 日志記錄
- 用戶補(bǔ)償
總結(jié)
