22 多級緩存（百度一面）

22.1 你用了什么緩存

答：本地內(nèi)存+redis

22.2 內(nèi)存標(biāo)記是如何被使用被更新的

22.3 什么時(shí)候修改這個(gè)第一層緩存（內(nèi)存標(biāo)記），把它改為false

答：當(dāng)redis預(yù)減庫存為0的時(shí)候，這個(gè)就需要改為false

22.4 這個(gè)內(nèi)存標(biāo)記可以被稱為第二級緩存嗎？（我答錯了）

22.4.1 內(nèi)存標(biāo)記和redis預(yù)減庫存的操作，哪一個(gè)屬于一級緩存哪一個(gè)屬于二級

在秒殺系統(tǒng)設(shè)計(jì)中，"內(nèi)存標(biāo)記"和"Redis預(yù)減庫存"都是優(yōu)化手段，旨在減少對數(shù)據(jù)庫的訪問以提高系統(tǒng)的性能。但在緩存的層級分類中，這兩者的位置可以如下解釋：

1. 內(nèi)存標(biāo)記：它直接在應(yīng)用程序的內(nèi)存中進(jìn)行，速度非?？?。因?yàn)檫@種操作不需要與任何外部系統(tǒng)通信，所以它通常被視為一級緩存。

2. Redis預(yù)減庫存：Redis是一個(gè)外部的內(nèi)存存儲系統(tǒng)，雖然它非?？?，但與直接在應(yīng)用程序的內(nèi)存中進(jìn)行操作相比，訪問Redis會涉及到網(wǎng)絡(luò)通信的延遲。因此，從緩存的層級分類角度來看，Redis通常被視為二級緩存。

所以，簡而言之，內(nèi)存標(biāo)記是一級緩存，而Redis預(yù)減庫存是二級緩存。

22.4.2 一級、二級緩存的區(qū)別標(biāo)志是什么呢

一級緩存和二級緩存的區(qū)別通?；谝韵绿匦曰驑?biāo)志來定義：

1. 存儲位置：

   • 一級緩存：通常存儲在事務(wù)或會話的上下文中，這意味著它是局部的，僅與單個(gè)會話或線程相關(guān)。例如，在某些ORM框架中，一級緩存是與單個(gè)會話關(guān)聯(lián)的。
   • 二級緩存：通常是全局的，它存儲在進(jìn)程或應(yīng)用之外的位置，并可供多個(gè)會話或線程共享。例如，分布式緩存系統(tǒng)如Redis或Memcached。

2. 生命周期：

   • 一級緩存：生命周期通常限于單個(gè)會話或事務(wù)。會話結(jié)束時(shí)，緩存中的數(shù)據(jù)也可能被清除。
   • 二級緩存：生命周期超出單個(gè)會話，通?；跁r(shí)間或容量失效策略來管理。

3. 數(shù)據(jù)共享性：

   • 一級緩存：因?yàn)樗蔷植康模圆粫欢鄠€(gè)會話或線程共享。
   • 二級緩存：可以被多個(gè)會話、線程或甚至是多個(gè)應(yīng)用實(shí)例共享。

4. 訪問速度：

   • 一級緩存：訪問速度非常快，因?yàn)樗ǔＴ趹?yīng)用程序的內(nèi)存中。
   • 二級緩存：雖然也是非?？斓模捎诳赡苌婕暗竭M(jìn)程間或網(wǎng)絡(luò)通信，所以相對較慢。

5. 失效策略：

   • 一級緩存：通常在會話結(jié)束或事務(wù)完成后自動失效。
   • 二級緩存：通?；诰唧w的失效策略，如LRU、TTL等。

6. 復(fù)雜性：

   • 一級緩存：通常更簡單，自動管理。
   • 二級緩存：可能需要更多的配置和管理，尤其是當(dāng)涉及到分布式緩存系統(tǒng)時(shí)。

根據(jù)上述特點(diǎn)，開發(fā)者可以根據(jù)實(shí)際需要選擇使用一級緩存、二級緩存或兩者結(jié)合，以優(yōu)化應(yīng)用程序的性能。

