先貼在這待整理。
一、數據量太大獲取緩慢怎么辦？
貌似這個問題在所有開發的應用系統中都會碰到這個問題，隨着時間的推移，由於需求的不斷演變，項目的數據量日漸增多，功能上的效率問題也會逐步顯露出來，例如統計報表、查詢下載、地圖渲染等功能模塊，當這些功能涉及到幾十張表甚至上百張表時，不難想象一次性獲取所有數據的時候系統將會變得異常緩慢。
1、首先從需求的設計和代碼層次出發
- 優化我們寫的代碼，減少沒必要的資源浪費。例如頻繁地使用new對象的方式以及if else和多個for循環的嵌套使用，對於大量的if和else及switch case的優化大家可以參考 多個if else如何優化和多個switch case如何優化，喜歡閱讀的朋友可以看下《重構——改善既有代碼的設計》這本書，另外對於代碼上的優化也方便於后期的維護使得代碼上的可讀性更高，除了邏輯控制代碼，也需要注意其字符串的處理以及List的數據的處理。字符串的話，使用StringBuffer或StringBuilder，對於工具類可以通過靜態方法來訪問。對於List上去重或者排序之類的處理，大家可參考java8系列文章；
- 優化代碼中的SQL語句，這也是重中之重，當查詢的數據牽扯到的數據庫表比較多時。頻繁地使用左連接或者內連接極大地會降低數據庫查詢的效率，對於SQL的優化大家可使用Explain命令進行對SQL語句的檢查效率，尤其要注意主表和次表的連接關系，根據Expalin的結果可對於部分字段及數據庫表增加相關的索引；
2、數據庫優化
對於數據庫的優化，在此不再做詳細探討。有時間我會再針對數據庫的優化整理出一篇文章，大致的方案有如下幾點
- 數據庫讀寫分離。
- 數據庫集群和庫表散列即分區分表。
- 數據庫表結構優化。
- 批量讀取和延遲修改
- SQL語句優化。
- 索引優化。
- 使用存儲過程代替直接操作。
3、使用緩存
- 框架自帶的緩存：如果你了解hibernate和mybatis的緩存機制那就好辦了，大家可參考mybatis一級緩存和二級緩存；
- 緩存的方式還可以通過程序代碼將數據直接保存到內存中，例如通過使用Map或者ConcurrentHashMap；
- 另外還有，就是使用緩存框架：Redis、Ehcache、Memcache等。 使用緩存框架的時候，我們需要關心的就是什么時候創建緩存和緩存失效策略（注意：使用緩存的時候還要考慮到緩存服務器發生故障時候如何進行容錯處理，是使用N多台服務器緩存相同的數據，通過分布式部署的方式對緩存數據進行控制，當一台發生故障的時候自動切換到其他的機器上去；還是通過Hash一致性的方式，等待緩存服務器恢復正常使用的時候重新指定到該緩存服務器。Hash一致性的另一個作用就是在分布式緩存服務器下對數據進行定位，將數據分布在不用緩存服務器上）；
二、多線程高並發如何優化？
4、HTML靜態化
- 我們可以將頁面靜態化提供訪問來緩解服務器壓力，能夠緩解服務器壓力加大以及降低數據庫數據的頻繁交換。適合於某些訪問量過大，但是內容不經常改變的頁面，如首頁、公告頁等；
- 前后端分離，即前端與后台應用分開部署，提高用戶訪問靜態代碼的速度，降低對后台應用訪問。前端界面的顯示是通過后台服務器的接口返回的json數據進行渲染后返回給前端瀏覽器進行解析執行；
5、圖片服務器分離
- 對於web服務器來說，圖片是最消耗資源的，於是我們有必要把圖片與頁面進行分離，我們把圖片放到獨立的圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統壓力，並且可以保證系統不會因為圖片的問題而崩潰。在圖片服務器上，我們可以對不同的配置進行優化。
- 靜態資源部署至CDN上，即直接將靜態資源全部存放在CDN服務器上。因為之前項目中的JavaScript,CSS以及img文件都是存放在CDN服務器上，將HTML文件一起存放到CDN上之后，可以將靜態資源統一放置在一種服務器上，便於前端進行維護；而且用戶在訪問靜態資源時，可以很好利用CDN的優點——CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。
6、負載均衡
1.軟/硬件負載均衡
軟件負載均衡解決方案是指在一台或多台服務器相應的操作系統上安裝一個或多個附加軟件來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
軟件解決方案缺點也較多，因為每台服務器上安裝額外的軟件運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，所以當連接請求特別大的時候，軟件本身會成為服務器工作成敗的一個關鍵；軟件可擴展性並不是很好，受到操作系統的限制；由於操作系統本身的Bug，往往會引起安全問題。
硬件負載均衡解決方案是直接在服務器和外部網絡間安裝負載均衡設備，這種設備通常稱之為負載均衡器，由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於服務器與Internet鏈接之間，有些則以兩塊網絡適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到后端服務器群的內部網絡上。
一般而言，硬件負載均衡在功能、性能上優於軟件方式，不過成本昂貴。
2.本地/全局負載均衡
負載均衡從其應用的地理結構上分為本地負載均衡（Local Load Balance）和全局負載均衡（Global Load Balance，也叫地域負載均衡），本地負載均衡是指對本地的服務器群做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網絡結構的服務器群間作負載均衡。
本地負載均衡能有效地解決數據流量過大、網絡負荷過重的問題，並且不需花費昂貴開支購置性能卓越的服務器，充分利用現有設備，避免服務器單點故障造成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給服務器群內的服務器共同負擔。即使是再給現有服務器擴充升級，也只是簡單地增加一個新的服務器到服務群中，而不需改變現有網絡結構、停止現有的服務。
全局負載均衡主要用於在一個多區域擁有自己服務器的站點，為了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的服務器，從而獲得最快的訪問速度，也可用於子公司分散站點分布廣的大公司通過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。
全局負載均衡有以下的特點：
實現地理位置無關性，能夠遠距離為用戶提供完全的透明服務。
除了能避免服務器、數據中心等的單點失效，也能避免由於ISP專線故障引起的單點失效。
解決網絡擁塞問題，提高服務器響應速度，服務就近提供，達到更好的訪問質量。
6、使用nosql和Hadoop技術
7、集群與分布式架構
8、反向代理
客戶端直接訪問的服務器並不是直接提供服務的服務器，它從別的服務器獲取資源，然后將結果返回給用戶。
代理服務器和反向代理服務器：
代理服務器是代我們訪獲取資源，然后將結果返回。例如，訪問外網的代理服務器。反向代理服務器是我們正常訪問一台服務器的時候，服務器自己調用了別的服務器。
反向代理就是說，用戶的請求請求到負載均衡的設備上，負載均衡設備再講請求分發到空閑的應用服務器上處理，處理完成之后再通過負載均衡設備返回給用戶，這樣對於用戶來說，后來的分發是不可見的。
反向代理的實現
- 需要有一個負載均衡設備來分發用戶請求，將用戶請求分發到空閑的服務器上
- 服務器返回自己的服務到負載均衡設備
- 負載均衡將服務器的服務返回用戶
代理服務器我們主動使用，是為我們服務的，不需要有自己的域名；反向代理是服務器自己使用的，我們並不知道，有自己的域名。
微信掃描下方二維碼（新開通的個人微信公眾號） 更多優質資源及優質文章及時獲取 請大家多多支持哦