隨著軟件項目中的數(shù)據(jù)量不斷增加，有哪些方法可以讓我們的系統(tǒng)依然運行的非常的流暢，響應(yīng)時間很短呢？讓我們看一下：

下面這個架構(gòu)，大家一定很不陌生，大部分小項目都是這樣的架構(gòu)：所有的代碼都放在一個代碼包中，部署在一臺服務(wù)器上，數(shù)據(jù)庫也只有一個。

單體架構(gòu)簡單，最容易實現(xiàn)；但當(dāng)這臺服務(wù)器出現(xiàn)故障的時候，則無法對外提供服務(wù)，可用性差，難以擴(kuò)展。

當(dāng)數(shù)據(jù)開始增加，SQL 執(zhí)行地越來越慢；我們可以將頻繁讀取但是變化不多的數(shù)據(jù)保存到緩存中，這樣可以極大地減少數(shù)據(jù)庫的壓力，提高應(yīng)用的響應(yīng)速度；

常用的緩存淘汰策略：先進(jìn)先出、最少使用、最近最少使用等等；

常用的本地緩存框架：如果使用 Spring Boot 的話，可以直接使用 @Cacheable 注解使用本地緩存（默認(rèn)使用 ConcurrentHashMap 實現(xiàn)本地緩存）、EhCache、Caffeine。

當(dāng)然本地緩存也有很多的弊端，比如單個服務(wù)器資源有限、緩存數(shù)據(jù)無法共享、生命周期小于等于應(yīng)用的生命周期等等；所以我們可以引入分布式緩存，比如 Memcached 、 Redis。

因為并不是所有的數(shù)據(jù)都適合放在緩存中，所以隨著數(shù)據(jù)的進(jìn)一步增加，需要提高數(shù)據(jù)庫本身的性能和高可用，最簡單的方法：數(shù)據(jù)庫的讀寫分離。

當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)一步增加，單臺數(shù)據(jù)庫無法支撐，可以考慮分庫分表；每一條數(shù)據(jù)根據(jù)路由策略，存儲在不同的數(shù)據(jù)庫中；

分庫分表雖然突破了單臺數(shù)據(jù)庫的資源限制，理論上可以支撐無限增長的數(shù)據(jù)，但是也會帶來新的難題：

現(xiàn)有的數(shù)據(jù)分片不夠的話，就需要做數(shù)據(jù)庫的擴(kuò)充，要么需要做數(shù)據(jù)遷移，要么會讓數(shù)據(jù)路由算法變得更加復(fù)雜；

全量的數(shù)據(jù)查詢和統(tǒng)計成了一個很大的難題；

針對分庫分表后全量查詢的難題，通常我們可以引入 ES 做全量的數(shù)據(jù)檢索。

上面就是針對“數(shù)據(jù)量不斷增加”的一些解決方法，當(dāng)然我們也需要結(jié)合項目實際情況進(jìn)行架構(gòu)設(shè)計，這是一個迭代演化的過程，避免過度設(shè)計。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