導航:首頁 > 配伺服器 > 什麼叫伺服器高並發

什麼叫伺服器高並發

發布時間:2024-10-18 10:41:01

java「高並發」是什麼意思

1、在java中,高並發屬於一種編程術語,意思就是有很多用戶在訪問,導致系統數據不正確、糗事數據的現象。並發就是可以使用多個線程或進程,同時處理不同的操作。

❷ 高並發是什麼意思

高並發:在極短單位時間內,極多個請求同時發起到伺服器。

❸ 高並發,你真的理解透徹了嗎


高並發,幾乎是每個程序員都想擁有的經驗。原因很簡單:隨著流量變大,會遇到各種各樣的技術問題,比如介面響應超時、CPU load升高、GC頻繁、死鎖、大數據量存儲等等,這些問題能推動我們在技術深度上不斷精進。

在過往的面試中,如果候選人做過高並發的項目,我通常會讓對方談談對於高並發的理解,但是能系統性地回答好此問題的人並不多。

大概分成這樣幾類:

1、對數據化的指標沒有概念 :不清楚選擇什麼樣的指標來衡量高並發系統?分不清並發量和QPS,甚至不知道自己系統的總用戶量、活躍用戶量,平峰和高峰時的QPS和TPS等關鍵數據。

3、理解片面,把高並發設計等同於性能優化 :大談並發編程、多級緩存、非同步化、水平擴容,卻忽視高可用設計、服務治理和運維保障。

4、掌握大方案,卻忽視最基本的東西 :能講清楚垂直分層、水平分區、緩存等大思路,卻沒意識去分析數據結構是否合理,演算法是否高效,沒想過從最根本的IO和計算兩個維度去做細節優化。

這篇文章,我想結合自己的高並發項目經驗,系統性地總結下高並發需要掌握的知識和實踐思路,希望對你有所幫助。內容分成以下3個部分:


高並發意味著大流量,需要運用技術手段抵抗流量的沖擊,這些手段好比操作流量,能讓流量更平穩地被系統所處理,帶給用戶更好的體驗。

我們常見的高並發場景有:淘寶的雙11、春運時的搶票、微博大V的熱點新聞等。除了這些典型事情,每秒幾十萬請求的秒殺系統、每天千萬級的訂單系統、每天億級日活的信息流系統等,都可以歸為高並發。

很顯然,上面談到的高並發場景,並發量各不相同, 那到底多大並發才算高並發呢?

1、不能只看數字,要看具體的業務場景。不能說10W QPS的秒殺是高並發,而1W QPS的信息流就不是高並發。信息流場景涉及復雜的推薦模型和各種人工策略,它的業務邏輯可能比秒殺場景復雜10倍不止。因此,不在同一個維度,沒有任何比較意義。

2、業務都是從0到1做起來的,並發量和QPS只是參考指標,最重要的是:在業務量逐漸變成原來的10倍、100倍的過程中,你是否用到了高並發的處理方法去演進你的系統,從架構設計、編碼實現、甚至產品方案等維度去預防和解決高並發引起的問題?而不是一味的升級硬體、加機器做水平擴展。

此外,各個高並發場景的業務特點完全不同:有讀多寫少的信息流場景、有讀多寫多的交易場景, 那是否有通用的技術方案解決不同場景的高並發問題呢?

我覺得大的思路可以借鑒,別人的方案也可以參考,但是真正落地過程中,細節上還會有無數的坑。另外,由於軟硬體環境、技術棧、以及產品邏輯都沒法做到完全一致,這些都會導致同樣的業務場景,就算用相同的技術方案也會面臨不同的問題,這些坑還得一個個趟。

因此,這篇文章我會將重點放在基礎知識、通用思路、和我曾經實踐過的有效經驗上,希望讓你對高並發有更深的理解。


先搞清楚高並發系統設計的目標,在此基礎上再討論設計方案和實踐經驗才有意義和針對性。

高並發絕不意味著只追求高性能,這是很多人片面的理解。從宏觀角度看,高並發系統設計的目標有三個:高性能、高可用,以及高可擴展。

1、高性能:性能體現了系統的並行處理能力,在有限的硬體投入下,提高性能意味著節省成本。同時,性能也反映了用戶體驗,響應時間分別是100毫秒和1秒,給用戶的感受是完全不同的。

