• 如果讓你設計一個秒殺系統，你會如何設計？

  • Redis是一個分布式緩存系統，支持多種數據結構，我們可以利用Redis輕松實現一個強大的秒殺系統。

    我們可以采用Redis 最簡單的key-value數據結構，用一個原子類型的變量值(AtomicInteger)作為key，把用戶id作為value，庫存數量便是原子變量的最大值。對于每個用戶的秒殺，我們使用 RPUSH key value插入秒殺請求， 當插入的秒殺請求數達到上限時，停止所有后續插入。

    然后我們可以在臺啟動多個工作線程，使用 LPOP key 讀取秒殺成功者的用戶id，然后再操作數據庫做最終的下訂單減庫存操作。

    當然，上面Redis也可以替換成消息中間件如ActiveMQ、RabbitMQ等，也可以將緩存和消息中間件 組合起來，緩存系統負責接收記錄用戶請求，消息中間件負責將緩存中的請求同步到數據庫
    原文：https://blog.csdn.net/suifeng3051/article/details/52607544?
    學習：秒殺系統架構分析與實戰 >?https://my.oschina.net/xianggao/blog/524943

• 如果讓你來設計一個消息中間件，你會從哪些方面來考慮？核心的架構以及數據結構如何設計？

  • 比如說這個消息隊列系統，我們來從以下幾個角度來考慮一下。

    （1）首先這個mq得支持可伸縮性吧，就是需要的時候快速擴容，就可以增加吞吐量和容量，那怎么搞？設計個分布式的系統唄，參照一下kafka的設計理念，broker -> topic -> partition，每個partition放一個機器，就存一部分數據。如果現在資源不夠了，簡單啊，給topic增加partition，然后做數據遷移，增加機器，不就可以存放更多數據，提供更高的吞吐量了？

    （2）其次你得考慮一下這個mq的數據要不要落地磁盤吧？那肯定要了，落磁盤，才能保證別進程掛了數據就丟了。那落磁盤的時候怎么落啊？順序寫，這樣就沒有磁盤隨機讀寫的尋址開銷，磁盤順序讀寫的性能是很高的，這就是kafka的思路。

    （3）其次你考慮一下你的mq的可用性啊？這個事兒，具體參考我們之前可用性那個環節講解的kafka的高可用保障機制。多副本 -> leader & follower -> broker掛了重新選舉leader即可對外服務。

    （4）能不能支持數據0丟失啊？可以的，參考我們之前說的那個kafka數據零丟失方案
    原文：https://blog.csdn.net/A_BlackMoon/article/details/85197979?
    ?

