主頁 > 資料庫 > UniswapV2周邊合約學習(五)-- ExampleFlashSwap.sol

UniswapV2周邊合約學習(五)-- ExampleFlashSwap.sol

2020-10-26 14:25:29 資料庫

記得朋友圈看到過一句話,如果Defi是以太坊的皇冠,那么Uniswap就是這頂皇冠中的明珠,Uniswap目前已經是V2版本,相對V1,它的功能更加全面優化,然而其合約原始碼卻并不復雜,本文為個人學習UniswapV2原始碼的系列記錄文章,

一、ExampleFlashSwap合約介紹

該合約為利用UniswapV2交易對中的FlashSwap的先借后還特性,在買賣資產的同時和UnisapV1交易對進行交易,利用價格差進行套利,

二、ExampleFlashSwap合約原始碼

pragma solidity =0.6.6;

import '@uniswap/v2-core/contracts/interfaces/IUniswapV2Callee.sol';

import '../libraries/UniswapV2Library.sol';
import '../interfaces/V1/IUniswapV1Factory.sol';
import '../interfaces/V1/IUniswapV1Exchange.sol';
import '../interfaces/IUniswapV2Router01.sol';
import '../interfaces/IERC20.sol';
import '../interfaces/IWETH.sol';

contract ExampleFlashSwap is IUniswapV2Callee {
    IUniswapV1Factory immutable factoryV1;
    address immutable factory;
    IWETH immutable WETH;

    constructor(address _factory, address _factoryV1, address router) public {
        factoryV1 = IUniswapV1Factory(_factoryV1);
        factory = _factory;
        WETH = IWETH(IUniswapV2Router01(router).WETH());
    }

    // needs to accept ETH from any V1 exchange and WETH. ideally this could be enforced, as in the router,
    // but it's not possible because it requires a call to the v1 factory, which takes too much gas
    receive() external payable {}

    // gets tokens/WETH via a V2 flash swap, swaps for the ETH/tokens on V1, repays V2, and keeps the rest!
    function uniswapV2Call(address sender, uint amount0, uint amount1, bytes calldata data) external override {
        address[] memory path = new address[](2);
        uint amountToken;
        uint amountETH;
        { // scope for token{0,1}, avoids stack too deep errors
        address token0 = IUniswapV2Pair(msg.sender).token0();
        address token1 = IUniswapV2Pair(msg.sender).token1();
        assert(msg.sender == UniswapV2Library.pairFor(factory, token0, token1)); // ensure that msg.sender is actually a V2 pair
        assert(amount0 == 0 || amount1 == 0); // this strategy is unidirectional
        path[0] = amount0 == 0 ? token0 : token1;
        path[1] = amount0 == 0 ? token1 : token0;
        amountToken = token0 == address(WETH) ? amount1 : amount0;
        amountETH = token0 == address(WETH) ? amount0 : amount1;
        }

        assert(path[0] == address(WETH) || path[1] == address(WETH)); // this strategy only works with a V2 WETH pair
        IERC20 token = IERC20(path[0] == address(WETH) ? path[1] : path[0]);
        IUniswapV1Exchange exchangeV1 = IUniswapV1Exchange(factoryV1.getExchange(address(token))); // get V1 exchange

        if (amountToken > 0) {
            (uint minETH) = abi.decode(data, (uint)); // slippage parameter for V1, passed in by caller
            token.approve(address(exchangeV1), amountToken);
            uint amountReceived = exchangeV1.tokenToEthSwapInput(amountToken, minETH, uint(-1));
            uint amountRequired = UniswapV2Library.getAmountsIn(factory, amountToken, path)[0];
            assert(amountReceived > amountRequired); // fail if we didn't get enough ETH back to repay our flash loan
            WETH.deposit{value: amountRequired}();
            assert(WETH.transfer(msg.sender, amountRequired)); // return WETH to V2 pair
            (bool success,) = sender.call{value: amountReceived - amountRequired}(new bytes(0)); // keep the rest! (ETH)
            assert(success);
        } else {
            (uint minTokens) = abi.decode(data, (uint)); // slippage parameter for V1, passed in by caller
            WETH.withdraw(amountETH);
            uint amountReceived = exchangeV1.ethToTokenSwapInput{value: amountETH}(minTokens, uint(-1));
            uint amountRequired = UniswapV2Library.getAmountsIn(factory, amountETH, path)[0];
            assert(amountReceived > amountRequired); // fail if we didn't get enough tokens back to repay our flash loan
            assert(token.transfer(msg.sender, amountRequired)); // return tokens to V2 pair
            assert(token.transfer(sender, amountReceived - amountRequired)); // keep the rest! (tokens)
        }
    }
}