2、高可用:表示系統可以正常服務的時間。一個全年不停機、無故障;另一個隔三差五齣線上事故、宕機,用戶肯定選擇前者。另外,如果系統只能做到90%可用,也會大大拖累業務。

3、高擴展:表示系統的擴展能力,流量高峰時能否在短時間內完成擴容,更平穩地承接峰值流量,比如雙11活動、明星離婚等熱點事件。

這3個目標是需要通盤考慮的,因為它們互相關聯、甚至也會相互影響。

比如說:考慮系統的擴展能力,你會將服務設計成無狀態的,這種集群設計保證了高擴展性,其實也間接提升了系統的性能和可用性。

再比如說:為了保證可用性,通常會對服務介面進行超時設置,以防大量線程阻塞在慢請求上造成系統雪崩,那超時時間設置成多少合理呢?一般,我們會參考依賴服務的性能表現進行設置。

再從微觀角度來看,高性能、高可用和高擴展又有哪些具體的指標來衡量?為什麼會選擇這些指標呢?

2.2.1 性能指標

通過性能指標可以度量目前存在的性能問題,同時作為性能優化的評估依據。一般來說,會採用一段時間內的介面響應時間作為指標。

1、平均響應時間:最常用,但是缺陷很明顯,對於慢請求不敏感。比如1萬次請求,其中9900次是1ms,100次是100ms,則平均響應時間為1.99ms,雖然平均耗時僅增加了0.99ms,但是1%請求的響應時間已經增加了100倍。

2、TP90、TP99等分位值:將響應時間按照從小到大排序,TP90表示排在第90分位的響應時間, 分位值越大,對慢請求越敏感。

3、吞吐量:和響應時間呈反比,比如響應時間是1ms,則吞吐量為每秒1000次。

通常,設定性能目標時會兼顧吞吐量和響應時間,比如這樣表述:在每秒1萬次請求下,AVG控制在50ms以下,TP99控制在100ms以下。對於高並發系統,AVG和TP分位值必須同時要考慮。

另外,從用戶體驗角度來看,200毫秒被認為是第一個分界點,用戶感覺不到延遲,1秒是第二個分界點,用戶能感受到延遲,但是可以接受。

因此,對於一個 健康 的高並發系統,TP99應該控制在200毫秒以內,TP999或者TP9999應該控制在1秒以內。

2.2.2 可用性指標

高可用性是指系統具有較高的無故障運行能力,可用性 = 正常運行時間 / 系統總運行時間,一般使用幾個9來描述系統的可用性。

對於高並發系統來說,最基本的要求是:保證3個9或者4個9。原因很簡單,如果你只能做到2個9,意味著有1%的故障時間,像一些大公司每年動輒千億以上的GMV或者收入,1%就是10億級別的業務影響。

2.2.3 可擴展性指標

面對突發流量,不可能臨時改造架構,最快的方式就是增加機器來線性提高系統的處理能力。

對於業務集群或者基礎組件來說,擴展性 = 性能提升比例 / 機器增加比例,理想的擴展能力是:資源增加幾倍,性能提升幾倍。通常來說,擴展能力要維持在70%以上。

但是從高並發系統的整體架構角度來看,擴展的目標不僅僅是把服務設計成無狀態就行了,因為當流量增加10倍,業務服務可以快速擴容10倍,但是資料庫可能就成為了新的瓶頸。

像MySQL這種有狀態的存儲服務通常是擴展的技術難點,如果架構上沒提前做好規劃(垂直和水平拆分),就會涉及到大量數據的遷移。

因此,高擴展性需要考慮:服務集群、資料庫、緩存和消息隊列等中間件、負載均衡、帶寬、依賴的第三方等,當並發達到某一個量級後,上述每個因素都可能成為擴展的瓶頸點。

了解了高並發設計的3大目標後,再系統性總結下高並發的設計方案,會從以下兩部分展開:先總結下通用的設計方法,然後再圍繞高性能、高可用、高擴展分別給出具體的實踐方案。

通用的設計方法主要是從「縱向」和「橫向」兩個維度出發,俗稱高並發處理的兩板斧:縱向擴展和橫向擴展。

3.1.1 縱向擴展(scale-up)

它的目標是提升單機的處理能力,方案又包括:

1、提升單機的硬體性能:通過增加內存、 CPU核數、存儲容量、或者將磁碟 升級成SSD 等堆硬體的方式來提升。

