關於分布式系統，一直不知道該怎么寫，這里就先介紹下架構的演變
1.在最開始時，使用的架構是這樣的：
瀏覽器向后台服務器發送請求，然后服務器請求數據庫，獲取數據，在響應給瀏覽器，這是最早期的架構，服務器和數據庫放在一台主機上，
這樣的架構帶來的問題是：
當訪問量逐漸增大時，服務器的負載就會越來越大，負載達到一定限制時，服務器就會宕機，一旦服務器宕機，前端就獲取不到任何數據
2.為了解決這個問題，就提出了第二套架構
通過將數據庫分離出來成為一個單獨的服務器，來減小放web項目的服務器的壓力，這樣雖然解決了第一種架構的問題，但是新的問題出現了：
當有十萬並發請求web服務器時，服務器就會宕機，服務器宕機，瀏覽器仍然獲取不到任何數據，核心功能在web服務器上
3.因此就出現了第三種架構
為了解決上一種架構的問題，於是就提出了使用web服務器集群來部署項目，這樣當節點1宕機的話，就會請求節點2處理請求，那么問題也隨之而來：
如果訪問量非常大，導致節點1宕機的話，那么所有的請求就會被節點2接受，節點1宕機，節點2最后必然也會宕機，
4.負載均衡
針對上面的架構的問題，就有了解決辦法：
使用nginx來做負載均衡，使用輪詢算法，一條給節點1，一條給節點2，下一個請求還給節點1，這樣就解決了上面的問題，但是又迎來了新的問題：
假設節點1的最大負載是8萬，那么當節點1上現在已經達到滿載8萬時，下一條請求就是壓死駱駝的最后一根稻草，當下一次請求進入節點1，節點1的負載就到了8萬零一條，
這時節點1就會宕機。當節點1宕機后，nginx會繼續嘗試連接節點1，當嘗試幾次還是連接不上后，就會放棄連接，並將節點1標記為宕機狀態。
節點1宕機后，所有的請求就會壓在節點2上，那么最后結果是節點2也必然宕機
5.架構五，將項目拆分
將一個項目於分兩個節點來存放，節點1就只存放門戶網站，節點2存放登錄的項目， 這樣就將請求分不同的服務器處理了
假設此時又十萬並發過來了，這十萬並發中有兩萬是請求門戶網站的，就訪問節點1、3，八萬是請求登錄項目的就訪問節點2、4，這樣高並發的問題就解決了。可以查看dubbo架構：https://github.com/Zs-xiazhi/dubbo
並發的問題解決了，數據庫又出現問題了：想象一下，隨着項目的越來越大，用戶越來越多，數據庫中的用戶表中的數據也越來越多，數據的查詢就會非常慢，而且服務器集群中所有的服務器都是訪問這一個數據庫，那么數據庫的壓力就會很大。隨着數據庫中的數據越來越多，壓力越來越大，數據庫就會宕機，而服務器集群訪問的只有這一台數據庫，一旦數據庫宕機，那么所有的項目都獲取不到數據了。
6.架構六，設置主從數據庫
因為上面已經解決了服務器集群高並發問題，因此就不詳細畫該部分了：
數據庫設置主從關系庫，正常運行時web服務器訪問主庫，所有的數據都存放在DB1上，當DB1宕機時，訪問DB2，發現沒有數據，因此DB1和DB2之間要做數據同步。
當DB1宕機期間，所有的數據都存放在DB2上，如果DB1修好了，這時發現DB2上有的數據DB1上沒有，DB2就會自動向DB1同步數據，速度非常快，為了加快速度，可以將經常使用的且不經常修改的數據放入redis緩存中
這種架構出現的問題是：
1.如果DB1宕機，如何切換從庫?
啟用監聽。項目啟動后，web項目連接數據庫DB1，當DB1連接超時，啟用監聽，切換數據庫DB2
2.單表數據過大，數據庫承受訪問壓力過大
單表數據量過大：分庫分表
數據庫承受訪問壓力過大：獨寫分離
7.分庫分表
如上圖所示，假設項目用戶越來越多，那么用戶表user內的數據就會越來越多，這時查詢數據非常慢，使用分庫分表，就是將同一張表放入不同的數據庫中。
假設user表中有10萬條數據，那么就在db1放1-5萬條數據， db2中放5-10萬條數據
在分庫分表中，沒有主從概念，所有的數據庫都是平等的
問題：如何知道要查詢的數據在那兒個數據庫中？
假設用戶需要查詢一條數據， 那么服務器如何知道這條數據存在哪兒個數據庫的表中的呢？所以需要在服務器和數據庫之間建立一個命名節點，這也是一個數據庫，里面存放的數據是每個數據庫節點的數據范圍。如：DB1---1-5萬，DB2--5-10萬。這樣服務器訪問數據庫時，先到命名節點中查詢要查的數據庫是在哪兒個數據庫上，然后再到相應的數據庫中查詢數據。
8.讀寫分離
分庫分表完美解決了大量數據的存儲問題，但是單個服務器壓力過大的問題還沒有解決，讀寫分離解決但服務器壓力過大問題：中間的命名節點仍然存在，這里畫漏了
讀寫分離：
就是把服務器端的select和增刪改操作分離開來，對每一個數據庫做標識（read-->只做select操作，write-->只做增刪改操作）
讀寫分離是有主從概念的，並不是真的有主庫和從庫的區分，是有這個概念，讀為主，寫為從。
上圖使用的是獨寫分離加上分庫分表，這兩種方式可以同時使用，也可以分開單獨使用，並不沖突