22.4.3 我覺得可以根據(jù)距離cpu的邏輯遠(yuǎn)近來判斷，比如本地內(nèi)存標(biāo)記不需要網(wǎng)絡(luò)通信，所以是一級，redis需要網(wǎng)絡(luò)通信，所以是二級 另外一種角度看，數(shù)據(jù)是首先同步到redis，然后再同步到內(nèi)存標(biāo)記的

確實(shí)，根據(jù)數(shù)據(jù)存取的速度和距離CPU的邏輯遠(yuǎn)近來判斷緩存層級是非常直觀的方式。在計(jì)算機(jī)架構(gòu)中，這種分類方式常被用來描述CPU的緩存層級（L1、L2、L3等），其中距離CPU核心越近、速度越快的緩存被視為更低的層級。

對于應(yīng)用層面的緩存：

• 一級緩存：通常指直接存儲在應(yīng)用進(jìn)程中的緩存，如Java對象在JVM堆上的存儲。這種緩存的訪問速度極快，不涉及任何跨進(jìn)程或網(wǎng)絡(luò)通信。

• 二級緩存：涉及到跨進(jìn)程通信或網(wǎng)絡(luò)通信的緩存，如Redis、Memcached等分布式緩存系統(tǒng)。雖然它們?nèi)匀皇莾?nèi)存存儲，但由于涉及通信，訪問速度相對較慢。

你的觀點(diǎn)完全成立。如果數(shù)據(jù)首先同步到Redis然后再同步到內(nèi)存標(biāo)記，那么可以將Redis視為一種“前置緩存”或“緩沖層”，而應(yīng)用內(nèi)存中的標(biāo)記則可以視為更接近實(shí)際數(shù)據(jù)處理和業(yè)務(wù)邏輯的一級緩存。

這種層級化的緩存策略使得應(yīng)用能夠更加靈活地處理高并發(fā)情況，同時(shí)確保數(shù)據(jù)的一致性和系統(tǒng)的響應(yīng)速度。

22.5 內(nèi)存標(biāo)記和redis緩存的區(qū)別是什么呢？

答：使用內(nèi)存標(biāo)記就不需要和遠(yuǎn)程主機(jī)進(jìn)行網(wǎng)絡(luò)通信

23 一致性與緩存和mysql的更新機(jī)制（百度一面）

23.1 如果有一部分流量進(jìn)來了之后，就卡在這個(gè)邊界點(diǎn)，你怎么去判斷？如果秒殺第10件商品的時(shí)候，有兩個(gè)請求同時(shí)打到后端，有沒有可能這兩個(gè)請求都進(jìn)到你的消息隊(duì)列中去？

答：有可能的，因?yàn)閞edission可能會發(fā)生數(shù)據(jù)丟失，redis集群本身只能保證最終一致性

23.2 如果有一主多從的話，是不是可能存在多個(gè)流量進(jìn)來呢？

答：對，但是這種概率很低，因?yàn)橐粋€(gè)redis集群連續(xù)發(fā)生多次主從切換的可能性很小

23.3 前端這個(gè)時(shí)候，你會提示它在等待嗎？

答：對，會顯示排隊(duì)中，客戶端會不斷輪詢后端暴露出來的一個(gè)查詢訂單的接口，查看是否存在，這個(gè)接口會增加這個(gè)訂單到redis緩存中

23.3.1 為什么這個(gè)時(shí)候數(shù)據(jù)庫和redis的同步機(jī)制是先更新mysql，后更新緩存？難道不存在不一致問題嗎？

答：這個(gè)時(shí)候，客戶端只涉及到查詢訂單操作，而不涉及到修改，而且只有這一個(gè)服務(wù)端線程會修改redis緩存，所以可以采用先更新mysql，再刪除redis

23.4 如果用戶下單后沒多久又取消訂單了怎么辦？如果沒有支付怎么辦（誤區(qū)：（1）把這兩個(gè)弄成了一個(gè)事情，庫存回退沒有說，兩級緩存更新沒有說）

答：