2、提升單機的軟體性能:使用緩存減少IO次數,使用並發或者非同步的方式增加吞吐量。

3.1.2 橫向擴展(scale-out)

因為單機性能總會存在極限,所以最終還需要引入橫向擴展,通過集群部署以進一步提高並發處理能力,又包括以下2個方向:

1、做好分層架構:這是橫向擴展的提前,因為高並發系統往往業務復雜,通過分層處理可以簡化復雜問題,更容易做到橫向擴展。

上面這種圖是互聯網最常見的分層架構,當然真實的高並發系統架構會在此基礎上進一步完善。比如會做動靜分離並引入CDN,反向代理層可以是LVS+Nginx,Web層可以是統一的API網關,業務服務層可進一步按垂直業務做微服務化,存儲層可以是各種異構資料庫。

2、各層進行水平擴展:無狀態水平擴容,有狀態做分片路由。業務集群通常能設計成無狀態的,而資料庫和緩存往往是有狀態的,因此需要設計分區鍵做好存儲分片,當然也可以通過主從同步、讀寫分離的方案提升讀性能。

下面再結合我的個人經驗,針對高性能、高可用、高擴展3個方面,總結下可落地的實踐方案。

3.2.1 高性能的實踐方案

1、集群部署,通過負載均衡減輕單機壓力。

2、多級緩存,包括靜態數據使用CDN、本地緩存、分布式緩存等,以及對緩存場景中的熱點key、緩存穿透、緩存並發、數據一致性等問題的處理。

3、分庫分表和索引優化,以及藉助搜索引擎解決復雜查詢問題。

4、考慮NoSQL資料庫的使用,比如HBase、TiDB等,但是團隊必須熟悉這些組件,且有較強的運維能力。

5、非同步化,將次要流程通過多線程、MQ、甚至延時任務進行非同步處理。

6、限流,需要先考慮業務是否允許限流(比如秒殺場景是允許的),包括前端限流、Nginx接入層的限流、服務端的限流。

7、對流量進行 削峰填谷 ,通過 MQ承接流量。

8、並發處理,通過多線程將串列邏輯並行化。

9、預計算,比如搶紅包場景,可以提前計算好紅包金額緩存起來,發紅包時直接使用即可。

10、 緩存預熱 ,通過非同步 任務 提前 預熱數據到本地緩存或者分布式緩存中。

11、減少IO次數,比如資料庫和緩存的批量讀寫、RPC的批量介面支持、或者通過冗餘數據的方式幹掉RPC調用。

12、減少IO時的數據包大小,包括採用輕量級的通信協議、合適的數據結構、去掉介面中的多餘欄位、減少緩存key的大小、壓縮緩存value等。

13、程序邏輯優化,比如將大概率阻斷執行流程的判斷邏輯前置、For循環的計算邏輯優化,或者採用更高效的演算法。

14、各種池化技術的使用和池大小的設置,包括HTTP請求池、線程池(考慮CPU密集型還是IO密集型設置核心參數)、資料庫和Redis連接池等。

15、JVM優化,包括新生代和老年代的大小、GC演算法的選擇等,盡可能減少GC頻率和耗時。

16、鎖選擇,讀多寫少的場景用樂觀鎖,或者考慮通過分段鎖的方式減少鎖沖突。

上述方案無外乎從計算和 IO 兩個維度考慮所有可能的優化點,需要有配套的監控系統實時了解當前的性能表現,並支撐你進行性能瓶頸分析,然後再遵循二八原則,抓主要矛盾進行優化。

3.2.2 高可用的實踐方案

1、對等節點的故障轉移,Nginx和服務治理框架均支持一個節點失敗後訪問另一個節點。

2、非對等節點的故障轉移,通過心跳檢測並實施主備切換(比如redis的哨兵模式或者集群模式、MySQL的主從切換等)。

3、介面層面的超時設置、重試策略和冪等設計。

4、降級處理:保證核心服務,犧牲非核心服務,必要時進行熔斷;或者核心鏈路出問題時,有備選鏈路。

5、限流處理:對超過系統處理能力的請求直接拒絕或者返回錯誤碼。

6、MQ場景的消息可靠性保證,包括procer端的重試機制、broker側的持久化、consumer端的ack機制等。

7、灰度發布,能支持按機器維度進行小流量部署,觀察系統日誌和業務指標,等運行平穩後再推全量。

