18video性欧美19sex,欧美高清videosddfsexhd,性少妇videosexfreexxx片中国,激情五月激情综合五月看花,亚洲人成网77777色在线播放

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

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

3天內(nèi)不再提示

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

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

掃碼添加小助手

加入工程師交流群


前言

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

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

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

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

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

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

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

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

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

技術(shù)手段

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

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

  • 項目地址: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;

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


/**
*請求類,code為查詢的共同特征,例如查詢商品,通過不同id的來區(qū)分
*CompletableFuture將處理結(jié)果返回
*/
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是一個阻塞的隊列,內(nèi)部采用鏈表的結(jié)果,通過兩個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ā)的情況下生產(chǎn)者和消費者可以并行地操作隊列中的數(shù)據(jù),以此來提高整個隊列的并發(fā)性能。
*/
privatefinalQueuequeue=newLinkedBlockingQueue();

@PostConstruct
publicvoidinit(){
//定時任務(wù)線程池,創(chuàng)建一個支持定時、周期性或延時任務(wù)的限定線程數(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ù)量,超過最大任務(wù)數(shù),等下次執(zhí)行
if(i//拿到我們需要去數(shù)據(jù)庫查詢的特征,保存為集合
ListuserReqs=newArrayList<>();
for(Requestrequest:list){
userReqs.add(request);
}
//將參數(shù)傳入service處理,這里是本地服務(wù),也可以把userService看成RPC之類的遠程調(diào)用
Mapresponse=userService.queryUserByIdBatch(userReqs);
//將處理結(jié)果返回各自的請求
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;
}
}

控制層調(diào)用

/***
*請求合并
**/
@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ù)量,超過最大任務(wù)數(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;

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


/**
*請求類,code為查詢的共同特征,例如查詢商品,通過不同id的來區(qū)分
*CompletableFuture將處理結(jié)果返回
*/
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是一個阻塞的隊列,內(nèi)部采用鏈表的結(jié)果,通過兩個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ā)的情況下生產(chǎn)者和消費者可以并行地操作隊列中的數(shù)據(jù),以此來提高整個隊列的并發(fā)性能。
*/
privatefinalQueuequeue=newLinkedBlockingQueue();

