容量越大越不壞？24萬塊硬盤故障率報告公布 這些產(chǎn)品零故障
8月5日消息，云存儲服務(wù)商Backblaze發(fā)布了最新的硬盤故障率報告，年故障率有所上升。Backblaze發(fā)布的硬盤季度統(tǒng)計數(shù)據(jù)，其中包括故障率等重要方面。這些結(jié)
大家好，我是Tom哥。
作為后端研發(fā)同學(xué)為了幾兩碎銀，沒日沒夜周旋于各種人、各種事上。
如果你要想成長的更快，就要學(xué)會歸納總結(jié)，找到規(guī)律，并且善用這些規(guī)律。
就比如工作，雖然事情很多、也很繁瑣，但如果按照性質(zhì)歸下類，我覺得可以分為兩大類：
關(guān)于業(yè)務(wù)類的內(nèi)容很大程度依賴于產(chǎn)品同學(xué)的節(jié)奏，研發(fā)更多是被動角色，我們能做的是就是多跟產(chǎn)品聊天，「實時」了解產(chǎn)品的最新動向，培養(yǎng)自己的業(yè)務(wù) sense，給自己多預(yù)留一定的buffer時間可以去做技術(shù)調(diào)研、技術(shù)儲備。
工作過一段時間同學(xué)一般都經(jīng)歷過，產(chǎn)品變化節(jié)奏很快，經(jīng)常都是倒排時間，讓研發(fā)苦不堪言。
至于技術(shù)類，相對就比較溫和的多了，不過也非常考驗研發(fā)的技術(shù)實力。
今天，我們就來聊下關(guān)于接口性能優(yōu)化有哪些技巧?
本地緩存，最大的優(yōu)點是應(yīng)用和cache是在同一個進程內(nèi)部，請求緩存非常快速，沒有過多的網(wǎng)絡(luò)開銷等，在單應(yīng)用不需要集群支持或者集群情況下各節(jié)點無需互相通知的場景下使用本地緩存較合適。缺點也是因為緩存跟應(yīng)用程序耦合，多個應(yīng)用程序無法直接的共享緩存，各應(yīng)用或集群的各節(jié)點都需要維護自己的單獨緩存，對內(nèi)存是一種浪費。
常用的本地緩存框架有 Guava、Caffeine 等，都是些單獨的jar包 ，直接導(dǎo)入到工程里即可使用。
我們可以根據(jù)自己的需要靈活選擇想要哪個框架
使用門檻比較低， 大家可以自行網(wǎng)上搜索相應(yīng)的教程，這里就不展開了。
本地緩存適用兩種場景：
注意問題：
本地緩存的使用很容易讓你的應(yīng)用服務(wù)器帶上“狀態(tài)”，而且容易受內(nèi)存大小的限制。
分布式緩存借助分布式的概念，集群化部署，獨立運維，容量無上限，雖然會有網(wǎng)絡(luò)傳輸?shù)膿p耗，但這1~2ms的延遲相比其更多優(yōu)勢完成可以忽略。
優(yōu)秀的分布式緩存系統(tǒng)有大家所熟知的 Memcached 、Redis。對比關(guān)系型數(shù)據(jù)庫和緩存存儲，其在讀和寫性能上的差距可謂天壤之別，redis單節(jié)點已經(jīng)可以做到 8W+ QPS。設(shè)計方案時盡量把讀寫壓力從數(shù)據(jù)庫轉(zhuǎn)移到緩存上，有效保護脆弱的關(guān)系型數(shù)據(jù)庫。
注意問題：
梳理業(yè)務(wù)流程，畫出時序圖，分清楚哪些是串行?哪些是并行?充分利用多核 CPU 的并行化處理能力
如下圖所示，存在上下文依賴的采用串行處理，否則采用并行處理。
JDK 的 CompletableFuture 提供了非常豐富的API，大約有50種 處理串行、并行、組合以及處理錯誤的方法，可以滿足我們的場景需求。
一個接口的 RT 響應(yīng)時間是由內(nèi)部業(yè)務(wù)邏輯的復(fù)雜度決定的，執(zhí)行的流程約簡單，那接口的耗費時間就越少。
所以，普遍做法就是將接口內(nèi)部的非核心邏輯剝離出來，異步化來執(zhí)行。
下圖是一個電商的創(chuàng)建訂單接口，創(chuàng)建訂單記錄并插入數(shù)據(jù)庫是我們的核心訴求，至于后續(xù)的用戶通知，如：給用戶發(fā)個短信等，如果失敗，并不影響主流程的完成。
我們會將這些操作從主流程中剝離出來。
業(yè)務(wù)的普遍做法就是，下單成功后，發(fā)送一條異步消息到MQ 服務(wù)器，由消費端監(jiān)聽 topic，異步消費執(zhí)行，通過發(fā)布/訂閱 模式也能支持一些新的消費任務(wù)的快速接入。
TCP 三次握手非常耗費性能，所以我們引入了 Keep-Alive 長連接，避免頻繁的創(chuàng)建、銷毀連接。
池化技術(shù)也是類似道理，將很多能重復(fù)使用的對象緩存起來，放到一個池子里，用的時候去申請一個實例對象 ，用完后再放回池子里。
池化技術(shù)的核心是資源的“預(yù)分配”和“循環(huán)使用”，常見的池化技術(shù)的使用有：線程池、內(nèi)存池、數(shù)據(jù)庫連接池、HttpClient 連接池等
連接池的幾個重要參數(shù)：最小連接數(shù)、空閑連接數(shù)、最大連接數(shù)
比如創(chuàng)建一個線程池:
new ThreadPoolExecutor(3, 15, 5, TimeUnit.MINUTES, new ArrayBlockingQueue<>(10), new ThreadFactoryBuilder().setNameFormat("data-thread-%d").build(), (r, executor) -> { if (r instanceof BaseRunnable) { ((BaseRunnable) r).rejectedExecute(); } });MySQL的底層 innodb 存儲引擎采用 B+ 樹結(jié)構(gòu)，三層結(jié)構(gòu)支持千萬級的數(shù)據(jù)存儲。
當(dāng)然，現(xiàn)在互聯(lián)網(wǎng)的用戶基數(shù)非常大，這么大的用戶量，單表通常很難支撐業(yè)務(wù)需求，將一個大表水平拆分成多張結(jié)構(gòu)一樣的物理表，可以極大緩解存儲、訪問壓力。
分庫分表也可能會帶入很多問題：
每一個問題展開都要花費很長篇幅來講解，這里主要講接口性能優(yōu)化的方案匯總，就不展開細講了。
關(guān)于分庫分表，市場受歡迎的開源框架是 sharding-jdbc，目前已經(jīng)捐贈給Apache并啟動孵化
雖然有了分庫分表，從存儲維度可以減少很大壓力，但「富不過三代」，我們還是要學(xué)會精打細算，就比如所有的數(shù)據(jù)庫操作都是通過 SQL 來執(zhí)行。
一個不好的SQL會對接口性能產(chǎn)生很大影響。
比如：
SQL 優(yōu)化的經(jīng)驗非常多，比如：
SQL 優(yōu)化的內(nèi)容非常多，這里就不展開了
有很多業(yè)務(wù)的計算邏輯比較復(fù)雜，比如頁面要展示一個網(wǎng)站的 PV、微信的拼手氣紅包等
如果在用戶訪問接口的瞬間觸發(fā)計算邏輯，而這些邏輯計算的耗時通常比較長，很難滿足用戶的實時性要求。
一般我們都是提前計算，然后將算好的數(shù)據(jù)預(yù)熱到緩存中，接口訪問時，只需要讀緩存即可
是不是一下子就快了很多。
很多業(yè)務(wù)邏輯有事務(wù)要求，針對多個表的寫操作要保證事務(wù)特性。
但事務(wù)本身又特別耗費性能，為了能盡快結(jié)束，不長時間占用數(shù)據(jù)庫連接資源，我們一般要減少事務(wù)的范圍。
將很多查詢邏輯放到事務(wù)外部處理。
另外在事務(wù)內(nèi)部，一般不要進行遠程的 RPC 接口訪問，一般占用的時間比較長。
如果數(shù)據(jù)量過大，除了采用關(guān)系型數(shù)據(jù)庫的分庫分表外，我們還可以采用 NoSQL
如：MongoDB、Hbase、Elasticsearch、TiDB
NoSQL 采用分區(qū)架構(gòu)，對數(shù)據(jù)海量存儲能較好的支持，但是事務(wù)方面可能沒那么友好。
每一個 NoSQL 框架都有自己的特色，有支持 搜索的、有列式存儲、有文檔存儲，大家可以根據(jù)自己的業(yè)務(wù)場景選擇合適的框架。
當(dāng)下的計算機CPU處理速度還是很多的，而 IO 一般是個瓶頸，如：磁盤IO、網(wǎng)絡(luò)IO。
有這么一個場景，查詢 100 個人的賬戶余額?
有兩個設(shè)計方案：
方案一：開單次查詢接口，調(diào)用方內(nèi)部循環(huán)調(diào)用 100 次
方案二：服務(wù)提供方開一個批量查詢接口，調(diào)用方只需查詢 1 次
你覺得那種方案更好?
答案不言而喻，肯定是方案二
數(shù)據(jù)庫的寫操作也是一樣道理，為了提高性能，我們一般都是采用批量更新。
并發(fā)業(yè)務(wù)，為了防止數(shù)據(jù)的并發(fā)更新對數(shù)據(jù)的正確性產(chǎn)生干擾，我們通常是采用 加鎖 ，涉及獨享資源每次只能是一個線程來處理。
問題點在于，鎖是成對出現(xiàn)的，有加鎖就是釋放鎖。
對于非競爭資源，我們沒有必要圈在鎖內(nèi)部，會嚴(yán)重影響系統(tǒng)的并發(fā)能力。
控制鎖的范圍是我們要考慮的重點。
Tom哥帶團隊對小伙伴有要求，代碼必須要有 code review 環(huán)節(jié)，review 同學(xué)代碼經(jīng)常發(fā)現(xiàn)一個問題。
當(dāng)需要一個數(shù)據(jù)時，如果沒有調(diào) RPC 接口去查，比如想用戶信息這種通用型接口
因為前面要用，肯定已經(jīng)查過。但是我們知道方法的調(diào)用都是以棧幀的形式來傳遞，隨著一個方法執(zhí)行完畢而出棧，方法內(nèi)部的局部變量也就被回收了。
后面如果又要用到這個信息，只能重新去查。
如果能定義一個Context 上下文對象，將一些中間信息存儲并傳遞下來，會大大減輕后面流程的再次查詢壓力。
如何創(chuàng)建一個集合，這還不簡單，很快我們就寫出下面代碼
List lists = Lists.newArrayList();
如果說，要往里面插入 1000000 個元素，有沒有更好的方式?
我們做個試驗：
場景一：
結(jié)果：1000000 次插入 List，花費時間：154
場景二：
結(jié)果：1000000 次插入 List，花費時間：134
如果我們預(yù)先知道集合要存儲多少元素，初始化集合時盡量指定大小，尤其是容量較大的集合。
ArrayList 初始大小是 10，超過閾值會按 1.5 倍大小擴容，涉及老集合到新集合的數(shù)據(jù)拷貝，浪費性能。
避免一次從 DB 中查詢大量的數(shù)據(jù)到內(nèi)存中，可能會導(dǎo)致內(nèi)存不足，建議采用分批、分頁查詢
本文鏈接：http://m.www897cc.com/showinfo-26-65870-0.html接口性能優(yōu)化的 15 個技巧
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號