對於互聯網業務來說，傳統的直接訪問資料庫方式，主要通過數據分片、一主多從等方式來扛住讀寫流量，但隨著數據量的積累和流量的激增，僅依賴資料庫來承接所有流量，不僅成本高、效率低、而且還伴隨著穩定性降低的風險。
鑒於大部分業務通常是讀多寫少（讀取頻率遠遠高於更新頻率），甚至存在讀操作數量高出寫操作多個數量級的情況。因此， 在架構設計中，常採用增加緩存層來提高系統的響應能力 ，提升數據讀寫性能、減少資料庫訪問壓力，從而提升業務的穩定性和訪問體驗。
根據 CAP 原理，分布式系統在可用性、一致性和分區容錯性上無法兼得，通常由於分區容錯無法避免，所以一致性和可用性難以同時成立。對於緩存系統來說， 如何保證其數據一致性是一個在應用緩存的同時不得不解決的問題 。
需要明確的是，緩存系統的數據一致性通常包括持久化層和緩存層的一致性、以及多級緩存之間的一致性，這里我們僅討論前者。持久化層和緩存層的一致性問題也通常被稱為雙寫一致性問題，「雙寫」意為數據既在資料庫中保存一份，也在緩存中保存一份。
對於一致性來說，包含強一致性和弱一致性 ，強一致性保證寫入後立即可以讀取，弱一致性則不保證立即可以讀取寫入後的值，而是盡可能的保證在經過一定時間後可以讀取到，在弱一致性中應用最為廣泛的模型則是最終一致性模型，即保證在一定時間之後寫入和讀取達到一致的狀態。對於應用緩存的大部分場景來說，追求的則是最終一致性，少部分對數據一致性要求極高的場景則會追求強一致性。
為了達到最終一致性，針對不同的場景，業界逐步形成了下面這幾種應用緩存的策略。
— 1 —
Cache-Aside
Cache-Aside 意為旁路緩存模式，是應用最為廣泛的一種緩存策略。下面的圖示展示了它的讀寫流程，來看看它是如何保證最終一致性的。在讀請求中，首先請求緩存，若緩存命中（cache hit），則直接返回緩存中的數據；若緩存未命中（cache miss），則查詢資料庫並將查詢結果更新至緩存，然後返回查詢出的數據（demand-filled look-aside ）。在寫請求中，先更新資料庫，再刪除緩存（write-invalidate）。
1、為什麼刪除緩存，而不是更新緩存？
在 Cache-Aside 中，對於讀請求的處理比較容易理解，但在寫請求中，可能會有讀者提出疑問，為什麼要刪除緩存，而不是更新緩存？站在符合直覺的角度來看，更新緩存是一個容易被理解的方案，但站在性能和安全的角度，更新緩存則可能會導致一些不好的後果。
首先是性能 ，當該緩存對應的結果需要消耗大量的計算過程才能得到時，比如需要訪問多張資料庫表並聯合計算，那麼在寫操作中更新緩存的動作將會是一筆不小的開銷。同時，當寫操作較多時，可能也會存在剛更新的緩存還沒有被讀取到，又再次被更新的情況（這常被稱為緩存擾動），顯然，這樣的更新是白白消耗機器性能的，會導致緩存利用率不高。
而等到讀請求未命中緩存時再去更新，也符合懶載入的思路，需要時再進行計算。刪除緩存的操作不僅是冪等的，可以在發生異常時重試，而且寫-刪除和讀-更新在語義上更加對稱。
其次是安全 ，在並發場景下，在寫請求中更新緩存可能會引發數據的不一致問題。參考下面的圖示，若存在兩個來自不同線程的寫請求，首先來自線程 1 的寫請求更新了資料庫（step 1），接著來自線程 2 的寫請求再次更新了資料庫（step 3），但由於網路延遲等原因，線程 1 可能會晚於線程 2 更新緩存（step 4 晚於 step 3），那麼這樣便會導致最終寫入資料庫的結果是來自線程 2 的新值，寫入緩存的結果是來自線程 1 的舊值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。
2、為什麼先更新資料庫，而不是先刪除緩存？
另外，有讀者也會對更新資料庫和刪除緩存的時序產生疑問，那麼為什麼不先刪除緩存，再更新資料庫呢？在單線程下，這種方案看似具有一定合理性，這種合理性體現在刪除緩存成功。
但更新資料庫失敗的場景下，盡管緩存被刪除了，下次讀操作時，仍能將正確的數據寫回緩存，相對於 Cache-Aside 中更新資料庫成功，刪除緩存失敗的場景來說，先刪除緩存的方案似乎更合理一些。那麼，先刪除緩存有什麼問題呢？
問題仍然出現在並發場景下，首先來自線程 1 的寫請求刪除了緩存（step 1），接著來自線程 2 的讀請求由於緩存的刪除導致緩存未命中，根據 Cache-Aside 模式，線程 2 繼而查詢資料庫（step 2），但由於寫請求通常慢於讀請求，線程 1 更新資料庫的操作可能會晚於線程 2 查詢資料庫後更新緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存的結果是來自線程 2 中查詢到的舊值，而寫入資料庫的結果是來自線程 1 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（ step 5 ），讀取到的便是舊值。
另外，先刪除緩存，由於緩存中數據缺失，加劇資料庫的請求壓力，可能會增大緩存穿透出現的概率。
3、如果選擇先刪除緩存，再更新資料庫，那如何解決一致性問題呢？
為了避免「先刪除緩存，再更新資料庫」這一方案在讀寫並發時可能帶來的緩存臟數據，業界又提出了延時雙刪的策略，即在更新資料庫之後，延遲一段時間再次刪除緩存，為了保證第二次刪除緩存的時間點在讀請求更新緩存之後，這個延遲時間的經驗值通常應稍大於業務中讀請求的耗時。
延遲的實現可以在代碼中 sleep 或採用延遲隊列。顯而易見的是，無論這個值如何預估，都很難和讀請求的完成時間點准確銜接，這也是延時雙刪被詬病的主要原因。
4、那麼 Cache-Aside 存在數據不一致的可能嗎？
在 Cache-Aside 中，也存在數據不一致的可能性。在下面的讀寫並發場景下，首先來自線程 1 的讀請求在未命中緩存的情況下查詢資料庫（step 1），接著來自線程 2 的寫請求更新資料庫（step 2），但由於一些極端原因，線程 1 中讀請求的更新緩存操作晚於線程 2 中寫請求的刪除緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存中的是來自線程 1 的舊值，而寫入資料庫中的是來自線程 2 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。
這種場景的出現，不僅需要緩存失效且讀寫並發執行，而且還需要讀請求查詢資料庫的執行早於寫請求更新資料庫，同時讀請求的執行完成晚於寫請求。足以見得，這種 不一致場景產生的條件非常嚴格，在實際的生產中出現的可能性較小 。
除此之外，在並發環境下，Cache-Aside 中也存在讀請求命中緩存的時間點在寫請求更新資料庫之後，刪除緩存之前，這樣也會導致讀請求查詢到的緩存落後於資料庫的情況。
雖然在下一次讀請求中，緩存會被更新，但如果業務層面對這種情況的容忍度較低，那麼可以採用加鎖在寫請求中保證「更新資料庫&刪除緩存」的串列執行為原子性操作（同理也可對讀請求中緩存的更新加鎖）。 加鎖勢必會導致吞吐量的下降，故採取加鎖的方案應該對性能的損耗有所預期。
— 2 —
補償機制
我們在上面提到了，在 Cache-Aside 中可能存在更新資料庫成功，但刪除緩存失敗的場景，如果發生這種情況，那麼便會導致緩存中的數據落後於資料庫，產生數據的不一致的問題。
其實，不僅 Cache-Aside 存在這樣的問題，在延時雙刪等策略中也存在這樣的問題。針對可能出現的刪除失敗問題，目前業界主要有以下幾種補償機制。
1、刪除重試機制
由於同步重試刪除在性能上會影響吞吐量，所以常通過引入消息隊列，將刪除失敗的緩存對應的 key 放入消息隊列中，在對應的消費者中獲取刪除失敗的 key ，非同步重試刪除。這種方法在實現上相對簡單，但由於刪除失敗後的邏輯需要基於業務代碼的 trigger 來觸發 ，對業務代碼具有一定入侵性。
鑒於上述方案對業務代碼具有一定入侵性，所以需要一種更加優雅的解決方案，讓緩存刪除失敗的補償機制運行在背後，盡量少的耦合於業務代碼。一個簡單的思路是通過後台任務使用更新時間戳或者版本作為對比獲取資料庫的增量數據更新至緩存中，這種方式在小規模數據的場景可以起到一定作用，但其擴展性、穩定性都有所欠缺。
一個相對成熟的方案是基於 Mysql 資料庫增量日誌進行解析和消費，這里較為流行的是阿里巴巴開源的作為 MySQL binlog 增量獲取和解析的組件 canal（類似的開源組件還有 Maxwell、Databus 等）。
canal sever 模擬 MySQL slave 的交互協議，偽裝為 MySQL slave，向 MySQL master 發送 mp 協議，MySQL master 收到 mp 請求，開始推送 binary log 給 slave （即 canal sever ），canal sever 解析 binary log 對象（原始為 byte 流），可由 canal client 拉取進行消費，同時 canal server 也默認支持將變更記錄投遞到 MQ 系統中，主動推送給其他系統進行消費。
在 ack 機制的加持下，不管是推送還是拉取，都可以有效的保證數據按照預期被消費。當前版本的 canal 支持的 MQ 有 Kafka 或者 RocketMQ。另外， canal 依賴 ZooKeeper 作為分布式協調組件來實現 HA ，canal 的 HA 分為兩個部分：
那麼，針對緩存的刪除操作便可以在 canal client 或 consumer 中編寫相關業務代碼來完成。這樣，結合資料庫日誌增量解析消費的方案以及 Cache-Aside 模型，在讀請求中未命中緩存時更新緩存（通常這里會涉及到復雜的業務邏輯），在寫請求更新資料庫後刪除緩存，並基於日誌增量解析來補償資料庫更新時可能的緩存刪除失敗問題，在絕大多數場景下，可以有效的保證緩存的最終一致性。
另外需要注意的是，還應該隔離事務與緩存，確保資料庫入庫後再進行緩存的刪除操作。 比如考慮到資料庫的主從架構，主從同步及讀從寫主的場景下，可能會造成讀取到從庫的舊數據後便更新了緩存，導致緩存落後於資料庫的問題，這就要求對緩存的刪除應該確保在資料庫操作完成之後。所以，基於 binlog 增量日誌進行數據同步的方案，可以通過選擇解析從節點的 binlog，來避免主從同步下刪除緩存過早的問題。
3、數據傳輸服務 DTS
— 3 —
Read-Through
Read-Through 意為讀穿透模式，它的流程和 Cache-Aside 類似，不同點在於 Read-Through 中多了一個訪問控制層，讀請求只和該訪問控制層進行交互，而背後緩存命中與否的邏輯則由訪問控制層與數據源進行交互，業務層的實現會更加簡潔，並且對於緩存層及持久化層交互的封裝程度更高，更易於移植。
— 4 —
Write-Through
Write-Through 意為直寫模式，對於 Write-Through 直寫模式來說，它也增加了訪問控制層來提供更高程度的封裝。不同於 Cache-Aside 的是，Write-Through 直寫模式在寫請求更新資料庫之後，並不會刪除緩存，而是更新緩存。
這種方式的 優勢在於讀請求過程簡單 ，不需要查詢資料庫更新緩存等操作。但其劣勢也非常明顯，除了上面我們提到的更新資料庫再更新緩存的弊端之外，這種方案還會造成更新效率低，並且兩個寫操作任何一次寫失敗都會造成數據不一致。
如果要使用這種方案， 最好可以將這兩個操作作為事務處理，可以同時失敗或者同時成功，支持回滾，並且防止並發環境下的不一致 。另外，為了防止緩存擾動的頻發，也可以給緩存增加 TTL 來緩解。
站在可行性的角度，不管是 Write-Through 模式還是 Cache-Aside 模式，理想狀況下都可以通過分布式事務保證緩存層數據與持久化層數據的一致性，但在實際項目中，大多都對一致性的要求存在一些寬容度，所以在方案上往往有所折衷。
Write-Through 直寫模式適合寫操作較多，並且對一致性要求較高的場景，在應用 Write-Through 模式時，也需要通過一定的補償機制來解決它的問題。首先，在並發環境下，我們前面提到了先更新資料庫，再更新緩存會導致緩存和資料庫的不一致，那麼先更新緩存，再更新資料庫呢？
這樣的操作時序仍然會導致下面這樣線程 1 先更新緩存，最後更新資料庫的情況，即由於線程 1 和 線程 2 的執行不確定性導致資料庫和緩存的不一致。這種由於線程競爭導致的緩存不一致，可以通過分布式鎖解決，保證對緩存和資料庫的操作僅能由同一個線程完成。對於沒有拿到鎖的線程，一是通過鎖的 timeout 時間進行控制，二是將請求暫存在消息隊列中順序消費。
在下面這種並發執行場景下，來自線程 1 的寫請求更新了資料庫，接著來自線程 2 的讀請求命中緩存，接著線程 1 才更新緩存，這樣便會導致線程 2 讀取到的緩存落後於資料庫。同理，先更新緩存後更新資料庫在寫請求和讀請求並發時，也會出現類似的問題。面對這種場景，我們也可以加鎖解決。
另在，在 Write-Through 模式下，不管是先更新緩存還是先更新資料庫，都存在更新緩存或者更新資料庫失敗的情況，上面提到的重試機制和補償機制在這里也是奏效的。
— 5 —
Write-Behind
Write behind 意為非同步回寫模式，它也具有類似 Read-Through/Write-Through 的訪問控制層，不同的是，Write behind 在處理寫請求時，只更新緩存而不更新資料庫，對於資料庫的更新，則是通過批量非同步更新的方式進行的，批量寫入的時間點可以選在資料庫負載較低的時間進行。
在 Write-Behind 模式下，寫請求延遲較低，減輕了資料庫的壓力，具有較好的吞吐性。但資料庫和緩存的一致性較弱，比如當更新的數據還未被寫入資料庫時，直接從資料庫中查詢數據是落後於緩存的。同時，緩存的負載較大，如果緩存宕機會導致數據丟失，所以需要做好緩存的高可用。顯然，Write behind 模式下適合大量寫操作的場景，常用於電商秒殺場景中庫存的扣減。
— 6 —
Write-Around
如果一些非核心業務，對一致性的要求較弱，可以選擇在 cache aside 讀模式下增加一個緩存過期時間，在寫請求中僅僅更新資料庫，不做任何刪除或更新緩存的操作，這樣，緩存僅能通過過期時間失效。這種方案實現簡單，但緩存中的數據和資料庫數據一致性較差，往往會造成用戶的體驗較差，應慎重選擇。
— 7 —
總結
在解決緩存一致性的過程中，有多種途徑可以保證緩存的最終一致性，應該根據場景來設計合適的方案，讀多寫少的場景下，可以選擇採用「Cache-Aside 結合消費資料庫日誌做補償」的方案，寫多的場景下，可以選擇採用「Write-Through 結合分布式鎖」的方案 ，寫多的極端場景下，可以選擇採用「Write-Behind」的方案。
Ⅱ soulcoder——消息隊列知識總結(偏向於 Kafka)
[toc]
分析一個消息隊列主要從這幾個點出來。
在後半部分主要分析了 kafka 對以上幾點的保證。
詳見下文分析重點分析。
事務支持方面，ONS/RocketMQ較為優秀，但是不支持消息批量操作, 不保證消息至少被消費一次.
Kafka提供完全分布式架構, 並有replica機制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積, 支持批量操作, 消費者採用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費且僅被消費一次. 但是官方提供的運維工具不友好，開源社區的運維工具支持的版本一般落後於最新版本的Kafka.
目前使用的MNS服務，擁有HTTP REST API, 使用簡單, 數據可靠性高, 但是不保證消息有序，不能回溯數據.
RabbitMQ為重量級消息系統， 支持多協議(很多協議是目前業務用不到的), 但是不支持回溯數據, master掛掉之後， 需要手動從slave恢復, 可用性略遜一籌.
以rcoketMQ為例，他的集群就有
第一眼看到這個圖，就覺得和kafka好像，只是NameServer集群，在kafka中是用zookeeper代替，都是用來保存和發現master和slave用的。
通信過程如下:
Procer 與 NameServer集群中的其中一個節點（隨機選擇）建立長連接，定期從 NameServer 獲取 Topic 路由信息，並向提供 Topic 服務的 Broker Master 建立長連接，且定時向 Broker 發送心跳。
Procer 只能將消息發送到 Broker master，但是 Consumer 則不一樣，它同時和提供 Topic 服務的 Master 和 Slave建立長連接，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。
那麼kafka呢？
為了對比說明直接上kafka的拓補架構圖
如上圖所示，一個典型的Kafka集群中包含若干Procer（可以是web前端產生的Page View，或者是伺服器日誌，系統CPU、Memory等），若干broker（Kafka支持水平擴展，一般broker數量越多，集群吞吐率越高），若干Consumer Group，以及一個Zookeeper集群。Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Procer使用push模式將消息發布到broker，Consumer使用pull模式從broker訂閱並消費消息。
最騷的一個操作，消費者業務自己去保證冪等性。
換一個說法，如何保證消息隊列的冪等性?
另外說一點，冪等性的保證需要在一次請求中所有鏈路都是冪等的，再能最終保證這次請求的冪等，比如前段按鈕點擊兩次，後端認為都是這是兩次不同的請求，當然處理成兩次請求，所以說一個請求的冪等性，需要全局的冪等才能保證。
其實無論是哪種消息隊列，造成重復消費原因其實都是類似的。正常情況下，消費者在消費消息時候，消費完畢後，會發送一個確認信息給消息隊列，消息隊列就知道該消息被消費了，就會將該消息從消息隊列中刪除。只是不同的消息隊列發送的確認信息形式不同。
例如RabbitMQ是發送一個ACK確認消息，RocketMQ是返回一個CONSUME_SUCCESS成功標志，kafka實際上有個offset的概念，簡單說一下(後續詳細解釋),就是每一個消息都有一個offset，kafka消費過消息後，需要提交offset，讓消息隊列知道自己已經消費過了。
那造成重復消費的原因?，就是因為網路傳輸等等故障，確認信息沒有傳送到消息隊列，導致消息隊列不知道自己已經消費過該消息了，再次將該消息分發給其他的消費者。
如何解決?這個問題針對業務場景來答分以下幾點
其實這個可靠性傳輸，每種MQ都要從三個角度來分析:生產者弄丟數據、消息隊列弄丟數據、消費者弄丟數據。
從生產者弄丟數據這個角度來看，RabbitMQ提供transaction和confirm模式來確保生產者不丟消息。
transaction(事物機制)機制就是說，發送消息前，開啟事物(channel.txSelect())，然後發送消息，如果發送過程中出現什麼異常，事物就會回滾(channel.txRollback())，如果發送成功則提交事物(channel.txCommit())。然而缺點就是吞吐量下降了。
生產上用confirm模式的居多。一旦channel進入confirm模式，所有在該信道上面發布的消息都將會被指派一個唯一的ID(從1開始)，一旦消息被投遞到所有匹配的隊列之後，rabbitMQ就會發送一個Ack給生產者(包含消息的唯一ID)，這就使得生產者知道消息已經正確到達目的隊列了.如果rabiitMQ沒能處理該消息，則會發送一個Nack消息給你，你可以進行重試操作。
簡單來講 confirm模式就是生產者發送請求，到了消息隊列，消息隊列會回復一個消息收到的應答，如果沒收到，生產者開始重試。
處理消息隊列丟數據的情況，一般是開啟持久化磁碟的配置。這個持久化配置可以和confirm機制配合使用，你可以在消息持久化磁碟後，再給生產者發送一個Ack信號。這樣，如果消息持久化磁碟之前，rabbitMQ陣亡了，那麼生產者收不到Ack信號，生產者會自動重發。
消費者丟數據一般是因為採用了自動確認消息模式。這種模式下，消費者會自動確認收到信息。這時rahbitMQ會立即將消息刪除，這種情況下如果消費者出現異常而沒能處理該消息(但是消息隊列那邊已經認為消息被消費了)，就會丟失該消息。
至於解決方案，採用手動確認消息即可。
kafka為例
Procer在發布消息到某個Partition時，先通過ZooKeeper找到該Partition的Leader，然後無論該Topic的Replication Factor為多少（也即該Partition有多少個Replica），Procer只將該消息發送到該Partition的Leader。Leader會將該消息寫入其本地Log。每個Follower都從Leader中pull數據。
在kafka生產中，基本都有一個leader和多個follwer。follwer會去同步leader的信息。因此，為了避免生產者丟數據，做如下兩點配置
針對消息隊列丟數據的情況，無外乎就是，數據還沒同步，leader就掛了，這時zookpeer會將其他的follwer切換為leader,那數據就丟失了。針對這種情況，應該做兩個配置。
這種情況一般是自動提交了offset，然後你處理程序過程中掛了。kafka以為你處理好了。再強調一次offset是幹嘛的。
offset：指的是kafka的topic中的每個消費組消費的下標。簡單的來說就是一條消息對應一個offset下標，每次消費數據的時候如果提交offset，那麼下次消費就會從提交的offset加一那裡開始消費。
比如一個topic中有100條數據，我消費了50條並且提交了，那麼此時的kafka服務端記錄提交的offset就是49(offset從0開始)，那麼下次消費的時候offset就從50開始消費。
針對這個問題，通過某種演算法，將需要保持先後順序的消息放到同一個消息隊列中(kafka中就是partition,rabbitMq中就是queue)。然後只用一個消費者去消費該隊列。
有的人會問:那如果為了吞吐量，有多個消費者去消費怎麼辦？
簡單來說消息的時序性也可以通過錯誤重試來解決。
比如我們有一個微博的操作，發微博、寫評論、刪除微博，這三個非同步操作。如果是這樣一個業務場景，那隻要重試就行。比如你一個消費者先執行了寫評論的操作，但是這時候，微博都還沒發，寫評論一定是失敗的，等一段時間。等另一個消費者，先執行寫評論的操作後，再執行，就可以成功。
總之，針對這個問題，我的觀點是保證入隊有序就行，出隊以後的順序交給消費者自己去保證，沒有固定套路。
為了做到水平擴展，一個topic實際是由多個partition組成的，遇到瓶頸時，可以通過增加partition的數量來進行橫向擴容。
單個parition內是保證消息有序。
訂閱topic是以一個消費組來訂閱的，一個消費組裡面可以有多個消費者。
同一個消費組中的兩個消費者，只能消費一個partition。
換句話來說，就是一個partition，只能被消費組里的一個消費者消費，但是可以同時被多個消費組消費。
如果消費組內的消費者如果比partition多的話，那麼就會有個別消費者一直空閑。
kafka api 提供了很多功能比如
生產者能指定 topic 和 Partition 來投遞消息，並且還有延遲消息，事務消息等等，詳見下面的 api 文檔
http://kafka.apache.org/documentation.html#api
這個是 api 的中文文檔
http://orchome.com/66
Kakfa Broker集群受Zookeeper管理。
這里先說下
關於partition的分配，還有leader的選舉，總得有個執行者。在kafka中，這個執行者就叫controller。kafka使用zk在broker中選出一個controller，用於partition分配和leader選舉。
所有的Kafka Broker節點一起去Zookeeper上注冊一個臨時節點，並且只有一個Kafka Broker會注冊成功，其他的都會失敗，所以這個成功在Zookeeper上注冊臨時節點的這個Kafka Broker會成為 Kafka Broker Controller ，其他的Kafka broker叫 Kafka Broker follower 。（這個過程叫Controller在ZooKeeper注冊Watch）。
這個Controller會監聽其他的Kafka Broker的所有信息，如果這個kafka broker controller宕機了，在zookeeper上面的那個臨時節點就會消失，此時所有的kafka broker又會一起去Zookeeper上注冊一個臨時節點。
Kafka提供3種消息傳輸一致性語義：最多1次，最少1次，恰好1次。
最少1次(at most once)：可能會重傳數據，有可能出現數據被重復處理的情況;
最多1次(at least once)：可能會出現數據丟失情況;
恰好1次(Exactly once)：並不是指真正只傳輸1次，只不過有一個機制。確保不會出現「數據被重復處理」和「數據丟失」的情況。
操作系統本身有一層緩存，叫做page cache，是在內存里的緩存，我們也可以稱之為os cache，意思就是操作系統自己管理的緩存。
每新寫一條消息，kafka就是在對應的文件append寫，所以性能非常高。
https://mp.weixin.qq.com/s/sCRC5h0uw2DWD2MixI6pZw
我覺得的靠的是這兩個參數
這篇主要從生產和消費的角度詳細給出的過程
https://www.cnblogs.com/cyfonly/p/5954614.html
Ⅲ redis與mysql怎麼保證數據一致
1、技術整體思路。
MySQL binlog增量訂閱消費+消息隊列+增量數據更新到redis
1）讀Redis：熱數據基本都在Redis
2）寫MySQL:增刪改都是操作MySQL
3）更新Redis數據：MySQ的數據操作binlog，來更新到Redis
2、Redis更新。
1）數據操作主要分為兩大塊：
一個是全量(將全部數據一次寫入到redis)
一個是增量（實時更新）
這里說的是增量，指的是mysql的update、insert、delate變更數據。
2）讀取binlog後分析 ，利用消息隊列，推送更新各台的redis緩存數據。
這樣一旦MySQL中產生了新的寫入、更新、刪除等操作，就可以把binlog相關的消息推送至Redis，Redis再根據binlog中的記錄，對Redis進行更新。
其實這種機制，很類似MySQL的主從備份機制，因為MySQL的主備也是通過binlog來實現的數據一致性。
這里可以結合使用canal(阿里的一款開源框架)，通過該框架可以對MySQL的binlog進行訂閱，而canal正是模仿了mysql的slave資料庫的備份請求，使得Redis的數據更新達到了相同的效果。
Ⅳ 為什麼要用消息隊列更新緩存
用消息隊列更新緩存原因：
1、通過消息隊列將更新緩存操作串列處理，可以解決並發更新的問題，比如線程A、線程B在並發更新資料庫時，利用資料庫事務隔離機制避免臟讀。
2、然後把數據標識寫入消息隊列，接下來消費消息隊列，再通過數據標識去讀取資料庫相應數據並刷新緩存。
Ⅳ 保證分布式系統數據一致性的6種方案
編者按 ：本文由「高可用架構後花園」群討論整理而成。
有人的地方，就有江湖
有江湖的地方，就有紛爭
在電商等業務中，系統一般由多個獨立的服務組成，如何解決分布式調用時候數據的一致性？
具體業務場景如下，比如一個業務操作，如果同時調用服務 A、B、C，需要滿足要麼同時成功；要麼同時失敗。A、B、C 可能是多個不同部門開發、部署在不同伺服器上的遠程服務。
在分布式系統來說，如果不想犧牲一致性，CAP 理論告訴我們只能放棄可用性，這顯然不能接受。為了便於討論問題，先簡單介紹下數據一致性的基礎理論。
強一致
弱一致性
最終一致性
在工程實踐上，為了保障系統的可用性，互聯網系統大多將強一致性需求轉換成最終一致性的需求，並通過系統執行冪等性的保證，保證數據的最終一致性。但在電商等場景中，對於數據一致性的解決方法和常見的互聯網系統（如 MySQL 主從同步）又有一定區別，群友的討論分成以下 6 種解決方案。
業務整合方案主要採用將介面整合到本地執行的方法。拿問題場景來說，則可以將服務 A、B、C 整合為一個服務 D 給業務，這個服務 D 再通過轉換為本地事務的方式，比如服務 D 包含本地服務和服務 E，而服務 E 是本地服務 A ~ C 的整合。
優點： 解決（規避）了分布式事務。
缺點： 顯而易見，把本來規劃拆分好的業務，又耦合到了一起，業務職責不清晰，不利於維護。
由於這個方法存在明顯缺點，通常不建議使用。
此方案的核心是將需要分布式處理的任務通過消息日誌的方式來非同步執行。消息日誌可以存儲到本地文本、資料庫或消息隊列，再通過業務規則自動或人工發起重試。人工重試更多的是應用於支付場景，通過對賬系統對事後問題的處理。
消息日誌方案的核心是保證服務介面的冪等性。
考慮到網路通訊失敗、數據丟包等原因，如果介面不能保證冪等性，數據的唯一性將很難保證。
eBay 方式的主要思路如下。
Base：一種 Acid 的替代方案
此方案是 eBay 的架構師 Dan Pritchett 在 2008 年發表給 ACM 的文章，是一篇解釋 BASE 原則，或者說最終一致性的經典文章。文中討論了 BASE 與 ACID 原則在保證數據一致性的基本差異。
如果 ACID 為分區的資料庫提供一致性的選擇，那麼如何實現可用性呢？答案是
BASE (basically available, soft state, eventually consistent)
BASE 的可用性是通過 支持局部故障 而不是系統全局故障來實現的。下面是一個簡單的例子：如果將用戶分區在 5 個資料庫伺服器上，BASE 設計鼓勵類似的處理方式，一個用戶資料庫的故障隻影響這台特定主機那 20% 的用戶。這里不涉及任何魔法，不過它確實可以帶來更高的可感知的系統可用性。
文章中描述了一個最常見的場景，如果產生了一筆交易，需要在交易表增加記錄，同時還要修改用戶表的金額。這兩個表屬於不同的遠程服務，所以就涉及到分布式事務一致性的問題。
文中提出了一個經典的解決方法，將主要修改操作以及更新用戶表的消息 放在一個本地事務 來完成。同時為了避免重復消費用戶表消息帶來的問題，達到多次重試的冪等性， 增加一個更新記錄表 updates_applied 來記錄已經處理過的消息。
系統的執行偽代碼如下
（點擊可全屏縮放圖片）
基於以上方法，在第一階段，通過本地的資料庫的事務保障，增加了 transaction 表及消息隊列 。
在第二階段，分別讀出消息隊列（但不刪除），通過判斷更新記錄表 updates_applied 來檢測相關記錄是否被執行，未被執行的記錄會修改 user 表，然後增加一條操作記錄到 updates_applied，事務執行成功之後再刪除隊列。
通過以上方法，達到了分布式系統的最終一致性。進一步了解 eBay 的方案可以參考文末鏈接。
隨著業務規模不斷地擴大，電商網站一般都要面臨拆分之路。就是將原來一個單體應用拆分成多個不同職責的子系統。比如以前可能將面向用戶、客戶和運營的功能都放在一個系統里，現在拆分為訂單中心、代理商管理、運營系統、報價中心、庫存管理等多個子系統。
拆分首先要面臨的是什麼呢？
最開始的單體應用所有功能都在一起，存儲也在一起。比如運營要取消某個訂單，那直接去更新訂單表狀態，然後更新庫存表就 ok 了。因為是單體應用，庫在一起，這些都可以在一個事務里，由關系資料庫來保證一致性。
但拆分之後就不同了，不同的子系統都有自己的存儲。比如訂單中心就只管理自己的訂單庫，而庫存管理也有自己的庫。那麼運營系統取消訂單的時候就是通過介面調用等方式來調用訂單中心和庫存管理的服務了，而不是直接去操作庫。這就涉及一個『 分布式事務 』的問題。
分布式事務有兩種解決方式
1. 優先使用非同步消息。
上文已經說過，使用非同步消息 Consumer 端需要實現冪等。
冪等有兩種方式， 一種方式是業務邏輯保證冪等 。比如接到支付成功的消息訂單狀態變成支付完成，如果當前狀態是支付完成，則再收到一個支付成功的消息則說明消息重復了，直接作為消息成功處理。
另外一種方式如果業務邏輯無法保證冪等，則要增加一個去重表或者類似的實現 。對於 procer 端在業務資料庫的同實例上放一個消息庫，發消息和業務操作在同一個本地事務里。發消息的時候消息並不立即發出，而是向消息庫插入一條消息記錄，然後在事務提交的時候再非同步將消息發出，發送消息如果成功則將消息庫里的消息刪除，如果遇到消息隊列服務異常或網路問題，消息沒有成功發出那麼消息就留在這里了，會有另外一個服務不斷地將這些消息掃出重新發送。
2. 有的業務不適合非同步消息的方式，事務的各個參與方都需要同步的得到結果。 這種情況的實現方式其實和上面類似，每個參與方的本地業務庫的同實例上面放一個事務記錄庫。
比如 A 同步調用 B，C。A 本地事務成功的時候更新本地事務記錄狀態，B 和 C 同樣。如果有一次 A 調用 B 失敗了，這個失敗可能是 B 真的失敗了，也可能是調用超時，實際 B 成功。則由一個中心服務對比三方的事務記錄表，做一個最終決定。假設現在三方的事務記錄是 A 成功，B 失敗，C 成功。那麼最終決定有兩種方式，根據具體場景：
對 b 場景做一個特殊說明：比如 B 是扣庫存服務，在第一次調用的時候因為某種原因失敗了，但是重試的時候庫存已經變為 0，無法重試成功，這個時候只有回滾 A 和 C 了。
那麼可能有人覺得在業務庫的同實例里放消息庫或事務記錄庫，會對業務侵入，業務還要關心這個庫，是否一個合理的設計？
實際上可以依靠運維的手段來簡化開發的侵入，我們的方法是讓 DBA 在公司所有 MySQL 實例上預初始化這個庫，通過框架層（消息的客戶端或事務 RPC 框架）透明的在背後操作這個庫，業務開發人員只需要關心自己的業務邏輯，不需要直接訪問這個庫。
總結起來，其實兩種方式的根本原理是類似的，也就是 將分布式事務轉換為多個本地事務，然後依靠重試等方式達到最終一致性 。
交易創建的一般性流程
我們把交易創建流程抽象出一系列可擴展的功能點，每個功能點都可以有多個實現（具體的實現之間有組合/互斥關系）。把各個功能點按照一定流程串起來，就完成了交易創建的過程。
面臨的問題
每個功能點的實現都可能會依賴外部服務。那麼如何保證各個服務之間的數據是一致的呢？比如鎖定優惠券服務調用超時了，不能確定到底有沒有鎖券成功，該如何處理？再比如鎖券成功了，但是扣減庫存失敗了，該如何處理？
方案選型
服務依賴過多，會帶來管理復雜性增加和穩定性風險增大的問題。試想如果我們強依賴 10 個服務，9 個都執行成功了，最後一個執行失敗了，那麼是不是前面 9 個都要回滾掉？這個成本還是非常高的。
所以在拆分大的流程為多個小的本地事務的前提下，對於非實時、非強一致性的關聯業務寫入，在本地事務執行成功後，我們選擇發消息通知、關聯事務非同步化執行的方案。
消息通知往往不能保證 100% 成功；且消息通知後，接收方業務是否能執行成功還是未知數。前者問題可以通過重試解決；後者可以選用事務消息來保證。
所以目前只剩下需要實時同步做、有強一致性要求的業務場景了。在交易創建過程中，鎖券和扣減庫存是這樣的兩個典型場景。
要保證多個系統間數據一致，乍一看，必須要引入分布式事務框架才能解決。但引入非常重的類似二階段提交分布式事務框架會帶來復雜性的急劇上升；在電商領域，絕對的強一致是過於理想化的，我們可以選擇准實時的最終一致性。
我們在交易創建流程中， 首先創建一個不可見訂單 ，然後在同步調用鎖券和扣減庫存時，針對調用異常（失敗或者超時），發出廢單消息到MQ。如果消息發送失敗，本地會做時間階梯式的非同步重試；優惠券系統和庫存系統收到消息後，會進行判斷是否需要做業務回滾，這樣就准實時地保證了多個本地事務的最終一致性。
業界常用的還有支付寶的一種 xts 方案，由支付寶在 2PC 的基礎上改進而來。主要思路如下，大部分信息引用自官方網站。
分布式事務服務簡介
分布式事務服務 (Distributed Transaction Service, DTS) 是一個分布式事務框架，用來保障在大規模分布式環境下事務的最終一致性。DTS 從架構上分為 xts-client 和 xts-server 兩部分，前者是一個嵌入客戶端應用的 JAR 包，主要負責事務數據的寫入和處理；後者是一個獨立的系統，主要負責異常事務的恢復。
核心特性
傳統關系型資料庫的事務模型必須遵守 ACID 原則。在單資料庫模式下，ACID 模型能有效保障數據的完整性，但是在大規模分布式環境下，一個業務往往會跨越多個資料庫，如何保證這多個資料庫之間的數據一致性，需要其他行之有效的策略。在 JavaEE 規范中使用 2PC (2 Phase Commit, 兩階段提交) 來處理跨 DB 環境下的事務問題，但是 2PC 是反可伸縮模式，也就是說，在事務處理過程中，參與者需要一直持有資源直到整個分布式事務結束。這樣，當業務規模達到千萬級以上時，2PC 的局限性就越來越明顯，系統可伸縮性會變得很差。基於此，我們採用 BASE 的思想實現了一套類似 2PC 的分布式事務方案，這就是 DTS。DTS在充分保障分布式環境下高可用性、高可靠性的同時兼顧數據一致性的要求，其最大的特點是保證數據最終一致 (Eventually consistent)。
簡單的說，DTS 框架有如下特性：
以下是分布式事務框架的流程圖
實現
與 2PC 協議比較
1. 電商業務
公司的支付部門，通過接入其它第三方支付系統來提供支付服務給業務部門，支付服務是一個基於 Dubbo 的 RPC 服務。
對於業務部門來說，電商部門的訂單支付，需要調用
從業務規則上需要同時保證業務數據的實時性和一致性，也就是支付成功必須加積分。
我們採用的方式是同步調用，首先處理本地事務業務。考慮到積分業務比較單一且業務影響低於支付，由積分平台提供增加與回撤介面。
具體的流程是先調用積分平台增加用戶積分，再調用支付平台進行支付處理，如果處理失敗，catch 方法調用積分平台的回撤方法，將本次處理的積分訂單回撤。
(點擊圖片可以全屏縮放)
2. 用戶信息變更
分布式服務對衍生的配套系統要求比較多，特別是我們基於消息、日誌的最終一致性方案，需要考慮消息的積壓、消費情況、監控、報警等。
In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability.
英文版 ： http://queue.acm.org/detail.cfm?id=1394128
中文版： http://article.yeeyan.org/view/167444/125572
感謝李玉福、余昭輝、蘑菇街七公提供方案，其他多位群成員對本文內容亦有貢獻。
本文編輯李玉福、Tim Yang，轉載請註明來自@高可用架構
Ⅵ 緩存一致性
在現代的 CPU（大多數）上，所有的內存訪問都需要通過層層的緩存來進行。CPU 的讀 / 寫（以及取指令）單元正常情況下甚至都不能直接訪問內存——這是物理結構決定的；CPU 都沒有管腳直接連到內存。相反，CPU 和一級緩存（L1 Cache）通訊，而一級緩存才能和內存通訊。大約二十年前，一級緩存可以直接和內存傳輸數據。如今，更多級別的緩存加入到設計中，一級緩存已經不能直接和內存通訊了，它和二級緩存通訊——而二級緩存才能和內存通訊。或者還可能有三級緩存。
緩存是分「段」（line）的，一個段對應一塊存儲空間，大小是 32、64或128位元組，每個緩存段知道自己對應什麼范圍的物理內存地址。
當 CPU 看到一條讀內存的指令時，它會把內存地址傳遞給一級數據緩存。一級數據緩存會檢查它是否有這個內存地址對應的緩存段。如果沒有，它會把整個緩存段從內存（或者從更高一級的緩存，如果有的話）中載入進來。是的，一次載入整個緩存段，這是基於這樣一個假設：內存訪問傾向於本地化（localized），如果我們當前需要某個地址的數據，那麼很可能我們馬上要訪問它的鄰近地址。一旦緩存段被載入到緩存中，讀指令就可以正常進行讀取。
如果我們只處理讀操作，那麼事情會很簡單，因為所有級別的緩存都遵守以下規律—— 在任意時刻，任意級別緩存中的緩存段的內容，等同於它對應的內存中的內容。 。
一旦我們允許寫操作，事情就變得復雜一點了。這里有兩種基本的寫模式：直寫（write-through）和回寫（write-back）。直寫更簡單一點：我們透過本級緩存，直接把數據寫到下一級緩存（或直接到內存）中，如果對應的段被緩存了，我們同時更新緩存中的內容（甚至直接丟棄），就這么簡單。這也遵守前面的定律： 緩存中的段永遠和它對應的內存內容匹配。
回寫模式就有點復雜了。緩存不會立即把寫操作傳遞到下一級，而是僅修改本級緩存中的數據，並且把對應的緩存段標記為「臟」段。臟段會觸發回寫，也就是把裡面的內容寫到對應的內存或下一級緩存中。回寫後，臟段又變「干凈」了。當一個臟段被丟棄的時候，總是先要進行一次回寫。回寫所遵循的規律有點不同。 當所有的臟段被回寫後，任意級別緩存中的緩存段的內容，等同於它對應的內存中的內容。
換句話說，回寫模式的定律中，我們去掉了「在任意時刻」這個修飾語，代之以弱化一點的條件：要麼緩存段的內容和內存一致（如果緩存段是干凈的話），要麼緩存段中的內容最終要回寫到內存中（對於臟緩存段來說）。
只要系統只有一個 CPU 核在工作，一切都沒問題。如果有多個核，每個核又都有自己的緩存，那麼我們就遇到問題了，因為如果一個 CPU 緩存了某塊內存，那麼在其他 CPU 修改這塊內存的時候，我們希望得到通知。系統的內存在各個 CPU 之間無法做到與生俱來的同步，我們需要一個大家都能遵守的方法來達到同步的目的。
緩存一致性協議有多種，但是日常處理的大多數計算機設備使用的都屬於「窺探（snooping）」協議。
窺探」背後的基本思想是，所有內存傳輸都發生在一條共享的匯流排上，而所有的處理器都能看到這條匯流排：緩存本身是獨立的，但是內存是共享資源，所有的內存訪問都要經過仲裁（arbitrate）：同一個指令周期中，只有一個緩存可以讀寫內存。窺探協議的思想是，緩存不僅僅在做內存傳輸的時候才和匯流排打交道，而是不停地在窺探匯流排上發生的數據交換，跟蹤其他緩存在做什麼。所以當一個緩存代表它所屬的處理器去讀寫內存時，其他處理器都會得到通知，它們以此來使自己的緩存保持同步。只要某個處理器一寫內存，其他處理器馬上就知道這塊內存在它們自己的緩存中對應的段已經失效。
在直寫模式下，這是很直接的，因為寫操作一旦發生，它的效果馬上會被「公布」出去。但是如果混著回寫模式，就有問題了。因為有可能在寫指令執行過後很久，數據才會被真正回寫到物理內存中——在這段時間內，其他處理器的緩存也可能會傻乎乎地去寫同一塊內存地址，導致沖突。在回寫模型中，簡單把內存寫操作的信息廣播給其他處理器是不夠的，我們需要做的是，在修改本地緩存之前，就要告知其他處理器。
MESI 是四種緩存段狀態的首字母縮寫，任何多核系統中的緩存段都處於這四種狀態之一。
從CPU讀寫角度來說：
上圖的切換解釋：
緩存的一致性消息傳遞是要時間的，這就使其切換時會產生延遲。當一個緩存被切換狀態時其他緩存收到消息完成各自的切換並且發出回應消息這么一長串的時間中CPU都會等待所有緩存響應完成。可能出現的阻塞都會導致各種各樣的性能問題和穩定性問題。
比如你需要修改本地緩存中的一條信息，那麼你必須將I（無效）狀態通知到其他擁有該緩存數據的CPU緩存中，並且等待確認。等待確認的過程會阻塞處理器，這會降低處理器的性能。因為這個等待遠遠比一個指令的執行時間長的多。
為了避免這種CPU運算能力的浪費，Store Bufferes被引入使用。處理器把它想要寫入到主存的值寫到緩存，然後繼續去處理其他事情。當所有失效確認（Invalidate Acknowledge）都接收到時，數據才會最終被提交。
執行失效也不是一個簡單的操作，它需要處理器去處理。另外，存儲緩存（Store Buffers）並不是無窮大的，所以處理器有時需要等待失效確認的返回。這兩個操作都會使得性能大幅降低。為了應付這種情況，引入了失效隊列——對於所有的收到的Invalidate請求，Invalidate Acknowlege消息必須立刻發送，Invalidate並不真正執行，而是被放在一個特殊的隊列中，在方便的時候才會去執行，處理器不會發送任何消息給所處理的緩存條目，直到它處理Invalidate。
Ⅶ 到底什麼是消息隊列Java中如何實現消息隊列
「消息隊列」是在消息的傳輸過程中保存消息的容器。和我們學過的LinkedHashMap，TreeSet等一樣，都是容器。既然是容器，就有有自己的特性，就像LinkedHashMap是以鍵值對存儲。存取順序不變。而消息隊列，看到隊列就可以知道。這個容器裡面的消息是站好隊的，一般遵從先進先出原則。
java中已經為我們封裝好了很多的消息隊列。在java 1.5版本時推出的java.util.concurrent中有很多現成的隊列供我們使用。特性繁多，種類齊全。是你居家旅遊開發必備QAQ。
下面簡單列舉這個包中的消息隊列
:阻塞隊列 BlockingQueue
數組阻塞隊列 ArrayBlockingQueue
延遲隊列 DelayQueue
鏈阻塞隊列 LinkedBlockingQueue
具有優先順序的阻塞隊列 PriorityBlockingQueue
同步隊列 SynchronousQueue
阻塞雙端隊列 BlockingDeque
鏈阻塞雙端隊列 LinkedBlockingDeque
不同的隊列不同的特性決定了隊列使用的時機，感興趣的話你可以詳細了解。具體的使用方式我就不贅述了