三、原始碼其它部分學習

  • 第一行,照例是指定Solidity版本

  • 第二行,匯入IUniswapV2Callee介面,該介面定義了一個接收到代幣后的回呼函式,在Uniswapv2核心合約中的交易對合約的swap函式有這么一行代碼:

    if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data);,這正是呼叫了該函式,這行代碼在用戶得到買入的資產后立即呼叫了,且發生在用戶賣出資產之前,用戶可以在這個空隙利用uniswapV2Call這個回呼函式做自己想做的任意操作,比如說套利等,因此,此回呼函式再加上UniswapV2交易對的先買進再賣出機制是實作套利的核心,

  • 接下來六個import函式分別匯入UniswapV1版本的factory合約介面和交易對介面,V2版的工具庫及Router介面,標準ERC20代幣介面和WETH介面,因為V1版本的交易對為ETH/ERC20交易對,所以V2版本的交易對相應為WETH/ERC20交易對,所以需要用到WETH及ERC20介面,

  • contract ExampleFlashSwap is IUniswapV2Callee {這一行為合約定義,它必須實作IUniswapV2Callee,也就是必須實作uniswapV2Call這個函式,不然無法進行回呼會報錯重置交易,

  • IUniswapV1Factory immutable factoryV1;
    address immutable factory;
    IWETH immutable WETH;
    

    接下來是三個狀態變數,分別為V1版本的factory實體,V2版本的factory地址及WETH的實體,為什么這里V2版本的factory為地址型別而不為實體(合約型別)呢?因為下面的IUniswapV2Callee函式會利用該地址進行大量的計算(見工具庫),所以這里使用地址型別更方便一些,

  • 接下來是constructor構造器,利用輸入引數對上面三個狀態變數初始化,注意,WETH實體的初始化不是直接傳入的WETH合約地址,而是利用Router合約得到的,其實WETH合約人人都可以部署一個,是可以存在多個的,如果存在這種情況,到呼叫哪個地址實體化呢?用Router合約用到的那個地址才是一致的,是準確無誤的,

  • receive() external payable {} 這行代碼代表可以接收直接發送的ETH,注釋的意思和上一篇文章學習中對應的注釋類似,這里不再重復了,

四、uniswapV2Call函式學習

uniswapV2Call函式,它的注釋清晰的解釋了套利的程序,這期間你不需要擁有任何一種交易對中的資產(僅需要有少量的ETH來支付gas費用),俗稱空手套白狼,它的四個輸入引數為呼叫者(其實就是最初發起交易的賬號)、從V2交易對發送過來的兩種資產數量、用戶預先定義的資料,

注意上面提到的V2版本交易對的這行代碼:

if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data);,這就意味著本合約實際上為上述代碼中的to,也就是說用戶呼叫交易對合約的swap函式時,輸入的接收地址to必須為本合約地址,

