基于本機(jī)內(nèi)存的緩存
為了解決調(diào)用API依然需要2秒的問(wèn)題，經(jīng)過(guò)排查，其主要原因在于使用SQL獲取熱點(diǎn)新聞的過(guò)程中消耗了將近2秒的時(shí)間，于是乎，我們又想到了一個(gè)簡(jiǎn)單粗暴的解決方案，即把SQL查詢的結(jié)果直接緩存在當(dāng)前api服務(wù)器的內(nèi)存中（設(shè)置緩存有效時(shí)間為1分鐘）。后續(xù)1分鐘內(nèi)的請(qǐng)求直接讀緩存，不再花費(fèi)2秒去執(zhí)行SQL了。假如這個(gè)api每秒接收到的請(qǐng)求時(shí)100個(gè)，那么一分鐘就是6000個(gè)，也就是只有前2秒擁擠過(guò)來(lái)的請(qǐng)求會(huì)耗時(shí)2秒，后續(xù)的58秒中的所有請(qǐng)求都可以做到即使響應(yīng)，而無(wú)需再等2秒的時(shí)間。
服務(wù)端的redis
在API服務(wù)器的內(nèi)存都被緩存塞滿的時(shí)候，我們發(fā)現(xiàn)不得不另想解決方案了。最直接的想法就是我們把這些緩存都丟到一個(gè)專門的服務(wù)器上吧，把它的內(nèi)存配置的大大的。然后我們就盯上了redis。。。至于如何配置部署redis這里不解釋了，redis官方有詳細(xì)的介紹。隨后我們就用上了一臺(tái)單獨(dú)的服務(wù)器作為Redis的服務(wù)器，API服務(wù)器的內(nèi)存壓力得以解決。
持久化（Persistence）
單臺(tái)的Redis服務(wù)器一個(gè)月總有那么幾天心情不好，心情不好就罷工了，導(dǎo)致所有的緩存都丟失了（redis的數(shù)據(jù)是存儲(chǔ)在內(nèi)存的嘛）。雖然可以把Redis服務(wù)器重新上線，但是由于內(nèi)存的數(shù)據(jù)丟失，造成了緩存雪崩，API服務(wù)器和數(shù)據(jù)庫(kù)的壓力還是一下子就上來(lái)了。所以這個(gè)時(shí)候Redis的持久化功能就派上用場(chǎng)了，可以緩解一下緩存雪崩帶來(lái)的影響。redis的持久化指的是redis會(huì)把內(nèi)存的中的數(shù)據(jù)寫入到硬盤中，在redis重新啟動(dòng)的時(shí)候加載這些數(shù)據(jù)，從而最大限度的降低緩存丟失帶來(lái)的影響。
哨兵（Sentinel）和復(fù)制（Replication）
Redis服務(wù)器毫無(wú)征兆的罷工是個(gè)麻煩事。那么怎辦辦？答曰：備份一臺(tái)，你掛了它上。那么如何得知某一臺(tái)redis服務(wù)器掛了，如何切換，如何保證備份的機(jī)器是原始服務(wù)器的完整備份呢？這時(shí)候就需要Sentinel和Replication出場(chǎng)了。Sentinel可以管理多個(gè)Redis服務(wù)器，它提供了監(jiān)控，提醒以及自動(dòng)的故障轉(zhuǎn)移的功能；Replication則是負(fù)責(zé)讓一個(gè)Redis服務(wù)器可以配備多個(gè)備份的服務(wù)器。Redis也是利用這兩個(gè)功能來(lái)保證Redis的高可用的。此外，Sentinel功能則是對(duì)Redis的發(fā)布和訂閱功能的一個(gè)利用。
集群（Cluster）
單臺(tái)服務(wù)器資源的總是有上限的，CPU資源和IO資源我們可以通過(guò)主從復(fù)制，進(jìn)行讀寫分離，把一部分CPU和IO的壓力轉(zhuǎn)移到從服務(wù)器上。但是內(nèi)存資源怎么辦，主從模式做到的只是相同數(shù)據(jù)的備份，并不能橫向擴(kuò)充內(nèi)存；單臺(tái)機(jī)器的內(nèi)存也只能進(jìn)行加大處理，但是總有上限的。所以我們就需要一種解決方案，可以讓我們橫向擴(kuò)展。最終的目的既是把每臺(tái)服務(wù)器只負(fù)責(zé)其中的一部分，讓這些所有的服務(wù)器構(gòu)成一個(gè)整體，對(duì)外界的消費(fèi)者而言，這一組分布式的服務(wù)器就像是一個(gè)集中式的服務(wù)器一樣
