1、高並發網站架構設計 英文怎麼說
High concurrent Web Architecture Design
2、高並發，大流量網站架構時你考慮網卡流量了嗎
肯定的，高流量站點必須考慮自己的寬頻能否帶的動自己的網站，一個100M的寬頻如果是一百個用戶同時訪問那麼就相當於分開就只有每個人1M的寬頻使用了
3、怎樣具備大規模高並發訪問的Web應用架構設計和開發經驗
理論上經驗這個東西是學不來的.
說一下我的例子.
剛入行的時候,基本就是寫了一些增刪改查.甚至session都不太理解.
隨著入行後,你會遇到各種各樣的問題.在解決問題的過程中,經驗來了.
簡單說一下所謂大規模高並發訪問的web架構吧.
其實,對於大規模高並發不外乎兩點,第一點是及時相應(盡可能優化io).第二點是數據安全.
這兩點控制的好,就沒問題的.所以,我們的架構也就圍繞在這兩點應運而生.
第一點,為了盡可能提高應用的io吞吐量.則需要我們把所有耗時的io操作盡可能的優化,比如全局使用很少更改的一些配置,則可以採用nosql來全局共享(注意,這里的全局是指伺服器集群.如果涉及到了大規模,肯定是多伺服器的).在其次可以增加伺服器緩存.比如2秒鍾從上一條的伺服器讀取配置,存到伺服器級別.以提高效率.還有線程緩存.如果業務復雜可能對一個請求需要查詢多次數據,不變的,老規矩,放到線程緩存.基本也就差不多了.
第二點,因為應用不同,要考慮容錯率.這個部分優化,可以考慮分離業務,把必須要數據安全的業務邏輯提取出來,隊列執行或者特殊處理.
剩下的就是伺服器部署與如何分配,比如多少台web伺服器,資料庫配置,內存伺服器配置等.
這只能是在實際項目和工作過程中來區別對待了.
4、一般互聯網公司 如何進行高並發的架構
一、什麼是高並發
高並發（High Concurrency）是互聯網分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。
高並發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），並發用戶數等。
響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。
吞吐量：單位時間內處理的請求數量。
QPS：每秒響應請求數。在互聯網領域，這個指標和吞吐量區分的沒有這么明顯。
並發用戶數：同時承載正常使用系統功能的用戶數量。例如一個即時通訊系統，同時在線量一定程度上代表了系統的並發用戶數。
二、如何提升系統的並發能力
互聯網分布式架構設計，提高系統並發能力的方式，方法論上主要有兩種：垂直擴展（Scale Up）與水平擴展（Scale Out）。
垂直擴展：提升單機處理能力。垂直擴展的方式又有兩種：
（1）增強單機硬體性能，例如：增加CPU核數如32核，升級更好的網卡如萬兆，升級更好的硬碟如SSD，擴充硬碟容量如2T，擴充系統內存如128G；
（2）提升單機架構性能，例如：使用Cache來減少IO次數，使用非同步來增加單服務吞吐量，使用無鎖數據結構來減少響應時間；
在互聯網業務發展非常迅猛的早期，如果預算不是問題，強烈建議使用「增強單機硬體性能」的方式提升系統並發能力，因為這個階段，公司的戰略往往是發展業務搶時間，而「增強單機硬體性能」往往是最快的方法。
不管是提升單機硬體性能，還是提升單機架構性能，都有一個致命的不足：單機性能總是有極限的。所以互聯網分布式架構設計高並發終極解決方案還是水平擴展。
水平擴展：只要增加伺服器數量，就能線性擴充系統性能。水平擴展對系統架構設計是有要求的，如何在架構各層進行可水平擴展的設計，以及互聯網公司架構各層常見的水平擴展實踐，是本文重點討論的內容。
三、常見的互聯網分層架構
常見互聯網分布式架構如上，分為：
（1）客戶端層：典型調用方是瀏覽器browser或者手機應用APP
（2）反向代理層：系統入口，反向代理
（3）站點應用層：實現核心應用邏輯，返回html或者json
（4）服務層：如果實現了服務化，就有這一層
（5）數據-緩存層：緩存加速訪問存儲
（6）數據-資料庫層：資料庫固化數據存儲
整個系統各層次的水平擴展，又分別是如何實施的呢？
四、分層水平擴展架構實踐
反向代理層的水平擴展
反向代理層的水平擴展，是通過「DNS輪詢」實現的：dns-server對於一個域名配置了多個解析ip，每次DNS解析請求來訪問dns-server，會輪詢返回這些ip。
當nginx成為瓶頸的時候，只要增加伺服器數量，新增nginx服務的部署，增加一個外網ip，就能擴展反向代理層的性能，做到理論上的無限高並發。
站點層的水平擴展
站點層的水平擴展，是通過「nginx」實現的。通過修改nginx.conf，可以設置多個web後端。
當web後端成為瓶頸的時候，只要增加伺服器數量，新增web服務的部署，在nginx配置中配置上新的web後端，就能擴展站點層的性能，做到理論上的無限高並發。
服務層的水平擴展
服務層的水平擴展，是通過「服務連接池」實現的。
站點層通過RPC-client調用下游的服務層RPC-server時，RPC-client中的連接池會建立與下游服務多個連接，當服務成為瓶頸的時候，只要增加伺服器數量，新增服務部署，在RPC-client處建立新的下游服務連接，就能擴展服務層性能，做到理論上的無限高並發。如果需要優雅的進行服務層自動擴容，這里可能需要配置中心裡服務自動發現功能的支持。
數據層的水平擴展
在數據量很大的情況下，數據層（緩存，資料庫）涉及數據的水平擴展，將原本存儲在一台伺服器上的數據（緩存，資料庫）水平拆分到不同伺服器上去，以達到擴充系統性能的目的。
互聯網數據層常見的水平拆分方式有這么幾種，以資料庫為例：
按照范圍水平拆分
每一個數據服務，存儲一定范圍的數據，上圖為例：
這個方案的好處是：
（1）規則簡單，service只需判斷一下uid范圍就能路由到對應的存儲服務；
（2）數據均衡性較好；
（3）比較容易擴展，可以隨時加一個uid[2kw,3kw]的數據服務；
不足是：
（1）請求的負載不一定均衡，一般來說，新注冊的用戶會比老用戶更活躍，大range的服務請求壓力會更大；
按照哈希水平拆分
每一個資料庫，存儲某個key值hash後的部分數據，上圖為例：
這個方案的好處是：
（1）規則簡單，service只需對uid進行hash能路由到對應的存儲服務；
（2）數據均衡性較好；
（3）請求均勻性較好；
不足是：
（1）不容易擴展，擴展一個數據服務，hash方法改變時候，可能需要進行數據遷移；
這里需要注意的是，通過水平拆分來擴充系統性能，與主從同步讀寫分離來擴充資料庫性能的方式有本質的不同。
通過水平拆分擴展資料庫性能：
（1）每個伺服器上存儲的數據量是總量的1/n，所以單機的性能也會有提升；
（2）n個伺服器上的數據沒有交集，那個伺服器上數據的並集是數據的全集；
（3）數據水平拆分到了n個伺服器上，理論上讀性能擴充了n倍，寫性能也擴充了n倍（其實遠不止n倍，因為單機的數據量變為了原來的1/n）；
通過主從同步讀寫分離擴展資料庫性能：
（1）每個伺服器上存儲的數據量是和總量相同；
（2）n個伺服器上的數據都一樣，都是全集；
（3）理論上讀性能擴充了n倍，寫仍然是單點，寫性能不變；
緩存層的水平拆分和資料庫層的水平拆分類似，也是以范圍拆分和哈希拆分的方式居多，就不再展開。
五、總結
高並發（High Concurrency）是互聯網分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。
提高系統並發能力的方式，方法論上主要有兩種：垂直擴展（Scale Up）與水平擴展（Scale Out）。前者垂直擴展可以通過提升單機硬體性能，或者提升單機架構性能，來提高並發性，但單機性能總是有極限的，互聯網分布式架構設計高並發終極解決方案還是後者：水平擴展。
互聯網分層架構中，各層次水平擴展的實踐又有所不同：
（1）反向代理層可以通過「DNS輪詢」的方式來進行水平擴展；
（2）站點層可以通過nginx來進行水平擴展；
（3）服務層可以通過服務連接池來進行水平擴展；
（4）資料庫可以按照數據范圍，或者數據哈希的方式來進行水平擴展；
各層實施水平擴展後，能夠通過增加伺服器數量的方式來提升系統的性能，做到理論上的性能無限。
5、JAVA高吞吐高並發後端架構設計經驗是什麼意思
有些網站並發量比較高，例如：12306，到了春節的時候，訪問量就非常高回了。以前不是經常卡住、答崩潰嗎？
就是因為架構設計的不行。去年好多了。
高吞吐、高並發指的是一種種業務場景，訪問人數很多，同一時刻點擊也很多。
類似的還有雙十一，雙12。
高峰期的時候 涉及大量的讀寫操作，讀取網頁資源、數據，寫入訂單等等。
小型網站可以通過增加伺服器的方法解決，分離應用程序和資料庫，放在兩台伺服器上。
大型的網站涉及的技術就更多了：緩存技術、讀寫分離、分布式部署伺服器、業務拆分、資料庫優化等等。
6、海量高並發系統架構該怎樣設計
高並發情況下要考慮的因素有很多：
伺服器並發處理能力、響應時間專；數據安全及一致性、鎖屬機制；數據存儲及訪問性能...
系統架構按層級(水平)劃分的話，在每一層都需要考慮好壓力的分配，以最前端的網路接入層為例，一般做法是在高配機器上部署支持高並發的web伺服器(如nginx)集群，後端映射個多個業務組件達到並發處理能力；在數據訪問方面充分做好緩存，包括數據緩存、頁面、甚至文件緩存，需要存儲大量數據的情況下則考慮分布式。
不同應用場景的架構設計都存在差異！
7、用Java做一個大流量，高並發的網站應該怎麼樣進行底層構架
架構是為了解決糸統中具有共性的問題而進行定義了減少重復工作量，且易於維護和擴展的技術准則和規范，它產出物和體現為文檔和基礎代碼框架等。
因此選擇那些框架只是架構的一部分，通常是選擇自己善長的，以及對新技術的更新比較及時的；所以現在的Java框架最多為SpringMVC。
所以你提出的大並發是一個問題，但先確定它是不是所有模塊都需要解決這個問題。
而大數據又是另一個問題，同樣每個模塊查詢或者計算都是大數據嗎。
綜上所述將問題定位並分解，並發問題，要考慮帶寬還是區域網，一個應用伺服器最大能支持多少請求連接，你需要多少個，每個應用伺服器是獨立的模塊呢還是齊群。齊群還要注意的登錄一次還是多次，也就是SSO了，是否注意內存共享，如sessionId，是否考慮內存相互同步還是通過分布式的解決等糸列問題。還有一個資料庫有多少連接可以用等跟應用伺服器同理。
那麼大數據呢，要考慮的關鍵為兩個，是計算還是查詢，是實時的業務要求還是可以延時的，查詢可以是緩存，分表分庫，分區，索引等方式。緩存的時候要注意你考慮的帶寬是一個lDC還是多個IDC，數據間怎麼同歩是個分布式問題，如果大數據計算問題是否考慮一下雲計算解決方案等
因此你所說的怎麼架構，如何選框架，這是兩個問題，不是解決你問的大數據大並發，反而是架構工作中的一個塵灰而已。你也知道架構最大的是那裡了吧一一分析到分割。
架構是很難的工作，作不好，別相信用硬體能解決問題。就像使用微軟的 盜版一樣，出了問題可能是用N的成本來解決，N可能是幾萬，也可能是幾萬的N次方。
8、用Java做一個大流量，高並發的網站應該怎麼樣進行底層構架
JVM
JEE容器中運行的JVM參數配置參數的正確使用直接關繫到整個系統的性能和處理能力，的調優主要是對內存管理方面的調優，優化的方向分為以下4點：
1.HeapSize 堆的大小，也可以說Java虛擬機使用內存的策略，這點是非常關鍵的。
2.GarbageCollector 通過配置相關的參數進行Java中的垃圾收集器的4個演算法(策略)進行使用。
3.StackSize 棧是JVM的內存指令區,每個線程都有他自己的Stack，Stack的大小限制著線程的數量。
4.DeBug/Log 在JVM中還可以設置對JVM運行時的日誌和JVM掛掉後的日誌輸出，這點非常的關鍵，根據各類JVM的日誌輸出才能配置合適的參數。
網上隨處可見JVM的配置技巧，但是我還是推薦閱讀Sun官方的2篇文章，可以對配置參數的其所依然有一個了解
1.Java HotSpot VM Options
Java HotSpot VM Options
2.Troubleshooting Guide for Java SE 6 with HotSpot VMTroubleshooting Guide for Java SE 6 with HotSpot VM
另外，我相信不是每個人攻城師都是天天對著這些JVM參數的，如果你忘記了那些關鍵的參數你可以輸入Java -X(大寫X)進行提示。
JDBC
針對MySQL的JDBC的參數在之前的文章中也有介紹過，在單台機器或者集群的環境下合理的使用JDBC中的配置參數對操作資料庫也有很大的影響。
一些所謂高性能的 Java ORM開源框架也就是打開了很多JDBC中的默認參數：
1.例如：autoReconnect、prepStmtCacheSize、cachePrepStmts、useNewIO、blobSendChunkSize 等，
2.例如集群環境下：roundRobinLoadBalance、failOverReadOnly、autoReconnectForPools、secondsBeforeRetryMaster。
具體內容可以參閱MySQL的JDBC官方使用手冊：
http://dev.mysql.com/doc/refman/5.1/zh/connectors.html#cj-jdbc-reference
資料庫連接池(DataSource)
應用程序與資料庫連接頻繁的交互會給系統帶來瓶頸和大量的開銷會影響到系統的性能，JDBC連接池負責分配、管理和釋放資料庫連接，它允許應用程序重復使用一個現有的資料庫連接，而再不是重新建立一個連接，因此應用程序不需要頻繁的與資料庫開關連接，並且可以釋放空閑時間超過最大空閑時間的資料庫連接來避免因為沒有釋放資料庫連接而引起的資料庫連接遺漏。這項技術能明顯提高對資料庫操作的性能。
在此我認為有一點需要說明：
連接池的使用也是需要關閉，因為在資料庫連接池啟動的時候就預先和資料庫獲得了相應的連接，之後不再需要應用程序直接的和資料庫打交道，因為應用程序使用資料庫連接池是一個「借」的概念，應用程序從資料庫連接池中獲得資源是「借出」，還需要還回去，就好比有20個水桶放在這里，需要拿水的人都可以使用這些木桶從水池裡面拿水，如果20個人都拿完水，不將水桶還回原地，那麼後面來的人再需要拿水，只能在旁邊等待有人將木桶還回去，之前的人用完後需要放回去，不然後面的人就會一直等待，造成資源堵塞，同理，應用程序獲取資料庫連接的時候Connection連接對象的時候是從「池」中分配一個資料庫連接出去，在使用完畢後，歸還這個資料庫連接，這樣才能保持資料庫的連接「有借有還」准則。
參考資料：
http://dev.mysql.com/doc/refman/5.1/zh/connectors.html#cj-connection-pooling
數據存取
資料庫伺服器的優化和數據的存取，什麼類型的數據放在什麼地方更好是值得去思考的問題，將來的存儲很可能是混用的，Cache，NOSQL，DFS，DataBase 在一個系統中都會有，生活的餐具和平日里穿衣服需要擺放在家裡，但是不會用同一種類型的傢具存放，貌似沒有那個人家把餐具和衣服放在同一個櫃子裡面的。這就像是系統中不同類型的數據一樣，對不同類型的數據需要使用合適的存儲環境。文件和圖片的存儲，首先按照訪問的熱度分類，或者按照文件的大小。強關系類型並且需要事務支持的採用傳統的資料庫，弱關系型不需要事務支持的可以考慮NOSQL，海量文件存儲可以考慮一下支持網路存儲的DFS，至於緩存要看你單個數據存儲的大小和讀寫的比例。
還有一點值得注意就是數據讀寫分離，無論在DataBase還是NOSQL的環境中大部分都是讀大於寫，因此在設計時還需考慮 不僅僅需要讓數據的讀分散在多台機器上，還需要考慮多台機器之間的數據一致性，MySQL的一主多從，在加上MySQL-Proxy或者借用JDBC中的一些參數(roundRobinLoadBalance、failOverReadOnly、autoReconnectForPools、secondsBeforeRetryMaster)對後續應用程序開發，可以將讀和寫分離，將大量讀的壓力分散在多台機器上，並且還保證了數據的一致性。
緩存
在宏觀上看緩存一般分為2種：本地緩存和分布式緩存
1.本地緩存，對於Java的本地緩存而言就是講數據放入靜態(static)的數據結合中，然後需要用的時候就從靜態數據結合中拿出來,對於高並發的環境建議使用 ConcurrentHashMap或者CopyOnWriteArrayList作為本地緩存。緩存的使用更具體點說就是對系統內存的使用，使用多少內存的資源需要有一個適當比例，如果超過適當的使用存儲訪問，將會適得其反，導致整個系統的運行效率低下。
2. 分布式緩存，一般用於分布式的環境，將每台機器上的緩存進行集中化的存儲，並且不僅僅用於緩存的使用范疇，還可以作為分布式系統數據同步/傳輸的一種手段，一般被使用最多的就是Memcached和Redis。
數據存儲在不同的介質上讀/寫得到的效率是不同的，在系統中如何善用緩存，讓你的數據更靠近cpu，下面有一張圖你需要永遠牢記在心裡，來自Google的技術大牛Jeff Dean(Ref)的傑作，如圖所示：
並發/多線程
在高並發環境下建議開發者使用JDK中自帶的並發包(java.util.concurrent)，在JDK1.5以後使用java.util.concurrent下的工具類可以簡化多線程開發，在java.util.concurrent的工具中主要分為以下幾個主要部分：
1.線程池，線程池的介面(Executor、ExecutorService)與實現類(ThreadPoolExecutor、 ScheledThreadPoolExecutor），利用jdk自帶的線程池框架可以管理任務的排隊和安排，並允許受控制的關閉。因為運行一個線程需要消耗系統CPU資源，而創建、結束一個線程也對系統CPU資源有開銷，使用線程池不僅僅可以有效的管理多線程的使用，還是可以提高線程的運行效率。
2.本地隊列，提供了高效的、可伸縮的、線程安全的非阻塞 FIFO 隊列。java.util.concurrent 中的五個實現都支持擴展的 BlockingQueue 介面，該介面定義了 put 和 take 的阻塞版本：LinkedBlockingQueue、ArrayBlockingQueue、SynchronousQueue、PriorityBlockingQueue 和 DelayQueue。這些不同的類覆蓋了生產者-使用者、消息傳遞、並行任務執行和相關並發設計的大多數常見使用的上下文。
9、用Java做一個大流量、高並發的網站應該怎麼樣進行底層構架？採用哪些框架技術比較適合？
一個字：分
分而治之，多級分流
瀏覽器端、伺服器前端、中間層、資料庫端
每個地方都有可以分流的可能