@PostConstruct
publicvoidinit(){
//定時任務(wù)線程池,創(chuàng)建一個支持定時、周期性或延時任務(wù)的限定線程數(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ù)量,超過最大任務(wù)數(shù),等下次執(zhí)行
if(i//拿到我們需要去數(shù)據(jù)庫查詢的特征,保存為集合
ListuserReqs=newArrayList<>();
for(Requestrequest:list){
userReqs.add(request);
}
//將參數(shù)傳入service處理,這里是本地服務(wù),也可以把userService看成RPC之類的遠程調(diào)用
Mapresponse=userService.queryUserByIdBatchQueue(userReqs);
for(RequestuserReq:userReqs){
//這里再把結(jié)果放到隊列里
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é)

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

代碼地址

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

參考

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


審核編輯 :李倩


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

    關(guān)注

    33

    文章

    9306

    瀏覽量

    155685
  • 服務(wù)器
    +關(guān)注

    關(guān)注

    13

    文章

    10013

    瀏覽量

    90365
  • 數(shù)據(jù)庫
    +關(guān)注

    關(guān)注

    7

    文章

    3983

    瀏覽量

    67536

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

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

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

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    訂單拆單合并處理接口設(shè)計與實現(xiàn)

    處理接口能顯著提升系統(tǒng)性能,降低運營開銷。本文將逐步介紹該接口的核心設(shè)計、實現(xiàn)細節(jié)和使用場景,幫助開發(fā)者快速上手。 1. 接口核心功能 該接口
    的頭像 發(fā)表于 10-16 14:47 ?151次閱讀
    訂單拆單<b class='flag-5'>合并</b>處理<b class='flag-5'>接口</b>設(shè)計與實現(xiàn)

    如何理解工業(yè)數(shù)據(jù)中臺的并發(fā)能力

    工業(yè)數(shù)據(jù)中臺的并發(fā)能力是指其在同一時間段內(nèi)高效處理大量設(shè)備數(shù)據(jù)讀寫、分析請求的能力,這是保障工業(yè)數(shù)據(jù)實時采集、傳輸、處理與決策響應(yīng)穩(wěn)定性和高效性的關(guān)鍵。以下從核心價值、技術(shù)實現(xiàn)、應(yīng)用場景
    的頭像 發(fā)表于 10-15 11:49 ?170次閱讀

    CS、IU系列單聲道音頻功放 —— 覆蓋從低功耗到功率的全場景解決方案

    CS、IU系列單聲道音頻功放 —— 覆蓋從低功耗到功率的全場景解決方案 在音頻應(yīng)用中,不同場景對功放的要求差異巨大:從便攜式設(shè)備的低功耗,到家庭影院、專業(yè)音響的
    發(fā)表于 09-16 09:07

    有沒有針對特定行業(yè)或場景的裝置數(shù)據(jù)驗證效率提升方案?

    )、工業(yè)制造(汽車 / 化工)、數(shù)據(jù)中心、醫(yī)療行業(yè)四大典型場景,提供定制化的驗證效率提升方案,兼顧 “效率” 與 “行業(yè)合規(guī)性”。 一、新能源場站(光伏 / 風電):解決 “地理分散、
    的頭像 發(fā)表于 09-04 17:47 ?360次閱讀
    有沒有針對特定行業(yè)或<b class='flag-5'>場景</b>的裝置數(shù)據(jù)驗證<b class='flag-5'>效率</b>提升<b class='flag-5'>方案</b>?

    不同場景的文件共享方案-SMB/WebDAV/FTP/ZeroNews

    當下,文件共享已成為企業(yè)協(xié)作和日常工作中不可或缺的一環(huán)。不同的場景對文件共享的需求各異,文件共享方案的選擇直接影響企業(yè)效率與數(shù)據(jù)安全。 本文從 技術(shù)特性 、 適用場景 、 安全機制 等
    的頭像 發(fā)表于 08-28 12:04 ?477次閱讀
    不同<b class='flag-5'>場景</b><b class='flag-5'>下</b>的文件共享<b class='flag-5'>方案</b>-SMB/WebDAV/FTP/ZeroNews

    Nginx并發(fā)優(yōu)化方案

    作為一名在生產(chǎn)環(huán)境中摸爬滾打多年的運維工程師,我見過太多因為Nginx配置不當導(dǎo)致的性能瓶頸。今天分享一套完整的Nginx并發(fā)優(yōu)化方案,幫助你的系統(tǒng)從10萬QPS突破到百萬級別。
    的頭像 發(fā)表于 08-13 15:51 ?527次閱讀

    NVMe高速傳輸之擺脫XDMA設(shè)計19:PCIe請求模塊設(shè)計(

    組裝寫請求的TLP報頭,并將報頭通過axis_rq接口發(fā)送。當axis_rq接口握手時跳轉(zhuǎn)到WR_DATA狀態(tài)。WR_DATA:請求寫TLP數(shù)據(jù)發(fā)送狀態(tài)。該狀態(tài)
    發(fā)表于 08-11 15:24

    NVMe高速傳輸之擺脫XDMA設(shè)計13:PCIe請求模塊設(shè)計(

    避免異常情況的出現(xiàn)。 WR_HEAD:請求寫TLP頭發(fā)送狀態(tài)。該狀態(tài)根據(jù)請求類型、請求地址組裝寫請求的TLP報頭,并將報頭通過axis
    發(fā)表于 08-04 16:39

    NVMe高速傳輸之擺脫XDMA設(shè)計13:PCIe請求模塊設(shè)計(

    在接收到請求總線接口請求事務(wù)后,當請求類型的值為0時,表示通過PCIE硬核的配置管理接口發(fā)送請求
    的頭像 發(fā)表于 08-04 16:35 ?302次閱讀
    NVMe高速傳輸之擺脫XDMA設(shè)計13:PCIe<b class='flag-5'>請求</b>模塊設(shè)計(<b class='flag-5'>下</b>)

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

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

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

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

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

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

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

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

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

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

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

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