❶ 如何處理大量數據高並發大流量並發操作方案
大數據並發處理解決方案：
1、HTML靜態化
效率最高、消耗最小的就是純靜態化的html頁面，所以盡可能使網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，無法全部手動去挨個實現，於是出現了常見的信息發布系統CMS，像常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
2、圖片伺服器分離
對於Web伺服器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片伺服器，甚至很多台圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為圖片問題而崩潰，在應用伺服器和圖片伺服器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadMole，保證更高的系統消耗和執行效率。 這一實現起來是比較容易的一現，如果伺服器集群操作起來更方便，如果是獨立的伺服器，新手可能出現上傳圖片只能在伺服器本地的情況下，可以在令一台伺服器設置的IIS採用網路路徑來實現圖片伺服器，即不用改變程序，又能提高性能，但對於伺服器本身的IO處理性能是沒有任何的改變。
3、資料庫集群和庫表散列
大型網站都有復雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一台資料庫將很快無法滿足應用，於是需要使用資料庫集群或者庫表散列。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memory Cache是常用的緩存介面，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網站常採用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網路接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和ENet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這里不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量並發請求採用的終極解決辦法。 負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇。
硬體四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。第四層交換功能就象是虛IP，指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上，需要復雜的載量平衡演算法。在IP世界，業務類型由終端TCP或UDP埠地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP埠共同決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000台伺服器使用了三四台Alteon就搞定了。
❷ 股票實時交易系統如何實現高並發撮合交易最好有java架構
採用 Apama架構，篇幅所限，樓主可以網路，有很多詳細教程，主流很多交易系統都採用Apama
❸ 求教面向大規模連接的高並發網路模型，該如何處理
所謂並發伺服器就是在同一個時刻可以處理來自多個客戶端的請求;循環伺服器是指伺服器在同一時刻只可以響應一個客戶端的請求。而且對於TCP和UDP套接字，這兩種伺服器的實現方式也有不同的特點。
1、TCP循環伺服器：
首先TCP伺服器接受一個客戶端的連接請求，處理連接請求，在完成這個客戶端的所有請求後斷開連接，然後再接受下一個客戶端的請求。創建TCP循環伺服器的演算法如下：
復制代碼 代碼如下:
socket(……); //創建一個TCP套接字
bind(……); //邦定公認的埠號
listen(……); //傾聽客戶端連接
while(1) //開始循環接收客戶端連接
{
accept(……);//接收當前客戶端的連接
while(1)
{ //處理當前客戶端的請求
read(……);
process(……);
write(……);
}
close(……); //關閉當前客戶端的連接，准備接收下一個客戶端連接
}
TCP循環伺服器一次只處理一個客戶端的請求，如果有一個客戶端佔用伺服器不放時，其它的客戶機連接請求都得不到及時的響應。因此，TCP伺服器一般很少用循環伺服器模型的。
2、TCP並發伺服器：
並發伺服器的思想是每一個客戶端的請求並不由伺服器的主進程直接處理，而是伺服器主進程創建一個子進程來處理。創建TCP並發伺服器的演算法如下：
復制代碼 代碼如下:
socket(……); //創建一個TCP套接字
bind(……); //邦定公認的埠號
listen(……);//傾聽客戶端連接
while(1) //開始循環接收客戶端的接收
{
accept(……);//接收一個客戶端的連接
if(fork(……)==0) //創建子進程
{
while(1)
{ //子進程處理某個客戶端的連接
read(……);
process(……);
write(……);
}
close(……); //關閉子進程處理的客戶端連接
exit(……) ;//終止該子進程
}
close(……); //父進程關閉連接套接字描述符，准備接收下一個客戶端連接
}
TCP並發伺服器可以解決TCP循環伺服器客戶端獨占伺服器的情況。但同時也帶來了一個不小的問題，即響應客戶機的請求，伺服器要創建子進程來處理，而創建子進程是一種非常消耗資源的操作。
3、UDP循環伺服器：
UDP伺服器每次從套接字上讀取一個客戶端的數據報請求，處理接收到的UDP數據報，然後將結果返回給客戶機。創建UDP循環伺服器的演算法如下：
1 socket(……); //創建一個數據報類型的套接字 2 bind(……); //邦定公認的短口號 3 while(1) //開始接收客戶端的連接 4 { //接收和處理客戶端的UDP數據報 5 recvfrom(……); 6 process(……); 7 sendto(……);//准備接收下一個客戶機的數據報 8 }
消除行號
因為UDP是非面向連接的，沒有一個客戶端可以獨占伺服器。只要處理過程不是死循環，伺服器對於每一個客戶機的請求總是能夠處理的。
UDP循環伺服器在數據報流量過大時由於處理任務繁重可能造成客戶技數據報丟失，但是因為UDP協議本身不保證數據報可靠到達，所以UDP協議是允許丟失數據報的。
鑒於以上兩點，一般的UDP伺服器採用循環方式4、UDP並發伺服器把並發的概念應用UDP就得到了並發UDP伺服器，和並發TCP伺服器模型一樣是創建子進程來處理的。
創建UDP並發伺服器的演算法如下：
復制代碼 代碼如下:
socket(……); //創建一個數據報類型的套接字
bind(……); //邦定公認的短口號
while(1) //開始接收客戶端的連接
{ //接收和處理客戶端的UDP數據報
recvfrom(……);
if(fork(……)==0) //創建子進程
{
rocess(……);
sendto(……);
}
}
除非伺服器在處理客戶端的請求所用的時間比較長以外，人們實際上很少用這種UDP並發伺服器模型的。
4、多路復用I/O並發伺服器：
創建子進程會帶來系統資源的大量消耗，為了解決這個問題，採用多路復用I/O模型的並發伺服器。採用select函數創建多路復用I/O模型的並發伺服器的演算法如下：
初始化(socket，bind，listen);
復制代碼 代碼如下:
while(1)
{
設置監聽讀寫文件描述符(FD_*);
調用select;
如果是傾聽套接字就緒，說明一個新的連接請求建立
{
建立連接(accept);
加入到監聽文件描述符中去;
}
否則說明是一個已經連接過的描述符
{
進行操作(read或者write);
}
多路復用I/O可以解決資源限制問題，此模型實際上是將UDP循環模型用在了TCP上面。這也會帶了一些問題，如由於伺服器依次處理客戶的請求，所以可能導致友的客戶會等待很久。
❹ 學習大數據量，高並發處理應該看什麼書
先學測試吧。不是那種業務功能的測試，是系統的測試。因為要解決大數據量、高並發的問題，我個人的知識與經驗是： 1、先用單機測試。用工具產生大並發量去轟擊伺服器，直至伺服器緩慢，甚至接近崩潰； 3、找到系統瓶頸後，優化，解決這個瓶頸，然後再循環測試。這時你又會發現新的瓶頸，再解決。循環1 - 3步，直到各方面基本平衡為止。 4、當單機無法解決問題的時候，接著開始考慮負載均衡，考慮分布式方案，然後再用 1 - 3 的步驟分析與測試。
❺ 如何設計一個支持高並發的高可用服務
服務程序最為關鍵的設計是並發服務模型，當前有以下幾種典型的模型：-單進程服務，使用非阻塞IO使用一個進程服務多個客戶，通常與客戶通信的套接字設置為非阻塞的，阻塞只發生在select()、poll()、epoll_wait()等系統調用上面。這是一種行之有效的單進程狀態機式服務方式，已被廣泛採用。缺點是它無法利用SMP(對稱多處理器)的優勢，除非啟動多個進程。此外，它嘗試就緒的IO文件描述符後，立即從系統調用返回，這會導致大量的系統調用發生，尤其是在較慢的位元組傳輸時。select()本身的實現也是有局限的：能打開的文件描述符最多不能超過FD_SETSIZE，很容易耗盡；每次從select()返回的描述符組中掃描就緒的描述符需要時間，如果就緒的描述符在末尾時更是如此（epoll特別徹底修復了這個問題）。-多進程服務，使用阻塞IO也稱作accept/fork模型，每當有客戶連線時產生一個新的進程為之服務。這種方式有時是必要的，比如可以通過操作系統獲得良好的內存保護，可以以不同的用戶身份運行程序，可以讓服務運行在不同的目錄下面。但是它的缺點也很明顯：進程比較占資源，進程切換開銷太大，共享某些信息比較麻煩。Apache1.3就使用了這種模型，MaxClients數很容易就可以達到。-多線程服務，使用阻塞IO也稱之accept/pthread_create模型，有新客戶來時創建一個服務線程而不是服務進程。這解決了多進程服務的一些問題，比如它佔用資源少，信息共享方便。但是麻煩在於線程仍有可能消耗光，線程切換也需要開銷。-混合服務方式所謂的混合服務方式，以打破服務方和客戶方之間嚴格的1:1關系。基本做法是：新客戶到來時創建新的工作線程，當該工作線程檢測到網路IO會有延遲時停止處理過程，返回給Server一個延遲處理狀態，同時告訴Server被延遲的文件描述符，延遲超時時間。Server會在合適的時候返回工作線程繼續處理。注意這里的工作線程不是通過pthread_create()創建的，而是被包裝在專門用於處理延遲工作的函數里。這里還有一個問題，工作線程如何檢測網路IO會有延遲？方法有很多，比如設置較短的超時時間調用poll()，或者甚至使用非阻塞IO。如果是套接字，可以設置SO_RCVTIMEO和SO_SNDTIMEO選項，這樣更有效率。除了延遲線程，Server還應提供了未完成線程的支持。如有有特別耗費時間的操作，你可以在完成部分工作後停止處理，返回給Server一個未完成狀態。這樣Server會檢查工作隊列是否有別的線程，如果有則讓它們運行，否則讓該工作線程繼續處理，這可以防止某些線程挨餓。典型的一個混合服務模型開源實現ServerKitServerkit的這些線程支持功能可簡化我們的服務程序設計，效率上應該也是有保證的。2.隊列(queue)ServerKit提供的隊列是一個單向鏈表，隊列的存取是原子操作，如果只有一個執行單元建議不要用，因為原子操作的開銷較大。3.堆(heap)malloc()分配內存有一定的局限，比如在多線程的環境里，需要序列化內存分配操作。ServerKit提供的堆管理函數，可快速分配內存，可有效減少分配內存的序列化操作，堆的大小可動態增長，堆有引用計數，這些特徵比較適合多線程環境。目前ServerKit堆的最大局限是分配單元必須是固定大小。4.日誌記錄日誌被保存在隊列，有一個專門的線程處理隊列中的日誌記錄：它或者調用syslog()寫進系統日誌，或者通過UDP直接寫到遠程機器。後者更有效。5.讀寫鎖GNUlibc也在pthreads庫里實現了讀寫鎖，如果定義了__USE_UNIX98就可以使用。不過ServerKit還提供了讀寫鎖互相轉換的函數，這使得鎖的應用更為彈性。比如擁有讀鎖的若干個線程對同一個hash表進行檢索，其中一個線程檢索到了數據，此時需要修改它，一種法是獲取寫鎖，但這會導致釋放讀鎖和獲取寫鎖之間存在時間窗，另一種法是使用ServerKit提供的函數把讀鎖轉換成寫鎖，無疑這種方式更有效率。除了以上這些功能，ServerKit還提供了資料庫連接池的管理（當前只支持MySQL）和序列化（Sequences），如感興趣可參見相關的API文檔。二、ServerKit服務模塊編寫ServerKit由3部分組成：server程序，負責載入服務模塊、解析配置文件、建立資料庫連接池；libserver，動態鏈接庫，提供所有功能的庫支持，包括server本身也是調用這個庫寫的；API，編程介面，你編寫的服務模塊和ServerKit框架進行對話的介面。ServerKit需要libConfuse解析配置文件，所以出了安裝ServerKit，還需要安裝libConfuse。關於libConfuse可參考。下面我們看一個簡單的服務模塊FOO：#include#includestaticlongintsleep_ration;staticintFOO_construct(){fprintf(stderr,"FOO_construct\n");return1;}staticintFOO_prestart(cfg_t*configuration){fprintf(stderr,"FOO_prestart\n");return1;}staticvoid*FOO_operator(void*foobar){fprintf(stderr,"FOO_operator\n");for(;;)sleep(sleep_ration);returnNULL;}staticvoidFOO_report(void){fprintf(stderr,"FOO_report\n");}staticcfg_opt_tFOO_config[]={CFG_SIMPLE_INT("sleep_ration",&sleep_ration),CFG_END()};staticchar*FOO_authors[]={"VitoCaputo",NULL};SERVER_MODULE(FOO,0,0,1,"")按以下方法編譯：$gcc-c-fPIC-pthread-D_REENTRANT-gFOO.c$gcc-shared-lserver-lconfuse-lpthread-g-e__server_mole_main-oFOO.soFOO.o-e選項指定程序運行入口，這使得你可以直接在命令行敲./FOO.so運行模塊。server程序根據環境變數SERVER_PERSONALITY_PATH定位主目錄，並查找主目錄下的c11n作為配置文件，動態載入的模塊需放在主目錄下的moles目錄。$exportSERVER_PERSONALITY_PATH=`pwd`$mkdirmoles$cpFOO.somoles$vic11nc11n的內容：identity="any_id"FOO{sleep_ration=1;}identity標識server實例，用ps可看到程序名稱形如server.identity，本例為server.any_id。執行server啟動服務程序。三、ServerKit其他功能缺陷缺乏daemon模式；只能運行在Linuxbox；DBpool只支持MySQL；Heap管理內存的功力有限
❻ 高並發時如何生成唯一編號
使用uuid。uuid的演算法是生成全球唯一的id
❼ 關於MySQL高並發處理機制是如何實現
mysql的最大連接數默認是100, 這個數值對於並發連接很多的資料庫應用是遠遠不夠的，當連接請求大於默認連接數後，就會出現無法連接資料庫的錯誤，因此我們需要把它適當調大一些。
調節方法為：
1.linux伺服器中：改my.cnf中的值就行了
2.Windows伺服器中（我用的）:
在文件「my.ini」中找到段 [mysqld],在其中添加一行
max_connections=200 ### 200可以更改為想設置成的值.
然後重啟"mysql"服務。
/mysqladmin所在路徑/mysqladmin -uroot -p variables
輸入root資料庫賬號的密碼後可看到
| max_connections | 1000 |
其他需注意的：
在編程時，由於用mysql語句調用資料庫時，在每次之執行語句前，會做一個臨時的變數用來打開資料庫，所以你在使用mysql語句的時候，記得在每次調用完mysql之後就關閉mysql臨時變數。
另外對於訪問量大的，可以考慮直接寫到文本中，根據預測的訪問量，先定義假若是100個文件文件名依次為1.txt,2.txt...100.txt。需要的時候，再對所有文本文件中的數據進行分析，再導入資料庫。
❽ 什麼是多線程和高並發
「高並發和多線程」總是被一起提起，給人感覺兩者好像相等，實則 高並發 ≠ 多線程
多線程是完成任務的一種方法，高並發是系統運行的一種狀態，通過多線程有助於系統承受高並發狀態的實現。
高並發是一種系統運行過程中遇到的一種「短時間內遇到大量操作請求」的情況，主要發生在web系統集中大量訪問或者socket埠集中性收到大量請求（例如：12306的搶票情況；天貓雙十一活動）。該情況的發生會導致系統在這段時間內執行大量操作，例如對資源的請求，資料庫的操作等。如果高並發處理不好，不僅僅降低了用戶的體驗度（請求響應時間過長），同時可能導致系統宕機，嚴重的甚至導致OOM異常，系統停止工作等。如果要想系統能夠適應高並發狀態，則需要從各個方面進行系統優化，包括，硬體、網路、系統架構、開發語言的選取、數據結構的運用、演算法優化、資料庫優化……而多線程只是其中解決方法之一。
❾ 股票實時交易系統如何實現高並發撮合交易最好有java架構
分布式架構最適合不過了，分布式架構+負載均衡支持百萬級數據。！！！
❿ 股票實時交易系統如何實現高並發撮合交易最好有java架構
你得補充買一價與賣一價才能回答你啊
連續競價成交價格的確定
(1)成交價格的確定原則
①最高買人申報價格與最低賣出申報價格相同，以該價格為成交價格。
例如，某隻股票的委託情況為：買-7.85元、買二7.68元；賣7.85元、賣二7。90元，那麼7. 85元為成交價格。
②買入申報價格高於即時最低賣出申報價格的，以即時最低賣出申報價格為成交價格。
例如，某隻股票的委託情況為：賣-7.85元、賣二7.90元，此時若有以7. 89元買入的委託，則以最低賣出價7.85元為成交價。
③賣出申報價格低於即時最高買人申報價格的，以即時最高買人申報價格為成交價格。
例如，某隻股票的委託情況為：買一7. 85元、買二7.68元；若此時有以7. 69元賣出的委託，則以最高買入價7。85元成交。