架構演進與分庫分表
什麼時候分表？
水平切分
後續更新
在資料庫效能遇到瓶頸的時候，無非是會出現以下幾種情況：無法獲取連線，是因為在高併發的情況下資料庫連線數不夠；查詢時間太久，是因為單錶儲存資料過多，資料庫處理資料的效率降低；這些問題的出現我們首先應該想到的優化順序應該是軟體到硬體的優化。因為硬體的優化成本太高。
sql是存在於應用端的，這是我們首先要想著優化的點。sql的優化最終目的就是使用索引或者縮短執行時間。
優化表結構，對錶進行分割槽，對錶結構進行拆分或者冗餘處理，
或者對錶結構比如欄位的定義進行優化。使用效能高的儲存引擎。
我們可以對資料庫的架構進行優化，例如可以做資料庫集群，讀寫分離。或者在資料庫的上層做快取減小資料庫壓力。
是資料庫配置的優化，比如連線數，緩衝區大小等等，優化配置的目的都是為了更高效地利用硬體。
公升級硬體配置，例如使用高速固態硬碟和高效能cpu。
使用單一架構的時候，多個應用服務操作乙個資料庫例項，所有的表都存在乙個資料庫之中。這樣在資料量上來的時候，勢必會帶來效能問題。這時，我們就需要考慮服務和資料庫拆分。每個應用對應乙個資料庫。
這個時候每個業務系統都有了自己的資料庫，不同的業務系統就可以用不同的儲存方案。
當乙個表的資料量過大，sql也進行了優化後，對該錶的操作執行效率依然很低的時候，就需要考慮分表了。
垂直分表有兩種，一種是單庫的，一種是多庫的。
單庫單庫分表，比如：商戶資訊表，拆分成基本資訊表，****表，結算資訊表，附
件表等等。
多庫多庫垂直分表就是把原來儲存在乙個庫的不同的表，拆分到不同的資料庫。
比如：消費金融核心系統資料庫，有很多客戶相關的表，這些客戶相關的表，全部單獨存放到客戶的資料庫裡面。合同，放款，風控相關的業務表也是一樣的。
當我們對原來的一張表做了分庫的處理，如果某些業務系統的資料還是有乙個非常快的增長速度，比如說還款資料庫的還款歷史表，資料量達到了幾個億，這個時候硬體限制導致的效能問題還是會出現，所以從這個角度來說垂直切分並沒有從根本上解決單庫單錶資料量過大的問題。在這個時候，我們還需要對我們的資料做乙個水平的切分。
當我們的客戶表數量已經到達數千萬甚至上億的時候，單錶的儲存容量和查詢效率都會出現問題，我們需要進一步對單張表的資料進行水平切分。水平切分的每個資料庫的表結構都是一樣的，只是儲存的資料不一樣，比如每個庫儲存 1000 萬的資料。水平切分也可以分成兩種，一種是單庫的，一種是多庫的。
單庫銀行的交易流水表，所有進出的交易都需要登記這張表，因為絕大部分時候客戶都是查詢當天的交易和乙個月以內的交易資料，所以我們根據使用頻率把這張表拆分成三張表：
當天表：只儲存當天的資料。
當月表：在夜間執行乙個定時任務，前一天的資料，全部遷移到當月表。用的是 insert into select，然後 delete。
歷史表：同樣是通過定時任務，把登記時間超過 30 天的資料，遷移到 history
歷史表（歷史表的資料非常大，我們按照月度，每個月建立分割槽）。
多庫另一種是多庫的水平分表。比如客戶表，我們拆分到多個庫儲存，表結構是完全一樣的。
高可用集群架構的演進
我們專案組是做企業資料匯流排的，一開始的架構是採用apache httpd mod jk 做負載均衡，應用則部署在tomcat集群上面，該架構方案雖然考慮了tomcat容器級別的高可用，但並未考慮httpd的高可用，該方案的拓撲圖如下 該方案的缺點顯而易見，一旦httpd宕機，使用者將無法訪問應用，...
nginx架構演進 拆分資料庫及nfs
1.為什麼要進行資料庫的拆分 由於單台伺服器執行lnmp架構會導致 訪問緩慢，當記憶體吃滿時，容易導致系統出現oom，從而kill掉mysql資料庫，所以將web和資料庫進行獨立部署。2.資料庫拆分後解決了什麼問題 1.緩解web 的壓力 2.增強資料庫的讀寫效能 3.提高使用者訪問的速度 3.資料...
從單塊架構到分布式架構之資料庫集群（三）
資料庫集群主要有主備 主從 分庫 分表等方案。主要用來做儲存高可用，當主庫掛了之後可以利用備庫來代替主庫，備庫不提供任何的訪問能力。問題所在 主備資料同步是有延時的，資料量非常大的情況下可能會達到一分鐘以上。如果這個時候主庫所在伺服器宕機，可能會造成備庫資料不一致的情況。當主庫恢復正常執行之後，是把...