最近一直在研究高併發架構的設計，看了很多關於soa設計思想，dubbo+zookeeper的分布式服務設計，mq等等，但目前專案處於初步期，還沒上線，不能預估使用者數量以及將來的併發數量，所以為了節約成本（老闆吝嗇），快速上線專案，我們專案依舊處於集中式，沒有分模組，沒有分表分庫，只是提高了集中式專案的乙個併發處理。
首先我們來看一下專案整體的架構（很不規範，湊合著看）
我們先介紹下架構中的技術選型為什麼這麼選。
1.使用nginx進行反向**實現負載均衡而不使用其他的。網上有很多種實現負載均衡的軟硬體方案，其中f5，apache的負載均衡，lvs的負載均衡為什麼我們都不選？f5，沒錢。apache，複雜，在高併發上效能低於nginx。lvs，沒怎麼了解，直接拋棄了。
2.使用redis作為快取。redis跟mencache，ehcache選哪個一直都是人們所頭疼的。首先ehcache是存在於本地記憶體的，多個tomcat做負載的時候就特別麻煩了。mencache是支援多執行緒的快取，但它只支援一種資料結構---key-value，這使我們在使用它的時候會有很多瓶頸。redis分布式快取，提供了多種資料結構的儲存，雖然它只支援單執行緒訪問，但速度不亞於mencache。
3.mysql我們使用的是5.6的版本，主要是支援事務，顏表情等功能，沒啥好說的
接下來講一下架構
2.到了tomcat層後，我們會先把請求分為兩種，一種是查詢請求，一種是更新請求。
1）其中查詢請求先會訪問redis快取（減少mysql壓力，提高併發），若命中則返回資料給使用者，若不命中則查詢mysql（從庫：myisam引擎，唯讀庫，提高讀取效率），並把查詢結果set到redis中
2）更新請求會傳送到mysql（主庫：innodb，保證事務，資料安全）
3.由於我們專案對於實時性要求不是很高，所以此時可以不用考慮mysql主從複製時的延時性。（網上有很多種解決延時的方案，例如快取，中介軟體等）
4.至於靜態檔案我們存放在自己構建的cdn上，也是為了提公升訪問效率
最後講一下sql
1.設計表的時候適當的加些冗餘字段，這樣會少了很多的連表查詢（當然冗餘字段改變了對專案需求影響不大或冗餘字段不會改變的情況下）
2.預估好欄位大小，畢竟定義好欄位大小後mysql就給該字段定義了相對大小的空間，定義過大會很浪費資源。當然也避免定義一些沒用的字段
3.適當索引，當然跟廢話差不多啦，加索引的技巧也很多，上網搜搜。
4.不是一條sql搞定全部就是好，有時候把大的sql拆分成小的sql效率會高很多
大概就講這麼多啦，當然這裡面還有很多需要優化的東西，以後會陸續跟大家分享的
架構設計原則 高併發
架構設計原則 高併發 高併發設計可以從以下幾方面考慮 1.無狀態 無狀態的應用容易進行水平擴充套件。實際常用 應用無狀態，配置檔案有狀態，例如，不同的機房讀取不同的配置檔案，通過配置中心指定。2.拆分 拆分維度 3.服務化 服務化需要考慮自動服務註冊，和服務發現，還有服務的分組 隔離，例如，有的系統...
集中式架構和分布式架構的特點
1.集中式架構的特點 所謂的集中式系統就是由一台或多台主計算機組成的中心節點，資料集中儲存於這個中心節點中，並且整個系統的所有業務單元都集中部署在這個中心節點上，系統的所有功能均由其集中處理。也就是說，在集中式系統中，每個終端或客戶端機器僅僅負責資料的錄入和輸出，而資料的儲存與控制處理完全交由主機來...
高併發架構設計原則 拆分
在系統設計初期，是做乙個大而全的系統還是根據模組進行拆分要根據環境和需求進行權衡。訪問量不大 功能簡單 研發資源不多時可以做乙個大而全的系統即可 如果訪問量大資源充足 功能繁多可以考慮按功能拆分系統。下面幾種拆分維度 按照系統功能 業務拆分，比如商品系統 購物車系統 結算系統 訂單系統等。對乙個系統...