下面我們來詳細學習該函式:

  • 第一行定義了一個path來保存兩種資產的地址,path是路徑的意思,也可以代表交易路徑(流程),
  • 第2-3行定義了兩個臨時變數來記錄買進的ETH/TOKEN數量,方便辨識,不然token0token1你都不知道是什么,
  • 4、13行用來防止stack too deep errors,已經講過多次,不再重復,
  • 5-6行用來獲取V2交易對的兩種代幣地址,這里msg.sender就是V2的交易對,因為本函式是從V2交易對呼叫的,見上面列出的那行呼叫代碼,
  • 第7行用來驗證呼叫者(交易對)地址和使用UniswapV2工具庫算出來的地址相同,確保呼叫者就是V2交易對,不是假的或者偽裝的,
  • 第8行注釋說的很清楚,單向的,也就是只能賣出一種資產,得到另一種資產,不能兩種資產都賣,雖然UniswapV2交易對支持這種操作,但是這里套利是不支持這種操作的,所以只能得到一種資產,其中必定有一種資產為0,那有沒有兩種資產都為0呢?沒有這種可能,在UniswapV2交易對中對買進的資產做了限制,至少要買進一種(大于0),
  • 第9行和第10行就很明顯了,設定path[0]為賣出的資產(買進的為0),path[1]為買進的資產,也就是交易路徑為path[0] => path[1],這里需要說明,UniswapV2交易對呼叫此函式時提供的輸入引數amount0amount1是和token0token1對應的,也就是token0的買進數量為amount0
  • 第11行用來設定amountToken數值,如果token0為WETH地址,那么另一種資產必為TOKEN,所以其數值為amount1;否則就是本資產token0,對應的數值為amount0
  • 第12行用來設定amountETH數值,邏輯同上,
  • 第14行進一步驗證PATH中必須有一種地址為WETH地址,當然你也可以驗證token0或者token1必須有一個為WETH地址,它們是等效的,注釋講了用來確保它是V2中的包含WETH的交易對(否則無法和V1交易對套利),前面第7行只驗證了必須為V2交易對,
  • 第15行用來獲取同時涉及到兩種版本交易對的ERC20代幣實體,
  • 第16行用來獲取V1版本相應交易對的實體,它呼叫了V1版本的factory中的getExchange介面來獲取包含該ERC20代幣(15行那個實體)的交易對地址,
  • 接下來是一個if - else陳述句來根據從UniswapV2交易對得到的是普通ERC20代幣還是ETH分情況和UniswapV1的交易對進行交易,最后將得到的另一種資產支付給UniswapV2交易對,自己留下剩余的,實作套利的目的,
  • 如果是amountToken > 0,那就是從UniswapV2交易對得到了普通ERC20代幣,則接著進行:
    • 第18行將隨交易發送的資料data解碼成uint格式,并設定成為minETH的值,這個minETH是在V1交易對交易時指定得到的ETH最小值,這個解碼的語法abi.decode這里已經是第二次使用了,第一次使用在核心合約中的交易對合約的_safeTransfer函式中:abi.decode(data, (bool)),大家可以自己對照看一下,
    • 第19行對V1版本的交易對進行獲得的代幣的授權,因為V1版本交易對是授權交易,不是先轉移資產再交易,所以必須授權,
    • 第20行呼叫V1版本交易對相應的函式將TOKEN交易成ETH,也就是賣出TOKEN,得到ETH,引數分別是賣出的TOKEN數量,指定獲取的ETH最小數量及最晚交易時間,
    • 第21行根據UniswapV2的工具庫計算需要支付給UniswapV2交易對的另一種資產WETH的數值,注意:getAmountsIn函式回傳的是一個陣列,它的第一個元素就是賣出的初始資產的數量,具體分析可以參考序列文章中的周邊合約學習中的Router合約學習,
    • 第22行驗證從V1交易對換回的ETH數量必須大于欲支付給V2交易對的WETH數量,否則不夠支付,交易會重置,這里可以看到驗證時用了assert函式,但是我們有時也會在合約中看到使用require函式驗證,那么什么時候用require什么時候用assert呢?一般的原則為:當驗證直接外界輸入時,使用require;當驗證內部結果時,使用assert,可以看到這里是驗證中間的一個計算結果,所以使用了assert
    • 第23行,將ETH兌換成等額的欲支付數量的WETH,從第22行知道,這里ETH沒有兌換完,還有剩余的,這就是盈利,
    • 第24行,將欲支付數量的WETH轉移到V2交易對(msg.sender),這里就是先借后還的“還”,那什么時候開始借的呢,從呼叫本函式之前就借給本合約(轉移資產到本合約)了,
    • 第25-26行,將剩余的ETH發送給呼叫者(也就是初始用戶),并驗證發送是否成功,這里使用了一個低級函式call,它如果執行失敗,并不會重置整個交易,而是回傳一個false,所以這里必須驗證回傳值,這里為什么不使用更高級的address型別的transfersend成員呢,個人猜想原因有:
      1. 不易和WETH.transfer這種呼叫陳述句相區分,可能引起閱讀上的混淆;
      2. transfersend 必須在address payable型別上使用,需要使用payable(sender)來轉換,
      3. 因為transfersend函式限定了隨函式傳輸的gas為2300,萬一接收地址是一個合約,它還需要接收ETH后再做別的事,這時便會引起out of gas,導致交易失敗,使用call可以將所有能得到的gas都傳輸過去,利于接收方再執行其它操作,
      4. 小提示,不管是用transfersend還是call來發送ETH,接收地址如果是合約的話,必須有相應接收ETH的回呼函式,例如本合約中出現的receive,否則交易會失敗,
  • 如果是else,那就是amountETH > 0,也就是從UniswapV2交易對得到的是WETH,需要使用它從V1交易對中兌換出來TOKEN,然后再支付TOKEN給V2版本的交易對,
    • 第28行,解碼獲得用戶輸入的最小token數量,
    • 第29行,將所有WETH兌換成等額ETH,以便接下來和V1交易對交易,
    • 第30行,將所有ETH在V1交易對中交易成TOKEN,
    • 第31行,利用UniswapV2的工具庫計算需要支付給UniswapV2交易對的TOKEN的數量,它和30行得到的數量差就是盈利的數量,
    • 第32行,驗證從V1版本換回的TOKEN數量必須大于支付給UniswapV2交易對的TOKEN數量,否則不夠支付(盈利為負),會重置交易,
    • 第33行,將支付的TOKEN發送到V2交易對,也就是msg.sender,這里就是先借后還中的“還”,這里因為使用了assert函式,所以要求token.transfer必須回傳一個true,所以這個TOKEN對應的代幣合約必需滿足這個條件(個人猜想因為代幣合約是外部合約,是未知的,有可能不回傳值或者回傳為false,所以必須加一個條件),
    • 第34行,將剩余的TOKEN發送給最初用戶(sender),這里不用考慮接收方(sender)是合約還是外部賬號,因為不是發送ETH,使用assert同上,