當(dāng)用戶下單后沒多久又取消訂單，或者下單后未支付，系統(tǒng)需要有一套相應(yīng)的處理機(jī)制。這些機(jī)制通常涉及訂單的生命周期管理、庫存管理、支付超時(shí)等。以下是一些常見的處理方式：

1. 訂單取消：

   • 庫存回滾：當(dāng)用戶取消訂單，前端會向指定的接口立即發(fā)送請求，系統(tǒng)應(yīng)立即將對應(yīng)的商品庫存數(shù)量回滾。
   • 訂單狀態(tài)管理：訂單應(yīng)有多個(gè)狀態(tài)，如“已創(chuàng)建”、“已支付”、“已取消”等。當(dāng)用戶取消訂單時(shí)，系統(tǒng)應(yīng)將訂單狀態(tài)更改為“已取消”。
   • 庫存回退和緩存更新：會將這個(gè)庫存回退到mysql的商品表中，然后會刪除redis中相應(yīng)的訂單，同時(shí)刪除redis的關(guān)于該庫存信息的緩存，然后再將業(yè)務(wù)服務(wù)器中的該商品是否售罄的緩存更新為false

2. 未支付的訂單：

   • 支付超時(shí)機(jī)制：為訂單設(shè)定一個(gè)支付超時(shí)時(shí)間（例如15或30分鐘）。如果用戶在這個(gè)時(shí)間內(nèi)沒有完成支付，系統(tǒng)自動將訂單狀態(tài)更改為“已取消”并回滾庫存。
   • 超時(shí)提醒：當(dāng)訂單即將到達(dá)超時(shí)時(shí)間時(shí)，可以通過短信、郵箱或應(yīng)用內(nèi)通知提醒用戶支付。
   • 定期檢查：后端可以使用定時(shí)任務(wù)或其他機(jī)制定期檢查未支付的訂單，并根據(jù)其創(chuàng)建時(shí)間處理超時(shí)訂單。
   • 庫存回退和緩存更新：(基本邏輯和訂單取消的相應(yīng)邏輯相同)

總之，對于用戶的取消訂單或未支付行為，系統(tǒng)應(yīng)該有一套完整的策略和流程，確保商家的利益和其他用戶的正常購買體驗(yàn)不受影響。

23.5 你的一級緩存如何更新呢？這是不是涉及到了多個(gè)本地內(nèi)存機(jī)器的內(nèi)存標(biāo)記的更新呢？

答：

一級緩存通常指的是業(yè)務(wù)服務(wù)器本地的內(nèi)存緩存，例如Java中的ConcurrentHashMap或其他本地緩存工具。更新一級緩存的方法和策略如下：

• 數(shù)據(jù)變動觸發(fā)：當(dāng)有關(guān)鍵數(shù)據(jù)（如庫存）變動時(shí)，我們需要同時(shí)更新一級緩存中的相關(guān)數(shù)據(jù)。
• 多機(jī)器同步問題：在分布式環(huán)境中，可能有多個(gè)業(yè)務(wù)服務(wù)器實(shí)例，因此當(dāng)一級緩存的數(shù)據(jù)在一個(gè)實(shí)例中被修改時(shí)，我們需要確保其他實(shí)例的緩存數(shù)據(jù)也被相應(yīng)地更新。這通常通過消息中間件如Kafka、RabbitMQ等來實(shí)現(xiàn)，當(dāng)一個(gè)實(shí)例更新了緩存，它會發(fā)送一個(gè)消息到消息中間件，其他實(shí)例監(jiān)聽到這個(gè)消息后會更新自己的一級緩存。
• 定期刷新：一些數(shù)據(jù)可能不是經(jīng)常變動，但為了確保數(shù)據(jù)的時(shí)效性和準(zhǔn)確性，可以設(shè)置一個(gè)定期刷新的策略，例如每隔一段時(shí)間從數(shù)據(jù)庫或二級緩存（如Redis）中重新加載數(shù)據(jù)。

23.6 你的緩存更新會不會造成并發(fā)的沖突呢？比如客戶端線程在讀，服務(wù)端線程在寫

答：

