作者 l 會點代碼的大叔(CodeDaShu) 随着軟體項目中的資料量不斷增加，有哪些方法可以讓我們的系統依然運作的非常的流暢，響應時間很短呢？讓我們看一下： 01
單體架構
下面這個架構，大家一定很不陌生，大部分小項目都是這樣的架構：所有的代碼都放在一個代碼包中，部署在一台伺服器上，資料庫也隻有一個。
單體架構簡單，最容易實作；但當這台伺服器出現故障的時候，則無法對外提供服務，可用性差，難以擴充。 02
本地緩存
當資料開始增加，SQL 執行地越來越慢；我們可以将頻繁讀取但是變化不多的資料儲存到緩存中，這樣可以極大地減少資料庫的壓力，提高應用的響應速度； 常用的緩存淘汰政策：先進先出、最少使用、最近最少使用等等； 常用的本地緩存架構：如果使用 Spring Boot 的話，可以直接使用 @Cacheable 注解使用本地緩存(預設使用 ConcurrentHashMap 實作本地緩存)、EhCache、Caffeine。
03 分布式緩存 當然本地緩存也有很多的弊端，比如單個伺服器資源有限、緩存資料無法共享、生命周期小于等于應用的生命周期等等；是以我們可以引入分布式緩存，比如 Memcached 、 Redis。
04
讀寫分離
因為并不是所有的資料都适合放在緩存中，是以随着資料的進一步增加，需要提高資料庫本身的性能和高可用，最簡單的方法：資料庫的讀寫分離。
05
分庫分表
當資料庫中的資料進一步增加，單台資料庫無法支撐，可以考慮分庫分表；每一條資料根據路由政策，存儲在不同的資料庫中；
分庫分表雖然突破了單台資料庫的資源限制，理論上可以支撐無限增長的資料，但是也會帶來新的難題：
現有的資料分片不夠的話，就需要做資料庫的擴充，要麼需要做資料遷移，要麼會讓資料路由算法變得更加複雜；
全量的資料查詢和統計成了一個很大的難題；
06
分庫分表 + ES
針對分庫分表後全量查詢的難題，通常我們可以引入 ES 做全量的資料檢索。
上面就是針對“資料量不斷增加”的一些解決方法，當然我們也需要結合項目實際情況進行架構設計，這是一個疊代演化的過程，避免過度設計。
往期精選：
一篇文章告訴你什麼是Deno！
分布式事務之TCC服務設計和實作注意事項
手把手教你在 SpringBoot 中防禦 CSRF 攻擊！