BASE理論之思考
一、什麼是BASE理論？
BASE理論是對CAP中一致性和可用性權衡的結果，它的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。
BASE理論包含如下三個元素:
- BA:基本可用；
- S:軟狀態，狀態可以在一段時間內不同步；
- E:最終一致性，在一定的時間窗口內，最終數據達成一致即可。
1.什麼是基本可用？
舉例說明:
以曾經做過的OJ系統為例，OJ系統一般宕機的原因，主要是很多學員在相同的某個時間段統一提交。那麼什麼時候大多學員會統一提交呢？
一般刷題的時候，時間不確定，有的人喜歡上午刷題，有的人喜歡晚上刷題。基本上OJ是能夠承載著不確定時間的提交。問題提到大多學員會在什麼時候統一提交，答案是考試，考試有一定的時間規定，例如120分鐘或150分鐘等，超過時間規定範圍視為放棄考試，一般考試會提交10分鐘內交卷，而這個10分鐘承載著大量的學員提交，而這個大量提交不亞於電商秒殺商品。大量的學員提交，會造成系統一度假死狀態，即不能正常對外提供服務，通常我們的做法是彈性伸縮，所謂彈性伸縮就是每到考試的時候，伺服器會自動根據學員提交的情況來決定是否創建更多的實例，通過創建更多的實例來平衡服務壓力。但有些時候並不是創建更多的實例就能應對的，例如12306搶票，全國人民搶票回家，針對這樣的場景，不僅僅是加機器來橫向擴容保證服務可用，還得服務將降級處理，所謂服務降級分為兩個層面，一個是延遲服務，另一個是暫停目前用不到的服務把資源給優先順序高的服務，以此來達到服務基本可用的目的。
2.什麼是軟狀態？
舉例說明:
以批量導入大量的歷史數據為例，成千上萬的Excel文件，裡面裝有上億的數據，針對這些數據，系統使用人員在導入數據的過程中，總希望導入一個能夠馬上得到實時回饋(成功了多少，失敗了多少，失敗的原因是什麼)，但從實際中來看，幾百萬條數據插入到資料庫，肯定會消耗資料庫資源，一定程度上降低資料庫性能，使得其它應用服務受到一定程度上的影響。以我上家公司的解決辦法就是延遲插入，首先用戶在導入數據的時候，我們會馬上提示，數據正在導入中，導入成功後會給該用戶發送手機簡訊或者是郵件，但其實數據正在導入中並沒有馬上導入，而是進入到一個數據導入任務隊列中，排隊執行，先進先出，當執行到該任務時，數據任務導入隊列會集中多個伺服器進行數據導入，分批次導入，這樣一來效率高的多。當然了，這樣一來，用戶不能馬上看到數據，但這在一定程度上提高了系統整體可用性，避免因為數據導入而影響對外的正常服務，正好符合軟狀態，即數據狀態可以在一段時間內不同步。
3.什麼是最終一致性？
舉例說明:
以很久以前我寫的一個部落格爬蟲為例，部落格爬蟲分別是有三個，一個思否爬蟲，一個是CSDN爬蟲，最後是部落格園爬蟲，三個系統均是一個小的SpringBoot微服務，我的主服務仍然是部落格系統，爬蟲數據抓取並實時入庫，會在一定程度上導致我的主部落格系統訪問緩慢，原因是因為爬蟲應用抓取數據並實時入庫，性能在資料庫上，後來我想了一個辦法將爬蟲資料庫放在阿里雲的RDS上，每當晚上的23點到第二天的5點，這個時間段，爬蟲會將爬蟲資料庫上面的數據遷移到我的主部落格系統上。
以此來保證數據的最終一致性，也就是我不一定要數據馬上入庫能看到效果，我可以允許一定的延遲時間，只要最終某個時間段我能看到大量的數據即可，當時做這個的目的在於那個時候研究資料庫SQL優化，在研究SQL優化層面，我需要造一批數據，但我不喜歡假數據，於是通過爬蟲抓取一些真實的數據，這些真實的數據主要為我個人服務，一方面作為學習的素材，另外一方面可以基於真實的內容做一些數據分析。
二、為什麼會產生BASE理論？
新的理論的產生總是為了改進和完善舊有的理論，但本質上仍然變化不大(這也是左耳朵耗子為什麼著重說要注重基本功，也包括我的導師以及老J也曾說過多次)。
例如:
從單體應用到分散式微服務應用、從CAP理論到BASE理論、從前後端不分離到前後分離等，就很好的說明了這一點。
