&

分類:

推薦最新等你回答

sign 簽名在客戶端怎么保證安全（ios，android，web）

墨小白回答

api中，你不應(yīng)該暴露key和加密方法到客戶端，你應(yīng)該采用https + 用戶token的方式訪問(wèn)你后端接口

postgresql的int4類型為什么長(zhǎng)度可以達(dá)到10位

紓惘回答

用NaviCat連PG？還有這種操作？

言歸正傳。看起來(lái)像是GUI工具上的一些顯示內(nèi)容讓題主產(chǎn)生了誤解，簡(jiǎn)單解釋一下吧:

PG中int4類型對(duì)應(yīng)的是SQL標(biāo)準(zhǔn)中的INTEGER類型，而且PG實(shí)現(xiàn)的是源生的integer類型，是定長(zhǎng)4字節(jié)(=32位bit)。其對(duì)應(yīng)的十進(jìn)制取值范圍是 -?21474836478 ~ ?2147483647?

因此，題主截圖所示的操作錯(cuò)誤如下：

第一第二張圖，題主在嘗試對(duì)一個(gè)INTGEGER類型的列修改其長(zhǎng)度：上文已述，INTEGER是定長(zhǎng)的32位二進(jìn)制，因此這樣的操作必然是徒勞的。
不過(guò)GUI也有值得吐槽的地方，其“長(zhǎng)度”概念似乎有二義性
第三第四張圖，題主分別嘗試向INTEGER類型的字段插入一個(gè) INTEGER范圍內(nèi)的值和一個(gè)INTEGER范圍外的值。因此第二次嘗試是失敗的(第二次的12345678901超過(guò)了INTEGER最大值2147483647?)
另外，從題主的描述來(lái)看，題主似乎對(duì)于二進(jìn)制的位數(shù)和十進(jìn)制的位數(shù)沒(méi)分清。題主一直在強(qiáng)調(diào)要插入一個(gè)11位的十進(jìn)制數(shù)，可能題主看GUI里顯示INTEGER類型有"32位"就誤以為應(yīng)該能夠插入。但是實(shí)際上這里的32位是二進(jìn)制的位數(shù)(這也是我上文所述的GUI的槽點(diǎn): 等它顯示NUMERIC類型時(shí)，長(zhǎng)度恐怕就又要變成了十進(jìn)制的長(zhǎng)度的意思了）

最后，如果題主要插入11位的十進(jìn)制數(shù)，可以考慮將列的類型改為BIGINT(int8)類型或直接用NUMERIC類型

storm實(shí)時(shí)流處理中如何利用redis去除重復(fù)數(shù)據(jù)？

我不懂回答

直接為每個(gè)用戶設(shè)置一個(gè)事件鎖不就成了，發(fā)了直接設(shè)置當(dāng)前用戶的事件鎖并且失效時(shí)間30天，每次發(fā)送check一下鎖存不存在。

Vue點(diǎn)擊一個(gè)高亮，與點(diǎn)擊多個(gè)高亮

離殤回答

拼桌的時(shí)候判斷 selected includes 這一桌就可

為什么 windows下安裝的redis-cli 客戶端無(wú)法使用上下鍵切換命令？ tab鍵也無(wú)法使用？

過(guò)客回答

如果只是問(wèn)技術(shù)上的「為什么」的話……

因?yàn)檫@個(gè)版本的 Redis 客戶端，可能沒(méi)有編譯入 Readline 或者類似的命令行功能支持庫(kù)。我看到 antirez 在 GitHub 上有個(gè) antirez/linenoise repo，介紹說(shuō)是 "...readline replacement used in Redis..."，下面的 "Tested with" 段里面提到了一堆操作系統(tǒng)，但就是沒(méi)提到 Windows。如果你下載的 redis 用的就是這個(gè) linenoise 庫(kù)的話，那估計(jì)在 Windows 上確實(shí)沒(méi)做這個(gè)支持。

如果把控制臺(tái)的鍵盤/字符 I/O 看作 stdin 和 stdout 這幾個(gè)簡(jiǎn)單的流，那方向鍵是沒(méi)有一席之地的。就像用 C 語(yǔ)言寫的最簡(jiǎn)單的 hello world，不鏈接上奇怪的庫(kù)，運(yùn)行的時(shí)候大概不支持方向鍵的操作。