緩存并發(fā)的問題確實(shí)是一個(gè)需要關(guān)注的點(diǎn)。根據(jù)不同的緩存類型和策略，處理方式也會有所不同。

• Redis緩存：Redis是單線程模型，它確保了每次只有一個(gè)命令在執(zhí)行，因此不會有并發(fā)沖突。但在分布式應(yīng)用中，多個(gè)客戶端同時(shí)發(fā)送命令到Redis可能會造成讀舊數(shù)據(jù)的情況。為了避免這種情況，可以使用Redis的事務(wù)功能或樂觀鎖來確保數(shù)據(jù)的一致性。

• 本地內(nèi)存緩存：在多線程環(huán)境中，本地緩存可能會出現(xiàn)并發(fā)的問題。例如，當(dāng)一個(gè)線程正在更新緩存數(shù)據(jù)時(shí)，另一個(gè)線程可能正在讀取這些數(shù)據(jù)。為了解決這個(gè)問題，可以使用并發(fā)工具，如Java中的ConcurrentHashMap或ReadWriteLock。ConcurrentHashMap允許多個(gè)讀線程并發(fā)進(jìn)行，但寫操作會被鎖定，確保每次只有一個(gè)線程可以寫入。ReadWriteLock也提供了類似的功能，但提供了更細(xì)粒度的控制。

綜上所述，確保緩存的并發(fā)安全是關(guān)鍵，需要根據(jù)實(shí)際情況選擇合適的工具和策略來實(shí)現(xiàn)。

24 (度小滿金融校招一面)你的用戶訂單的狀態(tài)機(jī)是怎么設(shè)計(jì)的呢，假設(shè)一條訂單的初始值為0，表示用戶下單了，1表示已經(jīng)支付了，2表示…

答：假設(shè)一條訂單的初始值為0，表示用戶下單但是仍然未支付，1表示成功支付了，待發(fā)貨中，2表示用戶主動取消訂單了，3表示過期沒有支付所以取消訂單，4是終態(tài)，不會再變化了。

24.1 你什么時(shí)候插入的訂單記錄？

答：消費(fèi)者主動從kafka消息隊(duì)列中拉取下單消息，進(jìn)行消費(fèi)的時(shí)候，會進(jìn)行下單操作。

24.2 基于你剛剛設(shè)計(jì)的狀態(tài)機(jī)，用戶的哪一個(gè)行為會導(dǎo)致狀態(tài)機(jī)由哪一個(gè)狀態(tài)流轉(zhuǎn)到哪一個(gè)狀態(tài)，這個(gè)由用戶導(dǎo)致的行為一般體現(xiàn)在后端系統(tǒng)中的哪一步

答：
（1）用戶點(diǎn)擊下單按鈕會生成一筆訂單，此時(shí)訂單的狀態(tài)是0，消費(fèi)者主動從kafka消息隊(duì)列中拉取下單消息，進(jìn)行消費(fèi)的時(shí)候，會進(jìn)行下單操作，此時(shí)變成初始狀態(tài)0

（2）用戶主動調(diào)用取消訂單的接口，會使得狀態(tài)由0變?yōu)?

（3）用戶調(diào)用支付接口，狀態(tài)由0變?yōu)?

（4）用戶過了三十分鐘沒有支付，延時(shí)消息會到期被消費(fèi)，將訂單狀態(tài)由0變?yōu)?

（5）用戶收到貨之后點(diǎn)擊收貨按鈕，就會變?yōu)榻K態(tài)

24.3 假設(shè)現(xiàn)在又新增了幾個(gè)狀態(tài)，退換貨完成，退換貨中，退款中，退款完成，交易關(guān)閉這幾個(gè)狀態(tài)，想一下連同新增的狀態(tài)，各個(gè)狀態(tài)之間怎么流轉(zhuǎn)，在什么時(shí)間點(diǎn)流轉(zhuǎn)。

答：考慮到新增的狀態(tài)，我們可以定義以下狀態(tài)值：

5 - 退換貨中
6 - 退換貨完成
7 - 退款中
8 - 退款完成
9 - 交易關(guān)閉

