99精品伊人亚洲|最近国产中文炮友|九草在线视频支援|AV网站大全最新|美女黄片免费观看|国产精品资源视频|精彩无码视频一区|91大神在线后入|伊人终合在线播放|久草综合久久中文

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

效率加倍,高并發(fā)場景下的接口請求合并方案

jf_ro2CN3Fa ? 來源:芋道源碼 ? 2023-01-13 10:09 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群


前言

請求合并到底有什么意義呢?我們來看下圖。

281af012-92e3-11ed-bfe3-dac502259ad0.png

假設我們3個用戶(用戶id分別是1、2、3),現(xiàn)在他們都要查詢自己的基本信息,請求到服務器,服務器端請求數(shù)據(jù)庫,發(fā)出3次請求。我們都知道數(shù)據(jù)庫連接資源是相當寶貴的,那么我們怎么盡可能節(jié)省連接資源呢?

這里把數(shù)據(jù)庫換成被調用的遠程服務,也是同樣的道理。

我們改變下思路,如下圖所示。

28311838-92e3-11ed-bfe3-dac502259ad0.png

我們在服務器端把請求合并,只發(fā)出一條SQL查詢數(shù)據(jù)庫,數(shù)據(jù)庫返回后,服務器端處理返回數(shù)據(jù),根據(jù)一個唯一請求ID,把數(shù)據(jù)分組,返回給對應用戶。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

  • 項目地址:https://github.com/YunaiV/ruoyi-vue-pro
  • 視頻教程:https://doc.iocoder.cn/video/

技術手段

  • LinkedBlockQueue 阻塞隊列
  • ScheduledThreadPoolExecutor 定時任務線程池
  • CompleteableFuture future 阻塞機制(Java 8 的 CompletableFuture 并沒有 timeout 機制,后面優(yōu)化,使用了隊列替代)

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

  • 項目地址:https://github.com/YunaiV/yudao-cloud
  • 視頻教程:https://doc.iocoder.cn/video/

代碼實現(xiàn)

查詢用戶的代碼

publicinterfaceUserService{

MapqueryUserByIdBatch(ListuserReqs);
}
@Service
publicclassUserServiceImplimplementsUserService{

@Resource
privateUsersMapperusersMapper;

@Override
publicMapqueryUserByIdBatch(ListuserReqs){
//全部參數(shù)
ListuserIds=userReqs.stream().map(UserWrapBatchService.Request::getUserId).collect(Collectors.toList());
QueryWrapperqueryWrapper=newQueryWrapper<>();
//用in語句合并成一條SQL,避免多次請求數(shù)據(jù)庫的IO
queryWrapper.in("id",userIds);
Listusers=usersMapper.selectList(queryWrapper);
Map>userGroup=users.stream().collect(Collectors.groupingBy(Users::getId));
HashMapresult=newHashMap<>();
userReqs.forEach(val->{
ListusersList=userGroup.get(val.getUserId());
if(!CollectionUtils.isEmpty(usersList)){
result.put(val.getRequestId(),usersList.get(0));
}else{
//表示沒數(shù)據(jù)
result.put(val.getRequestId(),null);
}
});
returnresult;
}
}

合并請求的實現(xiàn)

packagecom.springboot.sample.service.impl;

importcom.springboot.sample.bean.Users;
importcom.springboot.sample.service.UserService;
importorg.springframework.stereotype.Service;

importjavax.annotation.PostConstruct;
importjavax.annotation.Resource;
importjava.util.*;
importjava.util.concurrent.*;