向上箭頭，不是向上。它有它對(duì)應(yīng)的控制字符的碼。向下箭頭也不是向下。至于 tab，也未必是 tab，也有對(duì)應(yīng)的控制字符。所以最基本的情況下，這幾個(gè)按鍵按下之后導(dǎo)致亂碼才正常。

但是你們又不高興，那怎么辦？

那命令行程序要支持方向鍵操作，比如調(diào)出上一條命令 (各種 shell 和 REPL 的必備基礎(chǔ)功能)，所以有了 Readline 這些庫(kù)來(lái)處理和終端之間最基本的這些交互。說(shuō)白了就是，如果收到了什么特殊控制字符，就做點(diǎn)什么事情。那這種「臟」的代碼自然是和具體的終端環(huán)境耦合的了。不支持某種終端，那就是不支持?；蛘邲](méi)鏈接進(jìn)去，那就是不支持。

你遇到的情況很可能就是這樣，用的 Redis 程序在 Windows 上沒(méi)有鏈接到合適的類似 Readline 的庫(kù)。Windows 10 的話，也許可以試試用 WSL 跑 Linux 上的二進(jìn)制，而 Linux 上面想要獲得鏈接庫(kù)齊全的二進(jìn)制應(yīng)該稍微容易點(diǎn)，也不需要自己編譯。

啟動(dòng)tonsorboard出現(xiàn)問(wèn)題

嫑吢丕回答

path/to/log 是絕對(duì)路徑嗎

這段php代碼怎么個(gè)執(zhí)行邏輯，沒(méi)看懂請(qǐng)教一下？

櫻花霓回答

引用傳值

$items 循環(huán)改變的是自身

比如第一次循環(huán)引用傳值變成了 $arr, 第二次循環(huán)也就是循環(huán)的$arr,就等于當(dāng)前循環(huán)的數(shù)組沒(méi)每循環(huán)一次，初始數(shù)據(jù)都是上一次循環(huán)的結(jié)果。

第一次變成這樣以此類推

$arr=[
  [
      "id"=>1,
      "pid"=>0,
      "name"=>'北京市',
      "son"=>[
          [
              "id"=>3,
              "pid"=>1,
              "name"=>"海淀區(qū)"
          ]
      ]
  ],
  [
      "id"=>1,
      "pid"=>0,
      "name"=>'黑龍江省',
  ]
];

h5開發(fā)中，遇到oppo手機(jī)，總是清空session storage里面的數(shù)據(jù)，有沒(méi)有什么辦法解決

歆久回答

其實(shí)無(wú)痕模式下 localStorage sessionStorage都無(wú)法使用的。我之前的解決無(wú)痕模式的辦法是：優(yōu)先設(shè)置／獲取本地存儲(chǔ)數(shù)據(jù)，如果沒(méi)有找cookie。如果數(shù)據(jù)過(guò)大可以考慮掛在window中??！

LS () {
  return {
    setItem (key, val) {
      try {
        localStorage.setItem(key, val)
      } catch (e) {
        cookie.set(key, val)
      }
    },
    getItem (key) {
      return localStorage.getItem(key) || cookie.get(key)
    },
    removeItem (key) {
      localStorage.removeItem(key)
      cookie.remove(key)
    }
  }
}

renren-fast-vue基于vue、element-ui構(gòu)建開發(fā)，實(shí)現(xiàn)renren-fast后臺(tái)管理前端功能，提供一套更優(yōu)的前端解決方案。

請(qǐng)問(wèn) Python 有沒(méi)有實(shí)現(xiàn)遠(yuǎn)程腳本分發(fā)結(jié)果返回及文件傳輸功能的分布式開源項(xiàng)目

墨小羽回答

ansible 或 saltstack?

白色布料紋理圖片和深色圖片合成，如何使布料顏色改變并保留紋理？

夕顏回答

像這樣？

突然覺(jué)得緩存如果單獨(dú)搞一套服務(wù)出來(lái)，那不是每次寫代碼都要業(yè)務(wù)的寫一遍，緩存的也寫一遍啊？

墨小白回答

@平常我看有的架構(gòu)是直接通過(guò)canel訂閱binlog，消費(fèi) 如果訂閱的商品數(shù)據(jù)有變動(dòng)直接可以消費(fèi)到，在寫入緩存中去

