本人所遇到的併發場景是在抽獎、秒殺、搶紅包等，即在活動期間內有大量用戶訪問的情況。
兩個解決思路：
1、Java代碼實現方式 ：使用Redis緩存、代碼鎖機制、MQ消息隊列等
2、服務器層面調優：多節點部署、服務分發、提升帶寬等
3、數據庫層面，例如給查詢字段加索引等
4、進行系統設計分析：一個Web頁面js、css、圖片等靜態文件 統計約1.5M
併發狀態下 併發量爲1000 /S 則流量爲1500M/S
服務器帶寬則必須支持1500M/S ？？
當然不是
這裏需要做分流
國內的虛擬主機用的服務器多數是100M共享，也有10M獨享的
總結：
從低成本、高性能和高擴張性的角度來說有如下處理方案：
1、HTML靜態化
2、圖片服務器分離
3、數據庫集羣和庫表散列
4、緩存
5、鏡像
6、負載均衡;一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在很多大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都非常容易。
引用一個牛人所做的總結，跟上面部分相同。
高併發時，性能瓶頸及當前常用的應對措施
1.數據庫瓶頸。Mysql併發鏈接100
2.apache 併發鏈接1500
3.程序執行效率
1.有數據庫瓶頸時，當前處理方案無外乎 主從，集羣。增加memcached【內存對象緩存系統】
如：手機之家新系統介紹及架構分享（http://www.slideshare.net/Fenng/ss-1218991?from=ss_embed）
就是在cache【緩存】層做優化
又拍網架構（http://www.bopor.com/?p=652）
是以增加數據庫，分表分庫的方法解決。
Sina增加了mq(消息隊列)來分發數據。
還有風站用了key-value的數據庫。其實這可以理解成一個持久化的緩存。
2.apache瓶頸。
增加服務器。負載均衡。如sina的F5
由於進程數的限制。會把一些基本不變的代碼挪出來放到單獨的服務器。如css/js/圖片。
國內成功的案例是tom的cdn
又如nginx的橫空出世和squid的反向代理都是基於這個原因出來的。
2). 數據庫查詢效率問題。如可能有order by ,group by 等Sql數據問題。
這個其實應該歸結到數據庫設計問題。
解決的辦法是建立正確的索引。增加memcache【分佈式的高速緩存系統】.。
對like表 用專用的sphinx.【SQL的全文檢索引擎】和lucence 【基於Java 的全文信息檢索】等搜索服務。
程序員都應該會用explain對sql語句作分析。