五、其它

大家從這個合約可以看出,套利合約使用沒有門檻,但它并不意味著我們隨時都可以使用這個套利合約來套利,個人覺得使用條件及限制有:

  • 首先套利的兩個交易對能資產要一致,這是很明顯的,你不能tokenA最后套成了tokenB,
  • 其次兩個交易對的價格有差別,要有利可套,否則交易回來的資產不夠支付的,交易會重置,白白損失手續費,
  • 套利到底能套多少未知,無法提前線下計算,因為它和交易時兩種交易對交易執行時價格有關,有可能你執行前是可以套利的,但執行時價格回落 ,你就無法套利了,

實際中也有其它DeFi交易對和UniswapV2交易對之間套利的應用,例如DODO這個專案就有一個套利合約UniswapArbitrageur.sol(不過是針對特定交易對的),大家有興趣的可以自己去看一下,

好了,今天的套利合約示例學習就到此結束了,下一次計劃學習ExampleOracleSimple.sol(價格預言機示例合約),

由于個人能力有限,難免有理解錯誤或者不正確的地方,還請大家多多留言指正,

轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/191948.html

標籤:其他

上一篇:DeFi去中心化交易所系統開發技術

下一篇:數字貨幣交易所系統開發(技術)

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀:**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題,由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視,實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶,一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀:**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高,采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐,遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀:**滴滴資料通道引擎承載著全公司的資料同步,為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加,資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程,遇到的問題以及今后的規劃。 #1. 背景 資料,對于任何一家互聯網公司來說都是非常重要的資產,公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀:**深耕人工智能領域,致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎,這次獲獎的專案是什么呢?一起來看看詳細報道吧! 近日,由國際計算語言學協會ACL(The Association for Computational Linguistics)舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp? MPP (Massively Parallel Processing),即大規模并行處理,在資料庫非共享集群中,每個節點都有獨立的磁盤存盤系統和記憶體系統,業務資料根據資料庫模型和應用特點劃分到各個節點上,每臺資料節點通過專用網路或者商業通用網路互相連接,彼此協同計算,作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀:**指標體系是什么?如何使用OSM模型和AARRR模型搭建指標體系?如何統一流程、規范化、工具化管理指標體系?本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標,系統化的組織起來,通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索,LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料,可以使用下面的 SQL 陳述句: SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀:**Ceph是國際知名的開源分布式存盤系統,在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統, ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章,這一次主要寫一個嵌套的聚合,例如先對sex集合,再對desc聚合,最后再對age求和,共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by,avg,sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack(ELK)部署

    傻瓜式部署,只需替換IP與用戶 導讀: 現ELK四大組件分別為:Elasticsearch(核心)、logstash(處理)、filebeat(采集)、kibana(可視化) 下載均在https://www.elastic.co/cn/downloads/下tar包,各組件版本最好一致,配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:33:24 more
  • MySQL中binlog備份腳本分享

    關于MySQL的二進制日志(binlog),我們都知道二進制日志(binlog)非常重要,尤其當你需要point to point災難恢復的時侯,所以我們要對其進行備份。關于二進制日志(binlog)的備份,可以基于flush logs方式先切換binlog,然后拷貝&壓縮到到遠程服務器或本地服務器 ......

    uj5u.com 2023-04-20 08:28:06 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:27:27 more
  • 快取與資料庫雙寫一致性幾種策略分析

    本文將對幾種快取與資料庫保證資料一致性的使用方式進行分析。為保證高并發性能,以下分析場景不考慮執行的原子性及加鎖等強一致性要求的場景,僅追求最終一致性。 ......

    uj5u.com 2023-04-20 08:26:48 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:26:35 more
  • 云時代,MySQL到ClickHouse資料同步產品對比推薦

    ClickHouse 在執行分析查詢時的速度優勢很好的彌補了MySQL的不足,但是對于很多開發者和DBA來說,如何將MySQL穩定、高效、簡單的同步到 ClickHouse 卻很困難。本文對比了 NineData、MaterializeMySQL(ClickHouse自帶)、Bifrost 三款產品... ......

    uj5u.com 2023-04-20 08:26:29 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:25:13 more
  • Redis 報”OutOfDirectMemoryError“(堆外記憶體溢位)

    Redis 報錯“OutOfDirectMemoryError(堆外記憶體溢位) ”問題如下: 一、報錯資訊: 使用 Redis 的業務介面 ,產生 OutOfDirectMemoryError(堆外記憶體溢位),如圖: 格式化后的報錯資訊: { "timestamp": "2023-04-17 22: ......

    uj5u.com 2023-04-20 08:24:54 more
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:24:03 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:23:11 more