關(guān)于消息中間件應(yīng)用場(chǎng)景的問(wèn)題。

骨殘心回答

不適合。

消息量并不大而且實(shí)時(shí)性要求并不太高
主要是你要處理下發(fā)結(jié)果來(lái)確定后續(xù)操作，而消息隊(duì)列處理消息結(jié)果是很復(fù)雜的事

不要為了消息隊(duì)列而消息隊(duì)列

JavaScript創(chuàng)建散列表時(shí),散列函數(shù)有什么用?

陌如玉回答

就算加了幾個(gè)字段,但是首字母和index對(duì)應(yīng)關(guān)系還是沒(méi)變! 還是不需要散列函數(shù)呀?

邏輯上是樹型結(jié)構(gòu)的表緩存方案

魚梓回答

不太了解你的具體場(chǎng)景, 另外假設(shè)你是 B/S

我之前的做法是, 直接生成一個(gè)js
服務(wù)端只驗(yàn)證數(shù)據(jù)就可以了

我能想到的方案

保存相鄰兩級(jí)的 id的單向集合關(guān)系

比如

湖北省.id : [武漢市.id, 襄樊市.id, ...]
.....
武漢市.id : [洪山區(qū).id, 東湖高新區(qū).id, ...]

//省市區(qū)三個(gè)級(jí)別的話

//一共就是 34(省級(jí)行政區(qū)) + 294(地級(jí)市) 條記錄

然后驗(yàn)證一個(gè)省市區(qū)串是否正確只需要redis兩次請(qǐng)求

ps: 前提條件是你傳遞上來(lái)的是 省-市-區(qū) 而不是僅僅一個(gè) 區(qū)

Mysql主從復(fù)制和集群有何區(qū)別？分別適用什么場(chǎng)景？

青瓷回答

mysql主從的作用：
1、數(shù)據(jù)熱備：作為后備數(shù)據(jù)庫(kù)，主數(shù)據(jù)庫(kù)服務(wù)器故障后，可切換到從數(shù)據(jù)庫(kù)繼續(xù)工作，避免數(shù)據(jù)丟失。
2、架構(gòu)的擴(kuò)展：業(yè)務(wù)量越來(lái)越大，I/O訪問(wèn)頻率過(guò)高，單機(jī)無(wú)法滿足，此時(shí)做多庫(kù)的存儲(chǔ)，降低磁盤I/O訪問(wèn)的頻率，提高單個(gè)機(jī)器的I/O性能。
3、讀寫分離使數(shù)據(jù)庫(kù)能支撐更大的并發(fā)。在報(bào)表中尤其重要。由于部分報(bào)表sql語(yǔ)句非常的慢，導(dǎo)致鎖表，影響前臺(tái)服務(wù)。如果前臺(tái)使用master，報(bào)表使用slave，那么報(bào)表sql將不會(huì)造成前臺(tái)鎖，保證了前臺(tái)速度。
或者如果網(wǎng)站訪問(wèn)量和并發(fā)量太大了，少量的數(shù)據(jù)庫(kù)服務(wù)器是處理不過(guò)來(lái)的，會(huì)造成網(wǎng)站訪問(wèn)慢。數(shù)據(jù)寫入會(huì)造成數(shù)據(jù)表或記錄被鎖住，鎖住的意思就是其他訪問(wèn)線程暫時(shí)不能讀寫要等寫入完成才能繼續(xù)，這樣會(huì)影響其他用戶讀取速度。采用主從復(fù)制可以讓一些服務(wù)器專門讀，一些專門寫可以解決這個(gè)問(wèn)題。

而集群則是直接增加可承載讀寫量的辦法，效果比主從好。

如何在可以控制掛單數(shù)量和總金額的前提下，提高階梯掛單全部成交均價(jià)的性價(jià)比

不討囍回答

貌似可以看出一個(gè)數(shù)學(xué)的優(yōu)化問(wèn)題?；谀愕?strong>離目標(biāo)價(jià)格（5000元）越遠(yuǎn)時(shí)，掛單資金越少，越近時(shí)越多的思路，可以進(jìn)行建模：

起始商品價(jià)格為$begin$，最終價(jià)格為$end$，間隔區(qū)間為$delta$，則總共掛單次數(shù)$n$為:

$$ n = \frac{(begin-end)}{delta} + 1 $$

當(dāng)$begin = 6000$, $end = 5000$, $delta = 100$時(shí)代入得$n=11$, 總共掛單11次

起始掛單資金$basic$, 然后逐單增加$extra$。但保證$costlimit$范圍內(nèi)，

則全部花費(fèi)$cost$為：
$$ cost = basic + extra * 0 + basic + extra*1 + ... + basic + extra * (n-1) = (n-1) basic + \frac{ extra * n(n-1)}{2}$$

假設(shè)你的花費(fèi)上限為$costlimit$，那么應(yīng)該有
$$ (n-1) basic + \frac{ extra * n(n-1)}{2} \leq costlimit $$

第n次買的商品數(shù)量為第n次的花費(fèi)處以當(dāng)前商品的價(jià)格，也就是
$$ \frac{(basic + extra * (n-1))}{(begin - delta* (n-1))}$$

總共有商品數(shù)量為
$$ \sum_{i=0}^{n-1} \frac{(basic + extra * i)}{(begin - delta* i)} $$

總共商品均價(jià)為
$$ avg\_price = \frac{cost}{amount} $$

也即是:

$$ avg\_price = \frac{(n-1) basic + \frac{ extra * n(n-1)}{2}}{\sum_{i=0}^{n-1} \frac{(basic + extra * i)}{(begin - delta* i)}} $$

你的目標(biāo)就是在
$$ (n-1) basic + \frac{ extra * n(n-1)}{2} \leq costlimit $$

的前提下使得$avg\_price$和最終的價(jià)格$end$差距盡可能小，可以用兩個(gè)價(jià)格差作為標(biāo)準(zhǔn)，也可以用$\frac{end}{avg\_price}$ 比例的方式（也就是性價(jià)比）衡量。這里用性價(jià)比：

$$ f = argmax(\frac{ end}{ \frac{(n-1) basic + \frac{ extra * n(n-1)}{2}}{\sum_{i=0}^{n-1} \frac{(basic + extra * i)}{(begin - delta* i)}} } ) \leq 1 $$

當(dāng)你的最終成交均價(jià)就是商品的價(jià)格時(shí)性價(jià)比為1，否則小于1.

你通過(guò)調(diào)整一下你的起始價(jià)格$basic$和遞增價(jià)格$extra$，應(yīng)該能找到最佳的方案。

求分布式業(yè)務(wù)解決方案？

凹凸曼回答

訂單管理系統(tǒng)關(guān)聯(lián)的業(yè)務(wù)系統(tǒng)個(gè)數(shù)是未知的

也就是說(shuō)每個(gè)訂單需要記錄它關(guān)聯(lián)的業(yè)務(wù)系統(tǒng)以及對(duì)應(yīng)的狀態(tài)，關(guān)聯(lián)的系統(tǒng)每完成一個(gè)就通知一次訂單，訂單再檢查是否全部關(guān)聯(lián)系統(tǒng)完成。

跨域后臺(tái)設(shè)置了Access-Control-Allow-Origin:*，能訪問(wèn)到，但是瀏覽器會(huì)報(bào)錯(cuò)

做不到回答

exprss里是這么配置的，關(guān)鍵在于允許options請(qǐng)求以及options請(qǐng)求自動(dòng)返回200
看你說(shuō)的返回兩次可能是因?yàn)閜ost請(qǐng)求沒(méi)達(dá)到簡(jiǎn)單請(qǐng)求的要求，會(huì)發(fā)送options

// cors跨域配置
app.all('*', function (req, res, next) {
    res.header('Access-Control-Allow-Origin', '*');
    res.header('Access-Control-Allow-Headers', 'Content-Type, Content-Length, Authorization, Accept, X-Requested-With, Current-Page');
    res.header('Access-Control-Allow-Methods', 'PUT, POST, GET, DELETE, OPTIONS');

    if (req.method == 'OPTIONS') {
        res.sendStatus(200);
    } else {
        next();
    }
});

scrapy cookie問(wèn)題

愛(ài)是癌回答

session

如何使用 R語(yǔ)言模擬時(shí)間序列模型的數(shù)據(jù)。

命于你回答

建議你看下 Rstan 關(guān)于 Garch 的例子，可以直接復(fù)用

https://github.com/stan-dev/e...