示例程式
小結在使用多台裝置處理海量資料的時候,主要有兩種方案:流量分流和業務分流。
流量分流也就是我們常說的集群架構,這裡不細說,可以看一下我之前的文件:高併發伺服器學習筆記之十一:集群架構
業務分流也就是我們常說的分布式架構,是今天的主要內容。
乙個完成的系統,是由多個業務組成,業務之間相互協調來完成工作。而分布式架構區別於傳統的集中式架構,就是將不同的業務分別架設在不同的機器上,彼此之間使用rpc協議進行協調工作。
這次我們來做乙個簡單的數**算系統,只支援加法和乘法,採用分布式架構,將加法和乘法分別部署在兩個節點上,並用rpc協議進行通訊。實際開發中,有時候為了一些安全問題,不會將業務分發直接寫在客戶端,而是用乙個業務分發伺服器去處理,由於我們只是練習的示例**,業務分發伺服器就不加了,直接將業務分發寫在客戶端。關於業務節點列表,應給寫在乙個配置檔案裡,程式在執行的時候實時讀取,我們這裡為了簡單,直接寫死在**裡。
完整**戳這裡
簡單說就是各個業務節點之間的通訊協議,這個協議可以自己定乙個私有協議,也可以用一些公開協議,比如jsonrpc,我們這裡簡單一點,定義乙個簡單的私有協議,乙個結構體,包含兩個運算數和乙個結果
typedef struct __messages
message;
客戶端比較簡單,首先向加法伺服器傳送乙個加法運算申請,並等待結果返回,然後再向乘法伺服器傳送乙個乘法運算申請,等待結果返回
#include #include #include #include #include #include /* see notes */
#include #include #include /* superset of previous */
#include #include "public_head.h"
#include "fileio.h"
#define listen_backlog 50
#define add_ip "127.0.0.1"
#define add_port 10086
#define mul_ip add_ip
#define mul_port 10010
int main(int argc, char ** ar**)
write(sockfd, &addmessage, sizeof(message));
read(sockfd, &addmessage, sizeof(message));
printf("%d + %d = %d\n", addmessage.arg1, addmessage.arg2, addmessage.result);
sleep(1);
close(sockfd);
if ((sockfd = socket(af_inet, sock_stream, 0)) < 0)
handle_error("socket");
mulserver_addr.sin_family = af_inet;
mulserver_addr.sin_port = htons(mul_port);
inet_pton(sockfd, mul_ip, &mulserver_addr.sin_addr.s_addr);
mulmessage.arg1 = 3;
mulmessage.arg2 = 5;
if (connect(sockfd, (struct sockaddr*) & mulserver_addr, sizeof(mulserver_addr)) < 0)
write(sockfd, &mulmessage, sizeof(message));
read(sockfd, &mulmessage, sizeof(message));
printf("%d x %d = %d\n", mulmessage.arg1, mulmessage.arg2, mulmessage.result);
sleep(1);
close(sockfd);
return 0;
}
加法伺服器也比較簡單,接收到客戶端的加法運算請求後,用客戶端給的引數進行加法運算,再將結果返回
static void handle_request(int acceptfd)
close(acceptfd);
return;
}
乘法伺服器可以如同加法伺服器一樣簡單實現,但我們這裡為了演示業務伺服器之間的協調工作,乘法採用呼叫加法伺服器進行結果累加去實現
static void handle_request(int acceptfd)
for(i = 0; i < message.arg2; ++i)
close(sockfd);
message.result = addmessage.result;
write(acceptfd, &message, sizeof(message));
} printf("\n");
close(acceptfd);
return;
}
通過以上**我們可以看出,採用分布式架構,不但可以進行業務分流,提高資料處理量,更是簡化的服務端的**。分布式架構的難點不在於**,而在於業務的拆分和rpc協議的制定。業務怎麼拆分才合理,能夠讓各個業務節點的流量達到最佳平衡點,如果乙個業務節點經常閒置,另乙個業務節點經常爆滿,這顯然是不合適的,不過這個問題倒是可以通過集群架構進行緩解。 高併發伺服器學習筆記之七 非同步IO poll模型
poll模型和select模型很相似。兩者間的主要區別在於我們要如何指定待檢查的檔案描述符。在select中,我們提供三個集合,在每個集合中標明我們感興趣的檔案描述符。而在poll中我們提供一列檔案描述符,並在每個檔案描述符上標明我們感興趣的事件,完整 戳這裡 用到的系統呼叫如下 include i...
高併發伺服器學習筆記之四 多執行緒模型
該模型和多程序模型的思想類似,只是把程序換成了執行緒,因為執行緒的建立比程序建立開銷小。但這並不是說多執行緒就一定比多程序優秀,程序和執行緒都有各自的優缺點,具體請自行查閱執行緒和程序相關的內容,完整 戳這裡 include include include include include inclu...
(五十二)高併發伺服器 多執行緒模型
在使用執行緒模型開發伺服器時需考慮以下問題 1.調整程序內最大檔案描述符上限 2.執行緒如有共享資料,考慮執行緒同步 3.服務於客戶端執行緒退出時,退出處理。退出值,分離態 4.系統負載,隨著鏈結客戶端增加,導致其它執行緒不能及時得到cpu 多執行緒的機制一般是使用執行緒池,模型如下 0 以下是出錯...