8、監控報警:全方位的監控體系,包括最基礎的CPU、內存、磁碟、網路的監控,以及Web伺服器、JVM、資料庫、各類中間件的監控和業務指標的監控。

9、災備演練:類似當前的「混沌工程」,對系統進行一些破壞性手段,觀察局部故障是否會引起可用性問題。

高可用的方案主要從冗餘、取捨、系統運維3個方向考慮,同時需要有配套的值班機制和故障處理流程,當出現線上問題時,可及時跟進處理。

3.2.3 高擴展的實踐方案

1、合理的分層架構:比如上面談到的互聯網最常見的分層架構,另外還能進一步按照數據訪問層、業務邏輯層對微服務做更細粒度的分層(但是需要評估性能,會存在網路多一跳的情況)。

2、存儲層的拆分:按照業務維度做垂直拆分、按照數據特徵維度進一步做水平拆分(分庫分表)。

3、業務層的拆分:最常見的是按照業務維度拆(比如電商場景的商品服務、訂單服務等),也可以按照核心介面和非核心介面拆,還可以按照請求源拆(比如To C和To B,APP和H5 )。


高並發確實是一個復雜且系統性的問題,由於篇幅有限,諸如分布式Trace、全鏈路壓測、柔性事務都是要考慮的技術點。另外,如果業務場景不同,高並發的落地方案也會存在差異,但是總體的設計思路和可借鑒的方案基本類似。

高並發設計同樣要秉承架構設計的3個原則:簡單、合適和演進。"過早的優化是萬惡之源",不能脫離業務的實際情況,更不要過度設計,合適的方案就是最完美的。

作者簡介:985碩士,前亞馬遜工程師,現大廠技術管理者。

❹ 一般互聯網公司 如何進行高並發的架構