基于以上的狀態(tài)定義，以下是各狀態(tài)間的可能流轉(zhuǎn)以及在什么時(shí)間點(diǎn)流轉(zhuǎn)：

1. 用戶點(diǎn)擊下單按鈕
   用戶行為：點(diǎn)擊下單按鈕
   狀態(tài)流轉(zhuǎn)：初始 -> 0 (未支付)

2. 用戶取消訂單
   用戶行為：主動調(diào)用取消訂單的接口
   狀態(tài)流轉(zhuǎn)：0 (未支付) -> 2 (用戶主動取消)

3. 用戶支付
   用戶行為：調(diào)用支付接口
   狀態(tài)流轉(zhuǎn)：0 (未支付) -> 1 (已支付待發(fā)貨)

4. 用戶超時(shí)未支付
   系統(tǒng)行為：處理延時(shí)消息
   狀態(tài)流轉(zhuǎn)：0 (未支付) -> 3 (過期未支付)

5. 用戶確認(rèn)收貨
   用戶行為：點(diǎn)擊收貨按鈕
   狀態(tài)流轉(zhuǎn)：1 (已支付待發(fā)貨) -> 4 (交易完成)

6. 用戶申請退換貨
   用戶行為：點(diǎn)擊申請退換貨
   狀態(tài)流轉(zhuǎn)：4 (交易完成) -> 5 (退換貨中)

7. 退換貨完成
   系統(tǒng)行為：確認(rèn)退換貨請求已處理
   狀態(tài)流轉(zhuǎn)：5 (退換貨中) -> 6 (退換貨完成)

8. 用戶申請退款
   用戶行為：點(diǎn)擊申請退款
   狀態(tài)流轉(zhuǎn)：4 (交易完成) 或 6 (退換貨完成) -> 7 (退款中)

9. 退款完成
   系統(tǒng)行為：確認(rèn)退款已處理
   狀態(tài)流轉(zhuǎn)：7 (退款中) -> 8 (退款完成)

10. 交易關(guān)閉
    系統(tǒng)或用戶行為：在任何非終態(tài)下，由于某些原因（如長時(shí)間不活躍、交易異常等）交易關(guān)閉
    狀態(tài)流轉(zhuǎn)：任意狀態(tài) -> 9 (交易關(guān)閉)

以上流轉(zhuǎn)可能因業(yè)務(wù)需求的具體性而有所不同，但大致能夠涵蓋大部分場景。

25 希音一面：你的秒殺系統(tǒng)做的是增量還是存量庫存?。ǜ采w還是加減）

答：加減

25.1 我可以為你解釋增量庫存和全量庫存的概念：

1. 增量庫存：

   • 增量庫存是指對庫存的增加或減少是基于當(dāng)前庫存量進(jìn)行的。例如，如果當(dāng)前庫存為10，增量為+3，則新的庫存為13；如果增量為-2，則新的庫存為8。
   • 在實(shí)際操作中，增量庫存通常是通過加減操作來實(shí)現(xiàn)的。例如，每次商品銷售，庫存就減少相應(yīng)的數(shù)量；每次進(jìn)貨，庫存就增加相應(yīng)的數(shù)量。
   • 增量庫存操作更適合于實(shí)時(shí)或高并發(fā)的場景，因?yàn)樗梢院芎玫靥幚聿l(fā)操作，并確保數(shù)據(jù)的一致性。

2. 全量庫存：

   • 全量庫存是指每次更新庫存時(shí)，都是設(shè)置一個(gè)完整的庫存值，而不是基于當(dāng)前庫存進(jìn)行加減。
   • 例如，無論當(dāng)前庫存是多少，都可以直接設(shè)置庫存為20或其他任意值。
   • 全量庫存操作通常用于庫存的初始化、盤點(diǎn)或其他需要完全覆蓋當(dāng)前庫存的場景。

在實(shí)際的庫存管理系統(tǒng)中，增量庫存和全量庫存都有其應(yīng)用場景，具體使用哪種方式取決于業(yè)務(wù)需求和系統(tǒng)設(shè)計(jì)。

25.2 除了年終盤點(diǎn)，還有什么全量庫存的應(yīng)用場景呢？

