隨著軟體專案中的資料量不斷增加，有哪些方法可以讓我們的系統依然執行的非常的流暢，響應時間很短呢？讓我們看一下：

下面這個架構，大家一定很不陌生，大部分小專案都是這樣的架構：所有的程式碼都放在一個程式碼包中，部署在一臺伺服器上，資料庫也只有一個。

單體架構簡單，最容易實現；但當這臺伺服器出現故障的時候，則無法對外提供服務，可用性差，難以擴充套件。

當資料開始增加，SQL 執行地越來越慢；我們可以將頻繁讀取但是變化不多的資料儲存到快取中，這樣可以極大地減少資料庫的壓力，提高應用的響應速度；

常用的快取淘汰策略：先進先出、最少使用、最近最少使用等等；

常用的本地快取框架：如果使用 Spring Boot 的話，可以直接使用 @Cacheable 註解使用本地快取（預設使用 ConcurrentHashMap 實現本地快取）、EhCache、Caffeine。

當然本地快取也有很多的弊端，比如單個伺服器資源有限、快取資料無法共享、生命週期小於等於應用的生命週期等等；所以我們可以引入分散式快取，比如 Memcached 、 Redis。

因為並不是所有的資料都適合放在快取中，所以隨著資料的進一步增加，需要提高資料庫本身的效能和高可用，最簡單的方法：資料庫的讀寫分離。

當資料庫中的資料進一步增加，單臺數據庫無法支撐，可以考慮分庫分表；每一條資料根據路由策略，儲存在不同的資料庫中；

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

現有的資料分片不夠的話，就需要做資料庫的擴充，要麼需要做資料遷移，要麼會讓資料路由演算法變得更加複雜；

全量的資料查詢和統計成了一個很大的難題；

針對分庫分表後全量查詢的難題，通常我們可以引入 ES 做全量的資料檢索。

上面就是針對“資料量不斷增加”的一些解決方法，當然我們也需要結合專案實際情況進行架構設計，這是一個迭代演化的過程，避免過度設計。