一、什麼是高並發
高並發(High Concurrency)是互聯網分布式系統架構設計中必須考慮的因素之一,它通常是指,通過設計保證系統能夠同時並行處理很多請求。
高並發相關常用的一些指標有響應時間(Response Time),吞吐量(Throughput),每秒查詢率QPS(Query Per Second),並發用戶數等。
響應時間:系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms,這個200ms就是系統的響應時間。
吞吐量:單位時間內處理的請求數量。
QPS:每秒響應請求數。在互聯網領域,這個指標和吞吐量區分的沒有這么明顯。
並發用戶數:同時承載正常使用系統功能的用戶數量。例如一個即時通訊系統,同時在線量一定程度上代表了系統的並發用戶數。
二、如何提升系統的並發能力
互聯網分布式架構設計,提高系統並發能力的方式,方法論上主要有兩種:垂直擴展(Scale Up)與水平擴展(Scale Out)。
垂直擴展:提升單機處理能力。垂直擴展的方式又有兩種:
(1)增強單機硬體性能,例如:增加CPU核數如32核,升級更好的網卡如萬兆,升級更好的硬碟如SSD,擴充硬碟容量如2T,擴充系統內存如128G;
(2)提升單機架構性能,例如:使用Cache來減少IO次數,使用非同步來增加單服務吞吐量,使用無鎖數據結構來減少響應時間;
在互聯網業務發展非常迅猛的早期,如果預算不是問題,強烈建議使用「增強單機硬體性能」的方式提升系統並發能力,因為這個階段,公司的戰略往往是發展業務搶時間,而「增強單機硬體性能」往往是最快的方法。
不管是提升單機硬體性能,還是提升單機架構性能,都有一個致命的不足:單機性能總是有極限的。所以互聯網分布式架構設計高並發終極解決方案還是水平擴展。
水平擴展:只要增加伺服器數量,就能線性擴充系統性能。水平擴展對系統架構設計是有要求的,如何在架構各層進行可水平擴展的設計,以及互聯網公司架構各層常見的水平擴展實踐,是本文重點討論的內容。
三、常見的互聯網分層架構
常見互聯網分布式架構如上,分為:
(1)客戶端層:典型調用方是瀏覽器browser或者手機應用APP
(2)反向代理層:系統入口,反向代理
(3)站點應用層:實現核心應用邏輯,返回html或者json
(4)服務層:如果實現了服務化,就有這一層
(5)數據-緩存層:緩存加速訪問存儲
(6)數據-資料庫層:資料庫固化數據存儲
整個系統各層次的水平擴展,又分別是如何實施的呢?
四、分層水平擴展架構實踐
反向代理層的水平擴展
反向代理層的水平擴展,是通過「DNS輪詢」實現的:dns-server對於一個域名配置了多個解析ip,每次DNS解析請求來訪問dns-server,會輪詢返回這些ip。
當nginx成為瓶頸的時候,只要增加伺服器數量,新增nginx服務的部署,增加一個外網ip,就能擴展反向代理層的性能,做到理論上的無限高並發。
站點層的水平擴展
站點層的水平擴展,是通過「nginx」實現的。通過修改nginx.conf,可以設置多個web後端。
當web後端成為瓶頸的時候,只要增加伺服器數量,新增web服務的部署,在nginx配置中配置上新的web後端,就能擴展站點層的性能,做到理論上的無限高並發。
服務層的水平擴展
服務層的水平擴展,是通過「服務連接池」實現的。
站點層通過RPC-client調用下游的服務層RPC-server時,RPC-client中的連接池會建立與下游服務多個連接,當服務成為瓶頸的時候,只要增加伺服器數量,新增服務部署,在RPC-client處建立新的下游服務連接,就能擴展服務層性能,做到理論上的無限高並發。如果需要優雅的進行服務層自動擴容,這里可能需要配置中心裡服務自動發現功能的支持。
數據層的水平擴展
在數據量很大的情況下,數據層(緩存,資料庫)涉及數據的水平擴展,將原本存儲在一台伺服器上的數據(緩存,資料庫)水平拆分到不同伺服器上去,以達到擴充系統性能的目的。
互聯網數據層常見的水平拆分方式有這么幾種,以資料庫為例:
按照范圍水平拆分
每一個數據服務,存儲一定范圍的數據,上圖為例:
這個方案的好處是:
(1)規則簡單,service只需判斷一下uid范圍就能路由到對應的存儲服務;
(2)數據均衡性較好;
(3)比較容易擴展,可以隨時加一個uid[2kw,3kw]的數據服務;
不足是:
(1)請求的負載不一定均衡,一般來說,新注冊的用戶會比老用戶更活躍,大range的服務請求壓力會更大;
按照哈希水平拆分
每一個資料庫,存儲某個key值hash後的部分數據,上圖為例:
這個方案的好處是:
(1)規則簡單,service只需對uid進行hash能路由到對應的存儲服務;
(2)數據均衡性較好;
(3)請求均勻性較好;
不足是:
(1)不容易擴展,擴展一個數據服務,hash方法改變時候,可能需要進行數據遷移;
這里需要注意的是,通過水平拆分來擴充系統性能,與主從同步讀寫分離來擴充資料庫性能的方式有本質的不同。
通過水平拆分擴展資料庫性能:
(1)每個伺服器上存儲的數據量是總量的1/n,所以單機的性能也會有提升;
(2)n個伺服器上的數據沒有交集,那個伺服器上數據的並集是數據的全集;
(3)數據水平拆分到了n個伺服器上,理論上讀性能擴充了n倍,寫性能也擴充了n倍(其實遠不止n倍,因為單機的數據量變為了原來的1/n);
通過主從同步讀寫分離擴展資料庫性能:
(1)每個伺服器上存儲的數據量是和總量相同;
(2)n個伺服器上的數據都一樣,都是全集;
(3)理論上讀性能擴充了n倍,寫仍然是單點,寫性能不變;
緩存層的水平拆分和資料庫層的水平拆分類似,也是以范圍拆分和哈希拆分的方式居多,就不再展開。
五、總結
高並發(High Concurrency)是互聯網分布式系統架構設計中必須考慮的因素之一,它通常是指,通過設計保證系統能夠同時並行處理很多請求。
提高系統並發能力的方式,方法論上主要有兩種:垂直擴展(Scale Up)與水平擴展(Scale Out)。前者垂直擴展可以通過提升單機硬體性能,或者提升單機架構性能,來提高並發性,但單機性能總是有極限的,互聯網分布式架構設計高並發終極解決方案還是後者:水平擴展。
互聯網分層架構中,各層次水平擴展的實踐又有所不同:
(1)反向代理層可以通過「DNS輪詢」的方式來進行水平擴展;
(2)站點層可以通過nginx來進行水平擴展;
(3)服務層可以通過服務連接池來進行水平擴展;
(4)資料庫可以按照數據范圍,或者數據哈希的方式來進行水平擴展;
各層實施水平擴展後,能夠通過增加伺服器數量的方式來提升系統的性能,做到理論上的性能無限。