1. 除了年終盤點(diǎn)，還有什么全量庫存的應(yīng)用場景呢？

   • 新商品上架：當(dāng)商店引入新的商品時(shí)，需要為這些商品設(shè)置初始的庫存量。這是一個(gè)全量庫存的操作，因?yàn)槭侵苯釉O(shè)置商品的庫存，而不是基于現(xiàn)有的庫存進(jìn)行加減。

   • 退貨和換貨：當(dāng)客戶退回或換貨時(shí)，可能需要對庫存進(jìn)行調(diào)整。在某些情況下，這種調(diào)整可能是全量的，例如直接設(shè)置某個(gè)商品的庫存為特定的數(shù)量。

   • 庫存調(diào)撥：在大型的零售或倉儲企業(yè)中，可能需要在不同的倉庫之間進(jìn)行庫存調(diào)撥。當(dāng)某個(gè)倉庫收到調(diào)撥的商品時(shí)，可能會直接設(shè)置這些商品的庫存，而不是基于現(xiàn)有的庫存進(jìn)行加減。

   • 庫存糾錯：如果發(fā)現(xiàn)之前的庫存記錄有誤，可能需要進(jìn)行庫存糾錯。這通常是一個(gè)全量庫存的操作，因?yàn)槭侵苯釉O(shè)置商品的庫存，而不是基于現(xiàn)有的庫存進(jìn)行加減。

2. 年終盤點(diǎn)：在零售或倉儲行業(yè)中，通常在年底會進(jìn)行一次全面的庫存盤點(diǎn)。在這個(gè)過程中，員工會手工點(diǎn)驗(yàn)每一件商品，然后將實(shí)際的庫存數(shù)量錄入系統(tǒng)。由于這是一個(gè)全面的盤點(diǎn)，所以不考慮之前的庫存數(shù)量，直接將系統(tǒng)中的庫存值設(shè)置為盤點(diǎn)后的實(shí)際數(shù)量。這就是一個(gè)典型的全量庫存的應(yīng)用場景。

25.3 這兩種庫存方式的冪等性怎么保證

1. 增量庫存的冪等性怎么保證：

   • 唯一標(biāo)識：為每次的庫存變動操作生成一個(gè)唯一的標(biāo)識（如訂單號、事務(wù)ID等）。在操作前檢查該標(biāo)識是否已經(jīng)被處理過，如果已處理，則不再進(jìn)行操作。
   • 數(shù)據(jù)庫鎖：使用數(shù)據(jù)庫的行鎖或樂觀鎖來確保同一時(shí)間只有一個(gè)操作能夠更改庫存。
   • 狀態(tài)檢查：在進(jìn)行增量操作前，檢查商品或訂單的狀態(tài)，確保不會重復(fù)處理。
   • 消息隊(duì)列：使用支持冪等性的消息隊(duì)列，如Kafka，確保消息只被消費(fèi)一次。

2. 全量庫存的冪等性：

   全量庫存的冪等性相對容易保證，因?yàn)槊看味际窃O(shè)置一個(gè)固定的值，不依賴于之前的狀態(tài)。只要確保每次設(shè)置的值是相同的，那么多次操作的結(jié)果也是相同的。但在實(shí)際操作中，還需要考慮以下幾點(diǎn)：

   • 唯一標(biāo)識：同樣可以為每次的庫存設(shè)置操作生成一個(gè)唯一的標(biāo)識，以確保不會重復(fù)設(shè)置。
   • 版本控制：為庫存數(shù)據(jù)增加版本號或時(shí)間戳，每次更新時(shí)比較版本號或時(shí)間戳，只有當(dāng)新的版本號或時(shí)間戳大于當(dāng)前的版本號或時(shí)間戳?xí)r，才進(jìn)行更新。
   • 數(shù)據(jù)庫鎖：使用數(shù)據(jù)庫的行鎖或樂觀鎖來確保同一時(shí)間只有一個(gè)操作能夠設(shè)置庫存。

25.4 增量庫存可以使用下面這些全量庫存版本控制的方法嘛？

是的，增量庫存同樣可以使用以下的版本控制方法：

