鍍金池/ 問答/ 人工智能問答
做不到 回答

redis正常只是做數(shù)據(jù)庫檢索結(jié)果緩存吧
你難道想直接把數(shù)據(jù)庫數(shù)據(jù)全部緩存到redis，然后用sql查詢？。。。
這不是redis干的活啊

柚稚 回答

你的這種比較方式不太對(duì)，紅黑樹其實(shí)是2-3查找樹的一種比較優(yōu)雅的實(shí)現(xiàn)。
性能的量度不光光考慮時(shí)間復(fù)雜度，還有空間復(fù)雜度，以及工程難度。
紅黑樹出現(xiàn)的原因在于二叉查找樹的不平衡問題。紅黑樹能比較好的維持平衡。
當(dāng)然了，4階B樹也可以，但是其實(shí)他比2-3查找樹更復(fù)雜，但對(duì)于問題的解決卻沒有比較明顯的改善。

可以好好看看2-3查找樹的插入操作實(shí)現(xiàn)，對(duì)應(yīng)結(jié)合紅黑樹，會(huì)有意想不到的收獲

若相惜 回答

因?yàn)槟阒恍枰@示前100名，所以用一個(gè)最小堆就可以了。

Redi可以用sorted set加一個(gè)key保存第100名的積分，數(shù)據(jù)庫更新用戶積分后，先判斷是否比當(dāng)前第100名高，如果是就更新key和插入/更新到sorted set，然后定期把100名以后的移除掉，這樣就不會(huì)占太多內(nèi)存。

情皺 回答

根據(jù)你的需求，疑問一個(gè)問題，
無線大的數(shù)組為什么不直接用數(shù)據(jù)庫解決

礙你眼 回答

分布式系統(tǒng)架構(gòu)中，分布式事務(wù)問題是一個(gè)繞不過去的挑戰(zhàn)。而微服務(wù)架構(gòu)的流行，讓分布式事問題日益突出！
下面我們以電商購物支付流程中，在各大參與者系統(tǒng)中可能會(huì)遇到分布式事務(wù)問題的場景進(jìn)行詳細(xì)的分析！
圖片描述
如上圖所示，假設(shè)三大參與平臺(tái)（電商平臺(tái)、支付平臺(tái)、銀行）的系統(tǒng)都做了分布式系統(tǒng)架構(gòu)拆分，按上數(shù)中的流程步驟進(jìn)行分析：
1、電商平臺(tái)中創(chuàng)建訂單：預(yù)留庫存、預(yù)扣減積分、鎖定優(yōu)惠券，此時(shí)電商平臺(tái)內(nèi)各服務(wù)間會(huì)有分布式事務(wù)問題，因?yàn)榇藭r(shí)已經(jīng)要跨多個(gè)內(nèi)部服務(wù)修改數(shù)據(jù)；
2、支付平臺(tái)中創(chuàng)建支付訂單（選銀行卡支付）：查詢賬戶、查詢限制規(guī)則，符合條件的就創(chuàng)建支付訂單并跳轉(zhuǎn)銀行，此時(shí)不會(huì)有分布式事務(wù)問題，因?yàn)檫€不會(huì)跨服務(wù)改數(shù)據(jù)；
3、銀行平臺(tái)中創(chuàng)建交易訂單：查找賬戶、創(chuàng)建交易記錄、判斷賬戶余額并扣款、增加積分、通知支付平臺(tái)，此時(shí)也會(huì)有分布式事務(wù)問題（如果是服務(wù)化架構(gòu)的話）；
4、支付平臺(tái)收到銀行扣款結(jié)果：更改訂單狀態(tài)、給賬戶加款、給積分帳戶增加積分、生成會(huì)計(jì)分錄、通知電商平臺(tái)等，此時(shí)也會(huì)有分布式事務(wù)問題；
5、電商平臺(tái)收到支付平臺(tái)的支付結(jié)果：更改訂單狀態(tài)、扣減庫存、扣減積分、使用優(yōu)惠券、增加消費(fèi)積分等，系統(tǒng)內(nèi)部各服務(wù)間調(diào)用也會(huì)遇到分布式事問題；
圖片描述
如上圖，支付平臺(tái)收到銀行扣款結(jié)果后的內(nèi)部處理流程：
1、支付平臺(tái)的支付網(wǎng)關(guān)對(duì)銀行通知結(jié)果進(jìn)行校驗(yàn)，然后調(diào)用支付訂單服務(wù)執(zhí)行支付訂單處理；
2、支付訂單服務(wù)根據(jù)銀行扣款結(jié)果更改支付訂單狀態(tài)；
3、調(diào)用資金賬戶服務(wù)給電商平臺(tái)的商戶賬戶加款（實(shí)際過程中可能還會(huì)有各種的成本計(jì)費(fèi)；如果是余額支付，還可能是同時(shí)從用戶賬戶扣款，給商戶賬戶加款）；
4、調(diào)用積分服務(wù)給用戶積分賬戶增加積分；
5、調(diào)用會(huì)計(jì)服務(wù)向會(huì)計(jì)（財(cái)務(wù)）系統(tǒng)寫進(jìn)交易原始憑證生成會(huì)計(jì)分錄；
6、調(diào)用通知服務(wù)將支付處理結(jié)果通知電商平臺(tái)；
圖片描述
如上圖，把支付系統(tǒng)中的銀行扣款成功回調(diào)處理流程提取出來，對(duì)應(yīng)的分布式事務(wù)問題的代碼場景：
/ 支付訂單處理 /
@Transactional(rollbackFor = Exception.class)
public void completeOrder() {
orderDao.update(); // 訂單服務(wù)本地更新訂單狀態(tài)
accountService.update(); // 調(diào)用資金賬戶服務(wù)給資金帳戶加款
pointService.update(); // 調(diào)用積分服務(wù)給積分帳戶增加積分
accountingService.insert(); // 調(diào)用會(huì)計(jì)服務(wù)向會(huì)計(jì)系統(tǒng)寫入會(huì)計(jì)原始憑證
merchantNotifyService.notify(); // 調(diào)用商戶通知服務(wù)向商戶發(fā)送支付結(jié)果通知
}