• 如果讓你來負責一個電商雙11大促系統，你會如何來考慮和設計？

  • 大型促銷活動帶來的是流量暴漲，在高訪問量的沖擊下，電商系統會受到以下挑戰：瞬間訪問量可能是平時的幾十倍；網絡帶寬被占滿，用戶響應很慢；機器負載高甚至宕機；數據庫壓力過大導致服務不可用,各家電商峰值系統的架構設計，由于電商規模、商業模式以及技術選型的不同，其技術方案多彩多樣、百花齊放，著實令人興奮，全面展現了互聯網技術開放和創新的特征。下面從這些架構設計方案中，抽象和總結出其共性相通的核心思路，進行一些概述。核心思路集中表現為：采用分而治之的思想，大系統小做，小系統大做。濃縮一下就是三個字：快、穩、炫

  • 快——天下武功，唯快不破

    快的目標是確保用戶端快速流暢的體驗。概括來說，可以通過以下技術手段實現快的目標。

    對前端頁面的處理

    ·?????????將有效期較長的靜態頁面通過CDN（Content Delivery Network，內容分發網絡）緩存到離用戶最近的服務節點上。

    ·?????????將有效期較短或者需要對失效時間做最大限度控制的靜態頁面，通過類似于Memcache的高速緩存系統或類似于Squid的反向代理系統緩存在服務端。

    ·?????????將混合型頁面（如商品單頁）進行動靜分離，靜態數據（如商品介紹等）緩存在本地，動態數據（如可用庫存和促銷價格等）異步進行加載。

    對后端數據的處理

    ·?????????數據庫SQL慢查詢優化。例如，重構相關索引，對where子句進行優化等。

    ·?????????數據庫讀寫分離。例如，MySQL的Master/Slave結構。

    ·?????????數據庫分庫分表。這是減輕單個數據庫服務器壓力的有效手段，不過同時也會帶來系統的復雜性，是魚和熊掌之間的關系。

    對網絡傳輸的處理

    ·?????????執行負載均衡，第四層交換按實現分類，分為硬件實現和軟件實現。通過硬件實現一般都由專業的硬件廠商作為商業解決方案提供，如F5等，這些產品非常昂貴，但能夠提供非常優秀的性能和很靈活的管理能力。通過軟件實現，如LVS等，雖然性能比專業硬件稍差，但軟件實現配置起來更靈活。

    穩——不管風吹浪打，勝似閑庭信步

    穩的目標是確保系統端穩定可靠的服務。無論在任何情況下，都要做到盡可能不宕機、不出錯。要做到這一點，可以在以下幾個方面做文章。

    系統解耦

    拆分業務模塊和功能模塊，使得每個模塊都做到高度內聚，然后用SOA，通過嚴格定義模塊之間的服務接口，做到模塊間的松散耦合。在一個模塊發生問題時盡可能不影響其他模塊的執行，尤其不能影響關鍵業務的執行。同時，可以對單個模塊進行橫向擴展，尤其是對關鍵的業務模塊，以確保關鍵業務一定不能受影響。需要注意的是，模塊劃分的粒度應進行權衡，過細的粒度雖然可以帶來更多的靈活性，但也會帶來編程的復雜性。

    有損服務

    根據CAP（Consistency一致性，Availability可用性，Partition Tolerance分區容忍性）理論，三者不可得兼。對于電商平臺，其中多數應用并不需要很強的一致性，因此合理的方式是用犧牲部分一致性來換取較高的可用性。有損服務（服務降級）就是一種提高系統穩定性和可用性的有效實踐。在電商系統中，要優先保證類目瀏覽、產品單頁和訂單流程能夠執行。

    數據庫減負

    我們知道數據庫是所有節點中最不容易擴展的，復雜的SQL查詢條件會導致數據庫負擔過重，此時可用增加應用計算中間服務器的方式，通過高效簡潔的SQL查詢，應用計算中間服務器一次性地從數據庫中取出最小全集的數據行，然后在內存中利用算法剔除冗余數據，以應用算法的復雜度換數據庫負擔的方式。

    炫——運籌于帷幄之中，決勝于千里之外

    炫的目標是確保業務端實時高效的調度。從日志收集和實時計算入手，通過對用戶行為數據的可視化（圖1），及時發現問題和洞察商機，調度應用系統，對用戶多樣化和個性化的需求進行智能引導。

  • 原文：https://www.cnblogs.com/chunguang/p/5892274.html

    ?

    出現問題：

  • 現有業務的沖擊

    秒殺是營銷活動中的一種，如果和其他營銷活動應用部署在同一服務器上，肯定會對現有其他活動造成沖擊，極端情況下可能導致整個電商系統服務宕機

    直接下訂單

    下單頁面是一個正常的 URL 地址，需要控制在秒殺開始前，不能下訂單，只能瀏覽對應活動商品的信息。簡單來說，需要 Disable 訂單按鈕

    頁面流量突增

    秒殺活動開始前后，會有很多用戶請求對應商品頁面，會造成后臺服務器的流量突增，同時對應的網絡帶寬增加，需要控制商品頁面的流量不會對后臺服務器、DB、Redis 等組件的造成過大的壓力

    架構設計思想

    ?

    限流

    由于活動庫存量一般都是很少，對應的只有少部分用戶才能秒殺成功。所以我們需要限制大部分用戶流量，只準少量用戶流量進入后端服務器

    削峰

    秒殺開始的那一瞬間，會有大量用戶沖擊進來，所以在開始時候會有一個瞬間流量峰值。如何把瞬間的流量峰值變得更平緩，是能否成功設計好秒殺系統的關鍵因素。實現流量削峰填谷，一般的采用緩存和 MQ 中間件來解決

    異步

    秒殺其實可以當做高并發系統來處理，在這個時候，可以考慮從業務上做兼容，將同步的業務，設計成異步處理的任務，提高網站的整體可用性

    緩存

    秒殺系統的瓶頸主要體現在下訂單、扣減庫存流程中。在這些流程中主要用到 OLTP 的數據庫，類似 MySQL、SQLServer、Oracle。由于數據庫底層采用 B+ 樹的儲存結構，對應我們隨機寫入與讀取的效率，相對較低。如果我們把部分業務邏輯遷移到內存的緩存或者 Redis 中，會極大的提高并發效率

    整體架構

  • ?

    原文：https://www.jianshu.com/p/62cce4ba2b8a

    ?

    ?

    ?

    ?

• 我們公司有這樣的一個業務場景，XXXX，我給你畫個圖，YYYY，? ?就根據這樣的一個場景以及面臨的問題。如果讓你來設計這個系統， 你會如何考慮？

總結

以上是生活随笔為你收集整理的系统设计类问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。