• 唯一標(biāo)識：為每次的庫存變動操作生成一個(gè)唯一的標(biāo)識（如訂單號、事務(wù)ID等）。這可以確保每次的庫存變動操作不會被重復(fù)執(zhí)行。
• 版本控制：為庫存數(shù)據(jù)增加版本號或時(shí)間戳是一個(gè)常見的策略，特別是在高并發(fā)的場景下。當(dāng)多個(gè)請求同時(shí)嘗試修改庫存時(shí)，只有版本號或時(shí)間戳匹配的請求才會被執(zhí)行，其他的請求則會被拒絕。這樣可以確保庫存的數(shù)據(jù)一致性和操作的冪等性。

26 吞吐量達(dá)到極限了怎么繼續(xù)提升(度小滿金融三面)

26.1 秒殺主要體現(xiàn)在哪個(gè)地方呢，吞吐量高嗎還是

答：秒殺主要體現(xiàn)在系統(tǒng)的短時(shí)間內(nèi)需要處理大量用戶的并發(fā)請求，特別是在秒殺活動開始的那一剎那。因此，秒殺系統(tǒng)的吞吐量需求非常高，以確保在短時(shí)間內(nèi)處理盡可能多的用戶請求，同時(shí)確保系統(tǒng)的穩(wěn)定性和可用性。

26.2 你的極限吞吐量怎么得來的

答：極限吞吐量通常通過壓力測試得出。在控制條件下，我們會逐漸增加發(fā)向系統(tǒng)的請求，并監(jiān)控系統(tǒng)的響應(yīng)時(shí)間和錯誤率。當(dāng)我發(fā)現(xiàn)進(jìn)一步提高線程數(shù)或并發(fā)請求時(shí)，tps開始下降或系統(tǒng)響應(yīng)時(shí)間顯著增加，這時(shí)的吞吐量就是系統(tǒng)的極限吞吐量。

26.3 有沒有可能是發(fā)壓的地方扛不住了呢

答：有這種可能性。發(fā)壓工具或者發(fā)壓機(jī)本身也可能成為瓶頸，特別是當(dāng)它所在的硬件資源不足或網(wǎng)絡(luò)帶寬受限時(shí)。這也是為什么在進(jìn)行壓力測試時(shí)，我們也要監(jiān)控發(fā)壓機(jī)的資源使用情況。

26.4 你在什么樣機(jī)器上發(fā)出這1w個(gè)請求呢，為什么能抗住這1w線程或者更多的并發(fā)請求呢

答：本地，16GB的內(nèi)存，8核心，首先我是在本地進(jìn)行壓測的，它不涉及到遠(yuǎn)程通信，此外它的秒殺接口返回的信息量很少，各個(gè)服務(wù)也是本地部署，也就是說本機(jī)進(jìn)程之間的通信速度也很快，這樣就是說開的這些線程并發(fā)數(shù)雖然很高，但是也會很快釋放資源，或者說執(zhí)行完的線程會被重用。

26.5 那你這里2600TPS沒法提高的瓶頸大概是在什么地方呢？假設(shè)我想讓他提到3000，4000，需要在哪些地方做優(yōu)化呢

答：要提高TPS，首先需要識別當(dāng)前的瓶頸。這可能涉及到CPU、內(nèi)存、數(shù)據(jù)庫、網(wǎng)絡(luò)等多個(gè)方面。優(yōu)化可能包括對Redis進(jìn)行水平擴(kuò)展，對各微服務(wù)進(jìn)行集群部署和負(fù)載均衡，優(yōu)化數(shù)據(jù)庫查詢和索引，甚至考慮使用更高效的硬件。

26.6 剛剛你說對redis做水平擴(kuò)展，是默認(rèn)了redis已經(jīng)是瓶頸了是嗎

答：不完全是。提到Redis的水平擴(kuò)展是基于它常常是高并發(fā)系統(tǒng)中的一個(gè)瓶頸點(diǎn)。但真正的瓶頸可能涉及多個(gè)方面。為了確定真正的瓶頸，需要進(jìn)行深入的性能分析和監(jiān)控。