❺ qps多少才算高並發

QPS多少才算高並發,一般來說,這並沒有固定的標准,因為高並發取決於多種因素,如伺服器硬體性能、應用特性、網路帶寬等。以下是對QPS及高並發的

1. QPS的含義:QPS,即每秒查詢率,是評估系統性能的一個重要指標。它表示伺服器在每秒鍾內處理多少次查詢或請求的能力。這個指標與系統的並發處理能力密切相關。

2.高並發的相對性:高並發是一個相對的概念。對於小型應用或共享主機環境,QPS達到幾百可能就已經算是高並發。但對於經過優化、專門處理高流量的伺服器或大型電商平台來說,QPS數千甚至數萬可能才是常態。因此,判斷QPS是否算高並發需要結合具體的業務場景和伺服器承受能力。

3.硬體和應用因素的影響:伺服器的硬體配置以及應用的特性都會影響QPS的承受能力。在硬體性能優越且應用經過優化的情況下,系統可以處理更高的QPS。

4.高並發的挑戰:當QPS較高時,系統可能會面臨性能瓶頸、資源競爭和延遲增加等問題。這時需要對系統進行優化,包括代碼優化、緩存策略、負載均衡等,以提高系統的並發處理能力。

總之,判斷QPS是否算高並發需要結合具體場景和系統的實際情況。一般來說,QPS達到數千甚至更高時,可能需要關注並處理高並發帶來的挑戰。為了提高系統的並發能力,除了優化硬體外,還需要對軟體和應用進行相應的優化。

❻ 一直在說的高並發,多少qps才算高並發

高並發並沒有明確的QPS數值標准,通常認為QPS達到上千甚至上萬時即被認為是高並發。

關於高並發中QPS的具體數值,實際上並沒有一個固定的標准,因為它受到伺服器硬體、軟體架構、網路環境等多種因素的影響。一般來說,當QPS達到較高的數值,如上千甚至上萬時,就可以被認為是高並發場景。在這個級別,系統的性能、穩定性和擴展性面臨著較大的挑戰。

在高並發環境下,伺服器需要處理大量的並發請求。當QPS增大時,伺服器承受的負載也隨之增加,可能會引發一系列問題,如延遲增加、系統崩潰等。因此,對於高並發系統,除了硬體設備的升級,還需要優化軟體架構、提升代碼效率、合理使用緩存技術等手段來應對。

在實際應用中,判斷一個系統是否為高並發系統,除了關注QPS數值,還需要考慮系統的響應時間、並發用戶數、系統穩定性等指標。只有在這些指標都達到較高的水平時,才能真正滿足高並發場景的需求。另外,對於不同的應用場景,對高並發的定義也會有所不同。例如,一些實時性要求較高的系統,如在線支付、實時通訊等,對高並發的處理能力要求更為嚴格。

總之,高並發是一個相對的概念,需要根據具體的場景和需求來判斷。而對於高並發系統的建設,需要綜合考慮硬體、軟體、網路等多方面的因素,以確保系統的性能、穩定性和擴展性。

閱讀全文

與什麼叫伺服器高並發相關的資料

熱點內容
必修一數學PDF 瀏覽:775
javascriptphpjsp 瀏覽:811
深圳一程序員退房完整版 瀏覽:294
後台管理app哪個好 瀏覽:766
加密鎖無模塊什麼意思 瀏覽:22
加密國度英文 瀏覽:20
科沃斯用了app怎麼使用按鍵 瀏覽:663
爬蟲編譯器價格 瀏覽:885
支付寶視頻app會員自動扣費怎麼關 瀏覽:230
單片機和wifi模塊 瀏覽:725
python倒序二進制代碼 瀏覽:362
廣東程序員離職 瀏覽:586
golang核心編程 瀏覽:170
中小學計演算法則 瀏覽:85
無職轉生哪個app能看 瀏覽:580
夏夢迪在哪個app 瀏覽:107
c編譯軟體cl 瀏覽:933
逗比的程序員頭像 瀏覽:984
單片機原理作業答案 瀏覽:230
文件夾的東西怎麼能轉成文檔 瀏覽:968