本地事務(wù)控制還可行嗎？

以上分布式事務(wù)問題，需要多種分布式事務(wù)解決方案來進(jìn)行處理。

訂單處理：本地事務(wù)

資金賬戶加款、積分賬戶增加積分：TCC型事務(wù)（或兩階段提交型事務(wù)），實(shí)時(shí)性要求比較高，數(shù)據(jù)必須可靠。
圖片描述

會(huì)計(jì)記賬：異步確保型事務(wù)（基于可靠消息的最終一致性，可以異步，但數(shù)據(jù)絕對(duì)不能丟，而且一定要記賬成功）
圖片描述

商戶通知：最大努力通知型事務(wù)（按規(guī)律進(jìn)行通知，不保證數(shù)據(jù)一定能通知成功，但會(huì)提供可查詢操作接口進(jìn)行核對(duì)）
圖片描述

推薦閱讀：https://www.roncoo.com/course...

葬愛 回答

這種配置只處理了 OPTIONS 請(qǐng)求。OPTIONS 請(qǐng)求不轉(zhuǎn)給后端，直接返回 204，并允許跨域。

對(duì)于其它請(qǐng)求，需要在前面再加一段：

location / {
   add_header Access-Control-Allow-Origin *;
   add_header Access-Control-Allow-Headers X-Requested-With;
   add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
    
   if ($request_method = 'OPTIONS') {
     return 204;
   }
}
愚念 回答

cnn圖像的輸入就是rgb + 多個(gè)卷積核，cnn會(huì)自動(dòng)學(xué)習(xí)特征

吃藕丑 回答

……你key都叫token當(dāng)然會(huì)覆蓋|||
你可以把key改成token_然后加個(gè)用戶id嘛，這樣就每個(gè)用戶獨(dú)立緩存了。

$redis->set('token_'.$userinfo['userid'],$cc['token']);

fillNumberInOneArray 將數(shù)字 m 填入到 第 n 個(gè)小宮格中，為什么要隨機(jī)選一個(gè)位置放呢？后期快放滿的時(shí)候，沖突的概率越來越大，根本不收斂的呀。你都能 judgeElse 了，為什么不能在生成 random 坐標(biāo)之前就排除一下已經(jīng)放了數(shù)字的格子呢？這一步浪費(fèi)的效率不計(jì)其數(shù)，甚至導(dǎo)致了算法有極大可能無法停止。9個(gè)格子有一個(gè)空位，用random去撞這個(gè)空位置，那有 8/9 的概率撞不到，一直死循環(huán)。

