軟件項目隨著數(shù)據(jù)量的不斷增加,有什么優(yōu)化方案么?
隨著軟件項目中的數(shù)據(jù)量不斷增加,有哪些方法可以讓我們的系統(tǒng)依然運行的非常的流暢,響應(yīng)時間很短呢?讓我們看一下:
單體架構(gòu)
下面這個架構(gòu),大家一定很不陌生,大部分小項目都是這樣的架構(gòu):所有的代碼都放在一個代碼包中,部署在一臺服務(wù)器上,數(shù)據(jù)庫也只有一個。
單體架構(gòu)簡單,最容易實現(xiàn);但當這臺服務(wù)器出現(xiàn)故障的時候,則無法對外提供服務(wù),可用性差,難以擴展。
本地緩存
當數(shù)據(jù)開始增加,SQL 執(zhí)行地越來越慢;我們可以將頻繁讀取但是變化不多的數(shù)據(jù)保存到緩存中,這樣可以極大地減少數(shù)據(jù)庫的壓力,提高應(yīng)用的響應(yīng)速度;
常用的緩存淘汰策略:先進先出、最少使用、最近最少使用等等;
常用的本地緩存框架:如果使用 Spring Boot 的話,可以直接使用 @Cacheable 注解使用本地緩存(默認使用 ConcurrentHashMap 實現(xiàn)本地緩存)、EhCache、Caffeine。
分布式緩存
當然本地緩存也有很多的弊端,比如單個服務(wù)器資源有限、緩存數(shù)據(jù)無法共享、生命周期小于等于應(yīng)用的生命周期等等;所以我們可以引入分布式緩存,比如 Memcached 、 Redis。
讀寫分離
因為并不是所有的數(shù)據(jù)都適合放在緩存中,所以隨著數(shù)據(jù)的進一步增加,需要提高數(shù)據(jù)庫本身的性能和高可用,最簡單的方法:數(shù)據(jù)庫的讀寫分離。
分庫分表
當數(shù)據(jù)庫中的數(shù)據(jù)進一步增加,單臺數(shù)據(jù)庫無法支撐,可以考慮分庫分表;每一條數(shù)據(jù)根據(jù)路由策略,存儲在不同的數(shù)據(jù)庫中;
分庫分表雖然突破了單臺數(shù)據(jù)庫的資源限制,理論上可以支撐無限增長的數(shù)據(jù),但是也會帶來新的難題:
現(xiàn)有的數(shù)據(jù)分片不夠的話,就需要做數(shù)據(jù)庫的擴充,要么需要做數(shù)據(jù)遷移,要么會讓數(shù)據(jù)路由算法變得更加復(fù)雜;
全量的數(shù)據(jù)查詢和統(tǒng)計成了一個很大的難題;
分庫分表 + ES
針對分庫分表后全量查詢的難題,通常我們可以引入 ES 做全量的數(shù)據(jù)檢索。
上面就是針對“數(shù)據(jù)量不斷增加”的一些解決方法,當然我們也需要結(jié)合項目實際情況進行架構(gòu)設(shè)計,這是一個迭代演化的過程,避免過度設(shè)計。
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長按關(guān)注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!