在上篇文章中，介紹了八種架構設計模式中的三種，既：查詢分離模式、微服務模式、多級快取模式
、彈性伸縮模式、多機房模式。
1. 分庫分表模式
這種模式主要解決單錶寫入、讀取、儲存壓力過大，從而導致業務緩慢甚至超時，交易失敗，容量不夠的問題。一般有水平切分和垂直切分兩種，這裡主要介紹水平切分。這個模式也是技術架構迭代演進過程中的必經之路。
這種模式的一般設計見下圖：
如上圖所示紅色部分，把一張表分到了幾個不同的庫中，從而分擔壓力。是不是很籠統？哈哈，那我們接下來就詳細的講解一下。首先澄清幾個概念，如下：
主機：硬體，指一台物理機，或者虛擬機器，有自己的cpu，記憶體，硬碟等。
例項：資料庫例項，如乙個mysql服務程序。乙個主機可以有多個例項，不同的例項有不同的程序，監聽不同的埠。
庫：指表的集合，如學校庫，可能包含教師表、學生表、食堂表等等，這些表在乙個庫中。乙個例項中可以有多個庫。庫與庫之間用庫名來區分。
表：庫中的表，不必多說，不懂的就不用往下看了，不解釋。
那麼怎麼把單錶分散呢？到底怎麼個分發呢？分發到**呢？以下是幾個工作中的實踐，分享一下：
主機：這是最主要的也是最重要的點，本質上分庫分表是因為計算與儲存資源不夠導致的，而這種資源主要是由物理機，主機提供的，所以在這裡分是最基本的，畢竟沒有可用的計算資源，怎麼分效果都不是太好的。
例項：例項控制著連線數，同時受os限制，cpu、記憶體、硬碟、網路io也會受間接影響。會出現熱例項的現象，即：有些例項特別忙，有些例項非常的空閒。乙個典型的現象是：由於單錶反應慢，導致連線池被打滿，所有其他的業務都受影響了。這時候，把表分到不同的例項是有一些效果的。
庫：一般是由於單庫中最大單錶數量的限制，才採取分庫。
表：單錶壓力過大，索引量大，容量大，單錶的鎖。據以上，把單錶水平切分成不同的表。
大型應用中，都是一台主機上只有乙個例項，乙個例項中只有乙個庫，庫==例項==主機，所以才有了分庫分表這個簡稱。
既然知道了基本理論，那麼具體是怎麼做的呢？邏輯是怎麼跑的呢？接下來以乙個例子來講解一下。
這個需求很簡單，使用者表(user)，單錶資料量1億，查詢、插入、儲存都出現了問題，怎麼辦呢？
首先，分析問題，這個明顯是由於資料量太大了而導致的問題。
其次，設計方案，可以分為10個庫，這樣每個庫的資料量就降到了1kw，單錶1kw資料量還是有些大，而且不利於以後量的增長，所以每個庫再分100個表，這個每個單錶資料量就為10w了，對於查詢、索引更新、單錶檔案大小、開啟速度，都有一些益處。接下來，給it部門打**，要10臺物理機，擴充套件資料庫......
最後，邏輯實現，這裡應該是最有學問的地方。首先是寫入資料，需要知道寫到哪個分庫分表中，讀也是一樣的，所以，需要有個請求路由層，負責把請求分發、轉換到不同的庫表中，一般有路由規則的概念。
怎麼樣，簡單吧？哈哈，too 那義務。說說這個模式的問題，主要是帶來了事務上的問題，因為分庫分表，事務完成不了，而分布式事務又太笨重，所以這裡需要有一定的策略，保證在這種情況下事務能夠完成。採取的策略如：最終一致性、複製、特殊設計等。再有就是業務**的改造，一些關聯查詢要改造，一些單錶orderby的問題需要特殊處理，也包括groupby語句，如何解決這些***不是一句兩句能說清楚的，以後有時間，我單獨講講這些。
該總結一下這種模式的優缺點的了，如下：
優點：減少資料庫單錶的壓力。
缺點：事務保證困難、業務邏輯需要做大量改造。
2. 彈性伸縮模式
這種模式主要解決突發流量的到來，導致無法橫向擴充套件或者橫向擴充套件太慢，進而影響業務，全站崩潰的問題。這個模式是一種相對來說比較高階的技術，也是各個大公司目前都在研究、試用的技術。截至今日，有這種思想的架構師就已經是很不錯了，能夠拿到較高薪資，更別提那些已經實踐過的，甚至實現了底層系統的那些，所以，你懂得......
這種模式的一般設計見下圖：
如上圖所示，多了乙個彈性伸縮服務，用來動態的增加、減少例項。原理上非常簡單，但是這個模式到底解決什麼問題呢？先說說由來和意義。
每年的雙11、六一八或者一些大促到來之前，我們都會為大流量的到來做以下幾個方面的工作:
提前準備10倍甚至更多的機器，即使用不上也要放在那裡備著，以防萬一。這樣浪費了大量的資源。
每台機器配置、除錯、引流，以便讓所有的機器都可用。這樣浪費了大量的人力、物力，更容易出錯。
如果機器準備不充分，那麼還要加班加點的重複上面的工作。這樣做特別容易出錯，引來領導的不滿，沒時間回家陪老婆，然後你的老婆就......(自己想)
在雙十一之後，我們還要人工做縮容，非常的辛苦。一般一年中會有多次**，那麼我們就會一直這樣，實在是煩！
最嚴重的，突然間的大流量爆發，會讓我們觸不及防，半夜起來擴容是在正常不過的事情，為此，我們偷懶起來，要更多的機器備著，也就出現了大量的cpu利用率為1%的機器。
我相信，如果你是老闆一定很震驚吧！！！
哈哈，那麼如何改變這種情況呢？請接著看
為此，首先把所有的計算資源整合成資源池的概念，然後通過一些策略、監控、服務，動態的從資源池中獲取資源，用完後在放回到池子中，供其他系統使用。
該總結一下這種模式的優缺點的了，如下：
優點：彈性、隨需計算，充分優化企業計算資源。
缺點：應用要從架構層做到可橫向擴充套件化改造、依賴的底層配套比較多，對技術水平、實力、應用規模要求較高。
3. 多機房模式
這種模式主要解決不同地區高效能、高可用的問題。
隨著應用使用者不斷的增加，使用者群體分布在全球各地，如果把伺服器部署在乙個地方，乙個機房，比如北京，那麼美國的使用者使用應用的時候就會特別慢，因為每乙個請求都需要通過海底光纜走上個那麼一秒鐘(預估)左右，這樣對使用者體驗及其不好。怎麼辦？使用多機房部署。
這種模式的一般設計見下圖：
如上圖所示，乙個典型的使用者請求流程如下：
使用者請求乙個鏈結a
通過dns智慧型解析到離使用者最近的機房b
使用b機房服務鏈結a
是不是覺得很簡單，沒啥？其實這裡面的問題沒有表面這麼簡單，下面一一道來。
首先是資料同步問題，在中國產生的資料要同步到美國，美國的也一樣，資料同步就會涉及資料版本、一致性、更新丟棄、刪除等問題。
其次是一地多機房的請求路由問題，典型的是如上圖，中國的北京機房和杭州機房，如果北京機房掛了，那麼要能夠通過路由把所有發往北京機房的請求**到杭州機房。異地也存在這個問題。
所以，多機房模式，也就是異地多活並不是那麼的簡單，這裡只是起了個頭，具體的有哪些坑，會在另一篇文章中介紹。
該總結一下這種模式的優缺點的了，如下：
優點：高可用、高效能、異地多活。
缺點：資料同步、資料一致性、請求路由。
呵呵，至此，整個關於八種架構設計模式及其優缺點概述就介紹完了，大約1w字左右。最後，我想說的是沒有銀彈、靈活運用，共勉！
Java單例設計模式及其優缺點
什麼是單例設計模式？單例模式，是一種常用的軟體設計模式。它的核心思想是指，乙個類只允許產生乙個例項化物件。單例設計模式實現要求 1 構造方法私有化，保證在類的外部不能通過使用new關鍵字來例項化物件 2 在類的內部產生例項化物件，呼叫類的具體方法，使用private static 封裝 3 提供乙個...
iOS中的兩種主要架構及其優缺點
凡是程式的開發者，應該對程式的架構都不陌生。乙個程式的架構的好壞對這個程式有著非常重要的作用。今天我們來看一下ios開發中用要的兩種主流的程式架構。這個過程中我們主要以例子的形式展開。我們來看第一種架構 如下圖所示 這種程式的架構的思路就是在用到哪個介面的時候，把該介面的的標頭檔案包含進來。用導航控...
單例模式的八種實現及優缺點
單例模式是最常用到的設計模式之一，熟悉設計模式的朋友對單例模式都不會陌生。一般介紹單例模式的書籍都會提到 餓漢式 和 懶漢式 這兩種實現方式。但是除了這兩種方式，本文還會介紹其他幾種實現單例的方式，讓我們來一起看看吧。簡介單例模式是一種常用的軟體設計模式，其定義是單例物件的類只能允許乙個例項存在。許...