26.7 你覺得你寫的這個(gè)系統(tǒng)在，是哪一個(gè)地方的資源或者哪一種資源不夠，導(dǎo)致需要做水平擴(kuò)展呢，比如IO，磁盤，網(wǎng)絡(luò)，線程，內(nèi)存和cpu

答：
（1）如果目的是提升整個(gè)微服務(wù)后端系統(tǒng)的總體tps，那么發(fā)壓方的機(jī)器也需要進(jìn)行集群部署，并在每個(gè)機(jī)器上隨機(jī)訪問不同的接口，以模擬真實(shí)的分布式環(huán)境。

（2）對于提升秒殺接口的tps，我認(rèn)為訂單處理服務(wù)可能是一個(gè)主要的瓶頸，因?yàn)樗婕暗綆齑娴目蹨p和訂單的生成。因此，訂單服務(wù)集群的水平擴(kuò)展可能是個(gè)好選擇，這樣可以提高它的CPU處理能力，從而提高整體的tps。

27 支付業(yè)務(wù)場景（百度acg百度網(wǎng)盤一面）

27.1 但你這到下單這一步已經(jīng)是異步了，用戶怎么知道是否可以支付呢？怎么立即跳轉(zhuǎn)到支付頁面呢（重點(diǎn)）

答：

您提到的問題確實(shí)是在設(shè)計(jì)異步下單系統(tǒng)時(shí)需要考慮的關(guān)鍵點(diǎn)。即使下單操作是異步的，用戶仍然需要得到一個(gè)明確的反饋來知道他們的下單請求是否被接受，以及是否可以繼續(xù)支付。以下是一種可能的解決方案：

1. 預(yù)下單響應(yīng)：當(dāng)用戶點(diǎn)擊下單按鈕后，系統(tǒng)立即接收請求并將其放入消息隊(duì)列中進(jìn)行異步處理。同時(shí)，系統(tǒng)可以立即返回一個(gè)預(yù)下單的響應(yīng)給用戶，這個(gè)響應(yīng)可能包含一個(gè)訂單ID或一個(gè)跟蹤號，以及一個(gè)提示信息，例如“您的訂單正在處理中，請稍候”。

2. 輪詢或WebSocket（重點(diǎn)）：在用戶端，可以使用輪詢或WebSocket等技術(shù)來定期查詢訂單的狀態(tài)。當(dāng)訂單處理完成（無論成功還是失?。?，系統(tǒng)會更新訂單狀態(tài)。用戶端在檢測到訂單狀態(tài)變化后，可以根據(jù)新的狀態(tài)給用戶提供相應(yīng)的反饋。例如，如果訂單處理成功，可以引導(dǎo)用戶到支付頁面；如果訂單處理失敗，可以給用戶顯示一個(gè)錯誤消息。

3. 通知機(jī)制：除了輪詢或WebSocket，系統(tǒng)還可以使用其他通知機(jī)制，如推送通知，來告知用戶訂單的狀態(tài)變化。

4. 超時(shí)處理：為了避免用戶長時(shí)間等待，可以設(shè)置一個(gè)合理的超時(shí)時(shí)間。如果在這個(gè)時(shí)間內(nèi)訂單仍然沒有被處理，可以認(rèn)為訂單處理失敗，并給用戶顯示一個(gè)超時(shí)錯誤消息。

5. 優(yōu)化異步處理速度：雖然下單操作是異步的，但仍然應(yīng)該盡量優(yōu)化其處理速度，確保大多數(shù)訂單可以在很短的時(shí)間內(nèi)被處理。這樣，用戶在等待訂單處理的時(shí)間會盡量縮短，提高用戶體驗(yàn)。

通過上述方法，即使下單操作是異步的，用戶仍然可以得到明確的反饋，并在適當(dāng)?shù)臅r(shí)候被引導(dǎo)到支付頁面。文章來源地址http://www.zghlxwxcb.cn/news/detail-707908.html

到了這里，關(guān)于微服務(wù)系統(tǒng)面經(jīng)之三: 以秒殺系統(tǒng)為例-多級緩存及其更新機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！