隨著軟件項目中的數據量不斷增加，有哪些方法可以讓我們的系統依然運行的非常的流暢，響應時間很短呢？讓我們看一下：
01.單體架構
下面這個架構，大家一定很不陌生，大部分小項目都是這樣的架構：所有的代碼都放在一個代碼包中，部署在一臺服務器上，數據庫也只有一個。
單體架構簡單，最容易實現；但當這臺服務器出現故障的時候，則無法對外提供服務，可用性差，難以擴展。
02.本地緩存
當數據開始增加，SQL執行地越來越慢；我們可以將頻繁讀取但是變化不多的數據保存到緩存中，這樣可以極大地減少數據庫的壓力，提高應用的響應速度；
常用的緩存淘汰策略：先進先出、最少使用、最近最少使用等等；
常用的本地緩存框架：如果使用SpringBoot的話，可以直接使用@Cacheable注解使用本地緩存（默認使用ConcurrentHashMap實現本地緩存）、EhCache、Caffeine。
03.分布式緩存
當然本地緩存也有很多的弊端，比如單個服務器資源有限、緩存數據無法共享、生命周期小于等于應用的生命周期等等；所以我們可以引入分布式緩存，比如Memcached、Redis。
04.讀寫分離
因為并不是所有的數據都適合放在緩存中，所以隨著數據的進一步增加，需要提高數據庫本身的性能和高可用，最簡單的方法：數據庫的讀寫分離。
05.分庫分表
當數據庫中的數據進一步增加，單臺數據庫無法支撐，可以考慮分庫分表；每一條數據根據路由策略，存儲在不同的數據庫中；
分庫分表雖然突破了單臺數據庫的資源限制，理論上可以支撐無限增長的數據，但是也會帶來新的難題：
現有的數據分片不夠的話，就需要做數據庫的擴充，要么需要做數據遷移，要么會讓數據路由算法變得更加復雜；
全量的數據查詢和統計成了一個很大的難題；
06.分庫分表+ES
針對分庫分表后全量查詢的難題，通常我們可以引入ES做全量的數據檢索。
上面就是針對“數據量不斷增加”的一些解決方法，當然我們也需要結合項目實際情況進行架構設計，這是一個迭代演化的過程，避免過度設計。