個人見解，希望大家多多提出意見
1.盡量使用快取技術來做。使用者快取、頁面快取等一切快取，使用特定的機制進行重新整理。利用消耗記憶體空間來換取使用者的效率。同時減少資料庫的訪問次數。
2.把資料庫的查詢語句進行優化，一般複雜的sql語句就不要使用orm框架自帶的做法來寫，採用自己來寫sql，例如hibernate的hql中的複雜語句，就會很耗時
3.優化資料庫表的結構，在關鍵字、主鍵、訪問率極高的字段中加入索引。但盡量只是在數字型別上面加。因為使用 字段 is null的時候，索引的效果會失效
4.報表統計的模組，盡量採用定時任務執行，如果非得要實時進行重新整理，那麼可以採用快取來做資料。
5.可以使用靜態頁面的地方，使用靜態頁面，減少頁面解析時間，同時由於頁面中有許多的這種，可以考慮一下把做成乙個伺服器，這樣可以減少業務伺服器的壓力。
6.使用集群的方式來解決，單台伺服器效能的問題。
7。把專案，拆分成為多個應用小型伺服器形式，來進行分布式部署。採用資料同步機制（可以使用資料庫同步形式來做）達到資料一致性。
8.使用負載均衡模式，來讓每乙個伺服器資源進行合理的利用。
9.快取機制中，可以使用redis來做記憶體資料庫快取起來。也可以使用映象分擔，這樣可以讓兩台伺服器進行訪問，提高伺服器的訪問量
如何支援高訪問量
1.頁面靜態化或偽靜態 門戶 一般要面對巨大的訪問量。如果每次都是從資料庫中取資料的話 資料庫將面臨巨大的壓力 io讀寫也是乙個瓶頸。可以使用靜態頁面 把那些不經常改變的自動生成html檔案 緩解資料庫的壓力 比如新聞系統就可以使用。訪問大並且不經常更改的資料。2.資料庫讀寫分離 通過靜態化只能實現...
併發效能與訪問量
中小型資訊企業的開發團隊經常聽到一句話 我們訪問量不大，系統不必設計的這麼複雜。然後卻經常莫名其妙的發現些使用者重複資訊 訂單重複提交 關鍵性資料溢位或者超出範圍的問題。不好意思，訪問量和併發效能有時候真的沒啥直接關係。假設乙個系統每分鐘60個訪問，表面看來系統沒什麼壓力。但是，假設你的系統在做乙個...
高併發大訪問量架構設計演進之路 歸納總結
高併發大訪問量架構設計演進之路 歸納總結 第01 大型架構的演進之路 第02 上 分布式快取 第02 下 分布式快取 第03 分布式訊息佇列 第04 分布式資料儲存 第05 分布式服務框架 第06 高效能系統架構 第07 高可用系統架構 第08 系統的安全架構 第09 架構實戰案例分析 第10 如何...