已經(jīng)被占的格子提前排除，這是其一。其二，假設(shè)小9宮格都剩下3個(gè)格子，需要放 7 了對(duì)吧，隨機(jī)一下，得到一個(gè)空格子，檢查了一下橫豎，發(fā)現(xiàn)不能放，接下來你需要標(biāo)記這個(gè)格子不可用，否則下次再 random 還有 1/3 的概率打中這個(gè)不可用的格子，導(dǎo)致算法不收斂。犯過的錯(cuò)，為什么下次還要繼續(xù)犯？下次你就該排除掉它，在剩下的選項(xiàng)里挑，否則這次試錯(cuò)就沒有意義啦，那這就不是算法，完全就是在碰運(yùn)氣。

function calculateCoordinate(position,n) 也可以精簡一下，沒必要那么多 switch-case：

function calculateCoordinate(position, n) {
  // 先計(jì)算九宮格是幾排幾列的九宮格, 我們把數(shù)獨(dú)看成是 3*3 的9個(gè)9宮格
  var nx = n % 3;
  var ny = Math.floor(n / 3); 

  var px = position % 3;
  var py = Math.floor(position / 3);
  // 同樣的套路處理小9宮格內(nèi)的坐標(biāo)，
  
  // 轉(zhuǎn)換一下坐標(biāo)系
  var returnX = px + nx * 3; 
  var returnY = py + ny * 3;
  return [returnY, returnX];
}
夕顏 回答

是的.一個(gè)分片對(duì)應(yīng)一個(gè)map,一個(gè)map對(duì)應(yīng)一個(gè)MapTask,map的數(shù)量和分片的數(shù)量相等.
只有一個(gè)分片時(shí),其他節(jié)點(diǎn)不參與計(jì)算.
到hadoop2.0之后,默認(rèn)的塊大小是128M.
課可以修改塊的大小來增多map.

還吻 回答

python2 -m pip install ipykernel
python2 -m ipykernel install --user

python3 -m pip install ipykernel
python3 -m ipykernel install --user

.............
ubuntun可以的

我不懂 回答

如果代碼里明確這樣表明了，那就是不支持windows了，如果是windows 10的話可以考慮使用WSL,直接在應(yīng)用商店搜索Ubuntu就可以安裝

瘋子范 回答

由于request.url是只讀的屬性，所以不能直接更改。
但看了一下源碼，可以嘗試在下載器中間件中這樣寫：

def process_request(self, request, spider):
    request._set_url(request.url + '&t=%s' % self.gettime())
吢丕 回答

這個(gè)一般都是瀏覽器端的本地緩存，比如百度的搜索框的autocomplete 就是根據(jù)你曾經(jīng)搜索的歷史記錄來提示的。 歷史數(shù)據(jù)就是保存在了瀏覽器端的

巴扎嘿 回答

從產(chǎn)品那學(xué)到的：層次分析法https://baike.baidu.com/item/...

實(shí)際應(yīng)用就是：列表排序優(yōu)先級(jí)

伴謊 回答
  1. 因?yàn)閞edis它爹不喜歡c++喜歡c
  2. redis build很快, 用了內(nèi)置容器(就是你說的stl, 雖然其實(shí)這些不是stl, stl只是某牛人在hp寫的庫, 標(biāo)準(zhǔn)庫在這基礎(chǔ)上面增減了很多東西. )一堆模板自然慢了下來
  3. 可移植性(樓上說了)
  4. c++比c更難(靠譜的c++碼農(nóng)比c少), 沒必要冒這種風(fēng)險(xiǎn).

反對(duì)C的結(jié)構(gòu)體中封裝函數(shù)指針就能很優(yōu)雅的實(shí)現(xiàn)面向?qū)ο蟆?/code>這種人肉虛表的做法, 我不認(rèn)為有正常人(除了c廚)會(huì)覺得這種方法優(yōu)雅. 雖然linux的內(nèi)核文件系統(tǒng)就是這么做的, Linus不就是c廚嗎, 不過既然redis它爹是c廚, 這樣做也是正常的.(扯遠(yuǎn)了, 逃

刮刮樂 回答

不好意思不是解答，因?yàn)槲乙灿龅竭@種情況

不知道樓主解決了沒

Redis的鍵key只能為字符串。

可以參考一下這份文檔Redis。

首頁 上一頁 5 6 7 8 9 10 11 12 13 下一頁 尾頁