原創(chuàng)文章，歡迎轉(zhuǎn)載。轉(zhuǎn)載請注明：轉(zhuǎn)載自IT人故事會，謝謝！
原文鏈接地址：『互聯(lián)網(wǎng)架構(gòu)』軟件架構(gòu)-分布式之大型網(wǎng)站的演變過程（28）

項目都是從單一的應(yīng)用，到分布式應(yīng)用，到流式的基棧，這樣的思想。

單體應(yīng)用

app應(yīng)用，db數(shù)據(jù)庫，server服務(wù)都在同一臺機器上

集群應(yīng)用

隨著業(yè)務(wù)量的增大，一臺服務(wù)器，需要進行拆分到3臺服務(wù)器。
server服務(wù)和app在一臺機器上。2臺應(yīng)用的，一臺數(shù)據(jù)庫的。

在真正的開發(fā)過程中，由一個應(yīng)用變成多個了會發(fā)生什么樣的問題？

1.session集群問題
2.數(shù)據(jù)一致性問題
3.數(shù)據(jù)瓶頸（一旦流量上來了，雖然應(yīng)用做了集群，但是數(shù)據(jù)庫沒有做集群，還是一個主庫），這時候要考慮主從數(shù)據(jù)庫。

N多個模板一直操作同一個數(shù)據(jù)庫，數(shù)據(jù)庫需要負載如何負載，將業(yè)務(wù)進行拆分，不同的業(yè)務(wù)訪問自己的數(shù)據(jù)庫。降低主庫的壓力。
互聯(lián)網(wǎng)的特性就是讀多寫少。

如果雙11了，交易額大的話，其實交易的讀寫庫壓力就很大。采用的方案是：分庫分表：垂直分庫，水平分表。模塊的專庫專用，就是一種垂直的分庫。分表是根據(jù)關(guān)鍵的字段orderId，userId將信息存儲到指定的表中。

水平分表的策略（hash，range，list）

1. range 和 list 要進行預(yù)估擴容很麻煩
2. hash 熱點數(shù)據(jù)進行分散，分布均衡，擴容也比較麻煩。

前端

1. 用戶如果使用userId比較多
2. 數(shù)據(jù)一致性要求比較高
3. 查詢我的訂單（userId查）
4. userId，時間查詢條件

后端

1. 內(nèi)部數(shù)據(jù)要求不太高
2. 業(yè)務(wù)復(fù)雜
3. 有通過非userId來進行查詢，當天所有的下單總數(shù)，下單的人數(shù)。
4. 消息中間件 和 es cluster（canal異構(gòu)）整理成后端需要的。
5. 不查詢數(shù)據(jù)庫，通過es來進行查詢
6. es 獲取數(shù)據(jù)庫的同步分：延時，實時，維度，增量，全量。其實就是讀binlog的日志。
7. 大的變小的，不斷的拆分， 不斷的合并
8. 最后可能到后臺就是一個漏洞的錐子形狀，越往后面越少，前面能過濾的都過濾掉了。

涉及到技術(shù)點

java，分庫分表，redis緩存，搜索引擎，RPC遠程調(diào)用，所有大型分布式都涉及到并發(fā)編程這一點。

PS：技術(shù)的選型，一定了解業(yè)務(wù)，才能知道他的解決方案。