/***
*zzq
*包裝成批量執(zhí)行的地方
**/
@Service
publicclassUserWrapBatchService{
@Resource
privateUserServiceuserService;

/**
*最大任務數(shù)
**/
publicstaticintMAX_TASK_NUM=100;


/**
*請求類,code為查詢的共同特征,例如查詢商品,通過不同id的來區(qū)分
*CompletableFuture將處理結果返回
*/
publicclassRequest{
//請求id唯一
StringrequestId;
//參數(shù)
LonguserId;
//TODOJava8的CompletableFuture并沒有timeout機制
CompletableFuturecompletableFuture;

publicStringgetRequestId(){
returnrequestId;
}

publicvoidsetRequestId(StringrequestId){
this.requestId=requestId;
}

publicLonggetUserId(){
returnuserId;
}

publicvoidsetUserId(LonguserId){
this.userId=userId;
}

publicCompletableFuturegetCompletableFuture(){
returncompletableFuture;
}

publicvoidsetCompletableFuture(CompletableFuturecompletableFuture){
this.completableFuture=completableFuture;
}
}

/*
LinkedBlockingQueue是一個阻塞的隊列,內部采用鏈表的結果,通過兩個ReenTrantLock來保證線程安全
LinkedBlockingQueue與ArrayBlockingQueue的區(qū)別
ArrayBlockingQueue默認指定了長度,而LinkedBlockingQueue的默認長度是Integer.MAX_VALUE,也就是無界隊列,在移除的速度小于添加的速度時,容易造成OOM。
ArrayBlockingQueue的存儲容器是數(shù)組,而LinkedBlockingQueue是存儲容器是鏈表
兩者的實現(xiàn)隊列添加或移除的鎖不一樣,ArrayBlockingQueue實現(xiàn)的隊列中的鎖是沒有分離的,即添加操作和移除操作采用的同一個ReenterLock鎖,
而LinkedBlockingQueue實現(xiàn)的隊列中的鎖是分離的,其添加采用的是putLock,移除采用的則是takeLock,這樣能大大提高隊列的吞吐量,
也意味著在高并發(fā)的情況下生產者和消費者可以并行地操作隊列中的數(shù)據(jù),以此來提高整個隊列的并發(fā)性能。
*/
privatefinalQueuequeue=newLinkedBlockingQueue();

@PostConstruct
publicvoidinit(){
//定時任務線程池,創(chuàng)建一個支持定時、周期性或延時任務的限定線程數(shù)目(這里傳入的是1)的線程池
ScheduledExecutorServicescheduledExecutorService=Executors.newScheduledThreadPool(1);

scheduledExecutorService.scheduleAtFixedRate(()->{
intsize=queue.size();
//如果隊列沒數(shù)據(jù),表示這段時間沒有請求,直接返回
if(size==0){
return;
}
Listlist=newArrayList<>();
System.out.println("合并了["+size+"]個請求");
//將隊列的請求消費到一個集合保存
for(inti=0;i//后面的SQL語句是有長度限制的,所以還要做限制每次批量的數(shù)量,超過最大任務數(shù),等下次執(zhí)行
if(i//拿到我們需要去數(shù)據(jù)庫查詢的特征,保存為集合
ListuserReqs=newArrayList<>();
for(Requestrequest:list){
userReqs.add(request);
}
//將參數(shù)傳入service處理,這里是本地服務,也可以把userService看成RPC之類的遠程調用
Mapresponse=userService.queryUserByIdBatch(userReqs);
//將處理結果返回各自的請求
for(Requestrequest:list){
Usersresult=response.get(request.requestId);
request.completableFuture.complete(result);//completableFuture.complete方法完成賦值,這一步執(zhí)行完畢,下面future.get()阻塞的請求可以繼續(xù)執(zhí)行了
}
},100,10,TimeUnit.MILLISECONDS);
//scheduleAtFixedRate是周期性執(zhí)行schedule是延遲執(zhí)行initialDelay是初始延遲period是周期間隔后面是單位
//這里我寫的是初始化后100毫秒后執(zhí)行,周期性執(zhí)行10毫秒執(zhí)行一次
}

publicUsersqueryUser(LonguserId){
Requestrequest=newRequest();
//這里用UUID做請求id
request.requestId=UUID.randomUUID().toString().replace("-","");
request.userId=userId;
CompletableFuturefuture=newCompletableFuture<>();
request.completableFuture=future;
//將對象傳入隊列
queue.offer(request);
//如果這時候沒完成賦值,那么就會阻塞,直到能夠拿到值
try{
returnfuture.get();
}catch(InterruptedExceptione){
e.printStackTrace();
}catch(ExecutionExceptione){
e.printStackTrace();
}
returnnull;
}
}

控制層調用

/***
*請求合并
**/
@RequestMapping("/merge")
publicCallablemerge(LonguserId){
returnnewCallable(){
@Override
publicUserscall()throwsException{
returnuserBatchService.queryUser(userId);
}
};
}

Callable是什么可以參考:

  • https://blog.csdn.net/baidu_19473529/article/details/123596792

模擬高并發(fā)查詢的代碼

packagecom.springboot.sample;

importorg.springframework.web.client.RestTemplate;

importjava.util.Random;
importjava.util.concurrent.CountDownLatch;

publicclassTestBatch{
privatestaticintthreadCount=30;

privatefinalstaticCountDownLatchCOUNT_DOWN_LATCH=newCountDownLatch(threadCount);//為保證30個線程同時并發(fā)運行

privatestaticfinalRestTemplaterestTemplate=newRestTemplate();

publicstaticvoidmain(String[]args){


for(inti=0;i//循環(huán)開30個線程
newThread(newRunnable(){
publicvoidrun(){
COUNT_DOWN_LATCH.countDown();//每次減一
try{
COUNT_DOWN_LATCH.await();//此處等待狀態(tài),為了讓30個線程同時進行
}catch(InterruptedExceptione){
e.printStackTrace();
}

for(intj=1;j<=?3;j++){
intparam=newRandom().nextInt(4);
if(param<=0){
param++;
}
StringresponseBody=restTemplate.getForObject("http://localhost:8080/asyncAndMerge/merge?userId="+param,String.class);
System.out.println(Thread.currentThread().getName()+"參數(shù)"+param+"返回值"+responseBody);
}
}
}).start();

}
}
}

測試效果

283d32f8-92e3-11ed-bfe3-dac502259ad0.png284d3d4c-92e3-11ed-bfe3-dac502259ad0.png

要注意的問題

  • Java 8 的 CompletableFuture 并沒有 timeout 機制
  • 后面的SQL語句是有長度限制的,所以還要做限制每次批量的數(shù)量,超過最大任務數(shù),等下次執(zhí)行(本例中加了MAX_TASK_NUM判斷)

使用隊列的超時解決Java 8 的 CompletableFuture 并沒有 timeout 機制

核心代碼

packagecom.springboot.sample.service.impl;

importcom.springboot.sample.bean.Users;
importcom.springboot.sample.service.UserService;
importorg.springframework.stereotype.Service;

importjavax.annotation.PostConstruct;
importjavax.annotation.Resource;
importjava.util.*;
importjava.util.concurrent.*;

/***
*zzq
*包裝成批量執(zhí)行的地方,使用queue解決超時問題
**/
@Service
publicclassUserWrapBatchQueueService{
@Resource
privateUserServiceuserService;

/**
*最大任務數(shù)
**/
publicstaticintMAX_TASK_NUM=100;


/**
*請求類,code為查詢的共同特征,例如查詢商品,通過不同id的來區(qū)分
*CompletableFuture將處理結果返回
*/
publicclassRequest{
//請求id
StringrequestId;

//參數(shù)
LonguserId;
//隊列,這個有超時機制
LinkedBlockingQueueusersQueue;


publicStringgetRequestId(){
returnrequestId;
}

publicvoidsetRequestId(StringrequestId){
this.requestId=requestId;
}

publicLonggetUserId(){
returnuserId;
}

publicvoidsetUserId(LonguserId){
this.userId=userId;
}

publicLinkedBlockingQueuegetUsersQueue(){
returnusersQueue;
}

publicvoidsetUsersQueue(LinkedBlockingQueueusersQueue){
this.usersQueue=usersQueue;
}
}

/*
LinkedBlockingQueue是一個阻塞的隊列,內部采用鏈表的結果,通過兩個ReenTrantLock來保證線程安全
LinkedBlockingQueue與ArrayBlockingQueue的區(qū)別
ArrayBlockingQueue默認指定了長度,而LinkedBlockingQueue的默認長度是Integer.MAX_VALUE,也就是無界隊列,在移除的速度小于添加的速度時,容易造成OOM。
ArrayBlockingQueue的存儲容器是數(shù)組,而LinkedBlockingQueue是存儲容器是鏈表
兩者的實現(xiàn)隊列添加或移除的鎖不一樣,ArrayBlockingQueue實現(xiàn)的隊列中的鎖是沒有分離的,即添加操作和移除操作采用的同一個ReenterLock鎖,
而LinkedBlockingQueue實現(xiàn)的隊列中的鎖是分離的,其添加采用的是putLock,移除采用的則是takeLock,這樣能大大提高隊列的吞吐量,
也意味著在高并發(fā)的情況下生產者和消費者可以并行地操作隊列中的數(shù)據(jù),以此來提高整個隊列的并發(fā)性能。
*/
privatefinalQueuequeue=newLinkedBlockingQueue();

@PostConstruct
publicvoidinit(){
//定時任務線程池,創(chuàng)建一個支持定時、周期性或延時任務的限定線程數(shù)目(這里傳入的是1)的線程池
ScheduledExecutorServicescheduledExecutorService=Executors.newScheduledThreadPool(1);

scheduledExecutorService.scheduleAtFixedRate(()->{
intsize=queue.size();
//如果隊列沒數(shù)據(jù),表示這段時間沒有請求,直接返回
if(size==0){
return;
}
Listlist=newArrayList<>();
System.out.println("合并了["+size+"]個請求");
//將隊列的請求消費到一個集合保存
for(inti=0;i//后面的SQL語句是有長度限制的,所以還要做限制每次批量的數(shù)量,超過最大任務數(shù),等下次執(zhí)行
if(i//拿到我們需要去數(shù)據(jù)庫查詢的特征,保存為集合
ListuserReqs=newArrayList<>();
for(Requestrequest:list){
userReqs.add(request);
}
//將參數(shù)傳入service處理,這里是本地服務,也可以把userService看成RPC之類的遠程調用
Mapresponse=userService.queryUserByIdBatchQueue(userReqs);
for(RequestuserReq:userReqs){
//這里再把結果放到隊列里
Usersusers=response.get(userReq.getRequestId());
userReq.usersQueue.offer(users);
}

},100,10,TimeUnit.MILLISECONDS);
//scheduleAtFixedRate是周期性執(zhí)行schedule是延遲執(zhí)行initialDelay是初始延遲period是周期間隔后面是單位
//這里我寫的是初始化后100毫秒后執(zhí)行,周期性執(zhí)行10毫秒執(zhí)行一次
}

publicUsersqueryUser(LonguserId){
Requestrequest=newRequest();
//這里用UUID做請求id
request.requestId=UUID.randomUUID().toString().replace("-","");
request.userId=userId;
LinkedBlockingQueueusersQueue=newLinkedBlockingQueue<>();
request.usersQueue=usersQueue;
//將對象傳入隊列
queue.offer(request);
//取出元素時,如果隊列為空,給定阻塞多少毫秒再隊列取值,這里是3秒
try{
returnusersQueue.poll(3000,TimeUnit.MILLISECONDS);
}catch(InterruptedExceptione){
e.printStackTrace();
}
returnnull;
}
}
...省略..

@Override
publicMapqueryUserByIdBatchQueue(ListuserReqs){
//全部參數(shù)
ListuserIds=userReqs.stream().map(UserWrapBatchQueueService.Request::getUserId).collect(Collectors.toList());
QueryWrapperqueryWrapper=newQueryWrapper<>();
//用in語句合并成一條SQL,避免多次請求數(shù)據(jù)庫的IO
queryWrapper.in("id",userIds);
Listusers=usersMapper.selectList(queryWrapper);
Map>userGroup=users.stream().collect(Collectors.groupingBy(Users::getId));
HashMapresult=newHashMap<>();
//數(shù)據(jù)分組
userReqs.forEach(val->{
ListusersList=userGroup.get(val.getUserId());
if(!CollectionUtils.isEmpty(usersList)){
result.put(val.getRequestId(),usersList.get(0));
}else{
//表示沒數(shù)據(jù),這里要new,不然加入隊列會空指針
result.put(val.getRequestId(),newUsers());
}
});
returnresult;
}

...省略...

小結

請求合并,批量的辦法能大幅節(jié)省被調用系統(tǒng)的連接資源,本例是以數(shù)據(jù)庫為例,其他RPC調用也是類似的道理。缺點就是請求的時間在執(zhí)行實際的邏輯之前增加了等待時間,不適合低并發(fā)的場景。

代碼地址

  • https://gitee.com/apple_1030907690/spring-boot-kubernetes/tree/v1.0.5

參考

  • https://www.cnblogs.com/oyjg/p/13099998.html


審核編輯 :李倩


聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 接口
    +關注

    關注

    33

    文章

    8993

    瀏覽量

    153682
  • 服務器
    +關注

    關注

    13

    文章

    9786

    瀏覽量

    87895
  • 數(shù)據(jù)庫

    關注

    7

    文章

    3925

    瀏覽量

    66170

原文標題:效率加倍,高并發(fā)場景下的接口請求合并方案

文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    無硅油與含硅油導熱片: 精準匹配不同場景的散熱解決方案

    不同應用場景的互補解決方案。理解它們各自的特性和適用領域,能為電子設備散熱設計提供更精準的匹配方案。 一、材料特性對比:不同的化學基礎決定不同應用邊界 含硅油導熱片的優(yōu)勢領域含硅油導熱片以有機硅聚合物為
    發(fā)表于 07-14 17:04

    鴻蒙5開發(fā)寶藏案例分享---應用并發(fā)設計

    ?** 鴻蒙并發(fā)編程實戰(zhàn)指南:解鎖ArkTS多線程黑科技** 嘿,開發(fā)者朋友們! 今天給大家扒一扒鴻蒙官方文檔里藏著的并發(fā)編程寶藏—— 100+實戰(zhàn)場景解決方案 !從金融理財?shù)接螒蜷_發(fā)
    發(fā)表于 06-12 16:19

    Ingress網(wǎng)關并發(fā)請求的解決方案

    當 Ingress 網(wǎng)關面臨高并發(fā)請求(如 QPS 超過 10萬+)時,可能導致服務崩潰、響應延遲激增或資源耗盡。
    的頭像 發(fā)表于 05-14 11:52 ?246次閱讀

    RAKsmart服務器如何重塑AI并發(fā)算力格局

    在AI大模型參數(shù)量突破萬億級、實時推理需求激增的當下,傳統(tǒng)服務器架構的并發(fā)處理能力已逼近物理極限。RAKsmart通過“硬件重構+軟件定義”的雙引擎創(chuàng)新,推出新一代AI服務器解決方案。下面,AI部落小編為您解析RAKsmart服務器如何重塑AI
    的頭像 發(fā)表于 04-03 10:37 ?308次閱讀

    TurMass? 如何幫助解決 UWB 定位系統(tǒng)大規(guī)模終端標簽并發(fā)通信沖突問題?

    在大容量定位終端數(shù)據(jù)并發(fā)場景中,現(xiàn)有通信技術因信號沖突、系統(tǒng)容量受限等問題,難以滿足需求。TurMass? 通信技術通過多信道設計、時隙劃分、定位與通信一體化等創(chuàng)新方案,有效解決了
    的頭像 發(fā)表于 03-17 14:38 ?407次閱讀
    TurMass? 如何幫助解決 UWB 定位系統(tǒng)大規(guī)模終端標簽<b class='flag-5'>高</b><b class='flag-5'>并發(fā)</b>通信沖突問題?

    RCA接口轉換為其他接口方案

    RCA接口轉換為其他接口方案多種多樣,具體取決于需要轉換的目標接口類型以及應用場景。以下是一些常見的轉換
    的頭像 發(fā)表于 02-17 16:52 ?1114次閱讀

    華為支付-商戶基礎支付場景開發(fā)步驟

    :orderStr中sign字段簽名規(guī)則是將除sign外的參數(shù)都做排序拼接后再簽名,簽名值賦值給sign字段。 以下為開放API接口請求及orderStr構建示例代碼片段: import
    發(fā)表于 02-12 17:12

    華為支付-平臺類商戶合單支付場景準備

    PayMercAuth對象內的入?yún)⑴判蚱唇舆M行簽名。請參考排序拼接和簽名示例代碼。 2. 3.構建合單訂單信息參數(shù)orderStr并返回給客戶端。業(yè)務接口請求示例代碼可參考業(yè)務接口請求。 (二)拉起
    發(fā)表于 02-11 10:40

    華為支付-免密支付接入支付并簽約場景

    參考排序拼接和簽名示例代碼。 2. 3.構建訂單信息參數(shù)orderStr返回給客戶端,業(yè)務接口請求示例代碼可參考業(yè)務接口請求。 (二)拉起華為支付收銀臺(端側開發(fā)) 使用orderStr調用
    發(fā)表于 02-10 09:55

    低成本解決方案,RK3506的應用場景分析!

    RK3506 是瑞芯微推出的MPU產品,芯片制程為22nm,定位于輕量級、低成本解決方案。該MPU具有低功耗、外設接口豐富、實時性的特點,適合用多種工商業(yè)場景。本文將基于RK3506
    的頭像 發(fā)表于 12-11 15:26 ?1353次閱讀
    低成本解決<b class='flag-5'>方案</b>,RK3506的應用<b class='flag-5'>場景</b>分析!

    存儲、高效率、更靈活,拆解聯(lián)核科技“前揀后存”解決方案

    為了解決傳統(tǒng)倉庫低矮、空間小儲量小,庫位不足等行業(yè)痛點,聯(lián)核科技重磅推出四向穿梭車,向密集存儲場景的拓展結合無人叉車,打造存儲、高效率的創(chuàng)新四向車前揀后存解決方案
    的頭像 發(fā)表于 12-02 16:01 ?424次閱讀

    NVIDIA助力麗蟾科技打造AI訓練與推理加速解決方案

    麗蟾科技通過 Leaper 資源管理平臺集成 NVIDIA AI Enterprise,為企業(yè)和科研機構提供了一套高效、靈活的 AI 訓練與推理加速解決方案。無論是在復雜的 AI 開發(fā)任務中,還是在并發(fā)推理
    的頭像 發(fā)表于 10-27 10:03 ?810次閱讀
    NVIDIA助力麗蟾科技打造AI訓練與推理加速解決<b class='flag-5'>方案</b>

    測試聊并發(fā)-入門篇

    服務端接口的性能測試中,我們面臨的挑戰(zhàn)不僅僅是處理單個請求效率,更在于如何在多用戶同時訪問時保持系統(tǒng)的穩(wěn)定性和響應速度。并發(fā)編程和測試,作為性能測試的核心,對于評估系統(tǒng)在
    的頭像 發(fā)表于 10-15 15:23 ?443次閱讀
    測試聊<b class='flag-5'>并發(fā)</b>-入門篇

    并發(fā)物聯(lián)網(wǎng)云平臺是什么

    并發(fā)物聯(lián)網(wǎng)云平臺是一種能夠處理大量設備同時連接并進行數(shù)據(jù)交換的云計算平臺。這種平臺通常被設計用來應對來自數(shù)以萬計甚至數(shù)十億計的物聯(lián)網(wǎng)設備的并發(fā)請求,保證系統(tǒng)的穩(wěn)定性和響應速度。 首先
    的頭像 發(fā)表于 08-13 13:50 ?541次閱讀

    并發(fā)系統(tǒng)的藝術:如何在流量洪峰中游刃有余

    尤為重要。用戶對在線服務的需求和期望不斷提高,系統(tǒng)的并發(fā)處理能力成為衡量其性能和用戶體驗的關鍵指標之一。并發(fā)系統(tǒng)不僅僅是大型互聯(lián)網(wǎng)企業(yè)的專利,對于任何希望在市場中占據(jù)一席之地的公司來說,能夠處理大量
    的頭像 發(fā)表于 08-05 13:43 ?512次閱讀
    <b class='flag-5'>高</b><b class='flag-5'>并發(fā)</b>系統(tǒng)的藝術:如何在流量洪峰中游刃有余