1樓：謝慕安
你把應用層協議和傳輸層協議搞混了。
如果是TCP層面的重傳不會導致這個問題，但應用層訊息丟了會導致TCP鏈路斷開，你無法再發後續的請求。
2樓：楊肉
如果重試的時候和之前傳送的是完全一樣的指令，Server自然是無法區分你是重試了還是一次新的INCR，任何RPC確實都是如此。HTTP協議也區分了POST和PUT。除了其他人說的非冪等操作不要瞎重試之外，還有個辦法就是設計RPC協議的時候額外帶一些資訊以確保「重試」和「再請求一次」是不一樣的。
最簡單的，比如每個client維護乙個計數器表示我是這個client的第幾條指令，重試時不增加計數，這樣server如果連續收到了非預期的計數，那就直接忽略掉就好。
3樓：郁白
當然，事務的執行一定要處理unknow的情況，非冪等的重試是不行的，最簡單的處理就是直接拋給使用者
很巧，我這個回答就遇到了知乎的問題，當我點傳送的時候，知乎沒有反應，也沒有退出編輯頁，但是再次點的時候，知乎提示不能重複回答，我手動退出後重新整理出了自己的答案
4樓：
100%會.比如Redis返回資訊丟包, client認為超時.這個時候時候記憶體中數字已經add了.
原因很簡單,redis 單執行緒可以保證自身操作原子遞增(incr命令),但是對應應用來說乙個完整的transaction應該是從傳送資料開始到收到成功響應結束,而不僅僅是incr中間一段.
所以你需要使用lua指令碼實現CAS. 這並不複雜
5樓：
不會出現這種情況。
如果這個計數相當重要，那麼read time out時就不能重試（而且redis 使用正常的情況下read timeout 的機率極低）。
如果這個計數沒這麼重要，那自然不用說，出現一點誤差沒大關係。
redis自增出現read timeout一般是內網不行，redis本身出問題的概率極小。內網不行了啥都別說了，應用依賴的其他服務都訪問不到了，redis的問題在這麼大的系統癱瘓中只是九牛一毛了。
隧道兩頭往中間開挖怎麼能保證一定能對上不會偏
日蓋樓專業戶 因為有測量技術。具體的說地球處於三維空間，如果建立乙個立體幾何座標系，那麼地球上的每乙個點都可以通過三個座標來具體定位。實際上這個座標系是有的。所謂的經緯度和海拔就是座標。為了方便，工程上使用的是座標系，中國就是以位於陝西涇陽的大地原點為平面 000,以黃海多年平均海平面位置為高度上的...
EXO 一定能挺下去的對吧！？
我是被唯八排除團籍那位的粉 說實話我從12年看這個團走過來 經歷了三次風波 我還是希望團能挺下來 實話實說團太難了 以9個人的樣子奔赴十年 別跟我槓，我會罵人 可能不續約是最好的解決方式 但是我希望不是唯一解決方式 EXO L雨 從沒懷疑EXO之間的感情，只懷疑某些粉絲對EXO的感情。我不會脫粉，怎...
參加職問的培訓一定能拿到滿意的offer嗎？
客觀冷靜得看，如果專業以及院校背景和之前經歷能達到對應企業要求沒問題只是少了臨門一腳那可以找老師輔導一下，不然也是瞎折騰，浪費錢浪費時間 可能嗎？很多紅圈律所都已經表示過跟這樣的機構沒有任何的合作了，但是他們還是把這些律所全部都寫到合同上面了，對此元芳你怎看？職問還有什麼好說的 睡醒的百合 客觀來講...