一、訊息推送系統設計需求

1、高性價比，在有限的硬體資源下，儘可能的提高訊息系統的效能和可用性。

2、提高資料的一致性。

二、分析

訊息推送，按資料量劃分，包括兩類：

1）持續的大量資料（比如：持續的物聯網GPS上報等）推送，單類資料量大於 10 kb 每秒 。

2）低頻率、資料量小的偶發事件、通知類的資料推送。

訊息重要性和實時性分級：（ “四象限” 劃分）

                            不重要                            |                          不重要

                            可延時                            |                          低延時

                            ——————————————————————

                            很重要                            |                          很重要

                            可延時                            |                          低延時

        備註：

                  很重要  =  非常重要，資料不丟、不亂。

                  不重要  =  可接受偶爾出現問題。

                  低延時  =  延時低（平均在3秒以內）。

                  可延時  =  有一定延時（3秒以上）。

大部分訊息處於 (2) (3) (4) 象限。針對訊息的特性，應採用不同效能和穩定級別的推送方案。

根據 CAP 定理：

    Consistency(一致性), 資料一致更新，所有資料變動都是同步的。

    Availability(可用性), 好的響應效能。

    Partition tolerance(分割槽容錯性) 可靠性。

    定理：任何分散式系統只可同時滿足二點，沒法三者兼顧。

沒有一個分散式系統是C、A、P同時都達到完美的，要麼損失效能來保障一致性和可用性；要麼損失一致性來提高效能。

理想模型如下：

A、犧牲 效能 來提高 可用性和一致性。

B、犧牲 一致性 來提高 效能和可用性。

C、犧牲 可用性 來提高 效能和一致性。

對於上面的 A 模型，用得非常廣泛，比如訊息的ACK機制，用法比較簡單，不多說。

對於上面的 B 模型，經常使用 BASE （犧牲高一致性，保證最終一致性） 方案。

    Basically Available 基本可用。

    Soft state 軟狀態 狀態可以有一段時間不同步，非同步。

    Eventually consistent 最終一致，最終資料是一致的就可以了，而不是實時高一致。

對於上面的 C 模型，用得比較少，也不好理解。犧牲可用性，來保證一致性和效能，我的理解是，除非服務不可用，否則服務一定是高效能且高一致性的。

也就是說，當服務不能保證一致性和高效能的時候，就降低可用性，寧願服務不可用，也不能讓服務出現不一致或者效能低的情況。

C模型的關鍵點在於，C模型的系統，系統自身不保證高可用，出現異常（效能降低或者一致性出現問題）時，它有意降低可用性，來保障服務期間的高效能和資料的強一致性。

所以如果使用C模型，則需要考慮，如何通過外部手段來保證系統的可用性（加強監控，出現不可用時，人工介入恢復，或者啟動臨時方案）。

延伸知識：分散式系統的容錯模式

電路熔斷器模式(Circuit Breaker Patten), 該模式的原理類似於家裡的電路熔斷器，如果家裡的電路發生短路，熔斷器能夠主動熔斷電路，以避免災難性損失。在分散式系統中應用電路熔斷器模式後，當目標服務慢或者大量超時，呼叫方能夠主動熔斷，以防止服務被進一步拖垮或者導致其他系統故障（雪崩效應）；如果情況又好轉了，電路又能自動恢復，這就是所謂的彈性容錯，系統有自恢復能力。

參考文章：http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service/

上面的A、B、C模型對於推送系統來說，

對於上面處於(2) 象限的訊息推送，可以考慮 能否採用上面 C模型，如果不能接受C模型的服務（暫時）不可用，則可能會降級為 A、B 模型，A模型犧牲效能，整個系統是否存在效能問題？B模型犧牲一致性，是否能採用軟狀態、最終一致性方案來彌補？

對於上面處於(3) 象限的訊息推送，宜採用 A 模型。

對於上面處於(4) 象限的訊息推送，宜採用 B 模型，A模型也可以，具體視情況而定。

A模型資料推送系統設計方案

在A模型中，效能不是關鍵。它的關鍵詞：效能不是瓶頸  資料要準確可靠

考慮點：

  1、如何保證資料100%不丟失？

  2、如何保證資料100%不重複？

不丟失：資料來後，先以最穩當的方式持久化下來，再推送出去，推送成功後，才刪掉持久化的資料，否則資料一直持久化直到超過儲存容量或者時間上限。（如果使用資料庫，可以考慮事務）

不重複：能夠識別每條資料的唯一性（最簡單的辦法就是每條資料有一個唯一標識），在記憶體資料庫中儲存一段時間已推送的資料標識（ID）的列表，當新的資料來了之後，和資料標識列表中的ID進行比較，如果存在則說明之前已經推送過這條資料，直接pass，否則推送資料並加入資料標識列表。

技術選型和系統處理資料流程：（純Java + Redis快取ID + 本地磁碟快取資料）

1）收到資料後，先將資料ID取出，去Redis裡已推送的資料ID的列表中查詢，如果找到這個ID，則說明資料已處理過，重複了，則丟棄該資料。否則繼續下面的步驟。

2）將資料和ID用Producer執行緒儘快寫入本地磁碟，以防丟失。

3）然後用Consumer執行緒將資料從磁碟讀取出來，然後嘗試推送出去。

4）如果推送成功，則標記該ID的資料為success並儲存到磁碟，然後繼續處理後面的資料。否則暫停或關閉接收 後續的資料（如果可以），如果不能暫停，則直接進入下面的第(5)步驟），

5）無限嘗試推送當前資料，直到故障解除，當前資料推送成功，

7）故障解除時，如果之前暫停或關閉了資料接收，則將其恢復。

8）繼續從磁碟取後面未處理的資料。

9）定期觸發一個非同步執行緒去清理磁碟上推送成功的資料，保持磁碟空間良好。

其他說明：

1）儘量將多種訊息合併在一個執行緒處理，如果技術或者業務上不能在一個執行緒去處理，則另起執行緒（或程序），與其他執行緒（或程序）隔離、資料完全獨立。

2）儘量控制在單機處理，如果一臺機器不夠，則多加幾臺機器，但每臺機器處理的資料完全獨立。

3）資料快取在本地磁碟上，只是一種簡單高效的策略，但使用不夠方便，也不便於管理，如果有高可用、高效能的redis，則建議建將資料快取在redis上。次之，可以換成mysql，如果網路環境穩定，可以連遠端mysql，否則可以將mysql和應用安裝在同一臺伺服器上。另外，也可以用sqlite檔案資料庫。

B模型資料推送系統設計方案

B模型的系統，不保證資料一致性。它的關鍵詞：效能和可用性優先。

設想這種場景：

一天有1億的資料要推送出去，但是在處理某條資料的時候報錯了，且重試了3次仍然不成功，後面還有大量資料等著推送，執行緒不能阻塞，那麼只能將推送失敗的資料記錄下來，繼續處理後面來的資料。

可以在 資料推送失敗或者接收方響應非常緩慢時，將資料記錄下來（比如記日誌，供人工排查補資料；或者轉存kafka，由補償程式處理），然後繼續接收後面的資料繼續推送。

首先，我們將容易產生故障的業務和資料分類，將容易發生故障的資料與其他資料隔離，以保證發生故障時，不影響其他資料的處理。

根據業務場景，按照資料分類，用單獨的執行緒處理，做故障隔離（某個執行緒發生故障時，不影響其他執行緒）。

其次，在故障發生持續時間長，或者故障發生頻繁的場景下，可能不適合用B模型，因為B模型不保證資料一致性，故障發生得越多，資料問題就會越嚴重，處理起來越麻煩。

在推送資料專案裡，如果發生故障可能持續時間很長，資料堆積很多，有這種情況下，就不建議使用B方案。

在故障發生率低、故障持續時間短的前提下，可以如下操作：

  如果推送失敗，不要阻塞後面的資料，採用將資料記錄下來（放記憶體裡面），等後面一批資料來後，同時處理，再次推送，如果這次推送仍然失敗，則再重複這個過程，一共重試3~5次，如果都失敗則進入C方案的流程（下面會講）。

上面這個方案，可以在故障持續時間短的情況下，解決推送問題。

C模型資料推送系統設計方案

C模型的系統，不保證系統高可用，換句話說，它寧願系統不可用，也要保證在系統可用的時間段內系統的高效能和資料的強一致性。它的關鍵詞：犧牲可用性 換一致性和效能。

可以在 資料推送失敗或者接收方響應非常緩慢時，且在C方案的補償機制下，系統仍無好轉，則關閉該資料的推送，同時觸發監控程式，通知人工處理，或者由 故障處理程式 去處理。

根據具體的業務場景，如果當某類資料多次無法推送時，主動關閉該資料的推送，同時觸發監控程式，通知維護人員，由維護人員決定，是否去處理故障，如果不需要處理，則該資料就一直關閉，如果需要處理，則當故障恢復時，重新啟動該資料的推送任務。也可以由monitor主動去監控資料推送是否恢復正常，恢復正常後，自動恢復推送。

一、訊息推送系統設計需求

1、高性價比，在有限的硬體資源下，儘可能的提高訊息系統的效能和可用性。

2、提高資料的一致性。

二、分析

訊息推送，按資料量劃分，包括兩類：

1）持續的大量資料（比如：持續的物聯網GPS上報等）推送，單類資料量大於 10 kb 每秒 。

2）低頻率、資料量小的偶發事件、通知類的資料推送。

訊息重要性和實時性分級：（ “四象限” 劃分）

                            不重要                            |                          不重要

                            可延時                            |                          低延時

                            ——————————————————————

                            很重要                            |                          很重要

                            可延時                            |                          低延時

        備註：

                  很重要  =  非常重要，資料不丟、不亂。

                  不重要  =  可接受偶爾出現問題。

                  低延時  =  延時低（平均在3秒以內）。

                  可延時  =  有一定延時（3秒以上）。

大部分訊息處於 (2) (3) (4) 象限。針對訊息的特性，應採用不同效能和穩定級別的推送方案。

根據 CAP 定理：

    Consistency(一致性), 資料一致更新，所有資料變動都是同步的。

    Availability(可用性), 好的響應效能。

    Partition tolerance(分割槽容錯性) 可靠性。

    定理：任何分散式系統只可同時滿足二點，沒法三者兼顧。

沒有一個分散式系統是C、A、P同時都達到完美的，要麼損失效能來保障一致性和可用性；要麼損失一致性來提高效能。

理想模型如下：

A、犧牲 效能 來提高 可用性和一致性。

B、犧牲 一致性 來提高 效能和可用性。

C、犧牲 可用性 來提高 效能和一致性。

對於上面的 A 模型，用得非常廣泛，比如訊息的ACK機制，用法比較簡單，不多說。

對於上面的 B 模型，經常使用 BASE （犧牲高一致性，保證最終一致性） 方案。

    Basically Available 基本可用。

    Soft state 軟狀態 狀態可以有一段時間不同步，非同步。

    Eventually consistent 最終一致，最終資料是一致的就可以了，而不是實時高一致。

對於上面的 C 模型，用得比較少，也不好理解。犧牲可用性，來保證一致性和效能，我的理解是，除非服務不可用，否則服務一定是高效能且高一致性的。

也就是說，當服務不能保證一致性和高效能的時候，就降低可用性，寧願服務不可用，也不能讓服務出現不一致或者效能低的情況。

C模型的關鍵點在於，C模型的系統，系統自身不保證高可用，出現異常（效能降低或者一致性出現問題）時，它有意降低可用性，來保障服務期間的高效能和資料的強一致性。

所以如果使用C模型，則需要考慮，如何通過外部手段來保證系統的可用性（加強監控，出現不可用時，人工介入恢復，或者啟動臨時方案）。

延伸知識：分散式系統的容錯模式

電路熔斷器模式(Circuit Breaker Patten), 該模式的原理類似於家裡的電路熔斷器，如果家裡的電路發生短路，熔斷器能夠主動熔斷電路，以避免災難性損失。在分散式系統中應用電路熔斷器模式後，當目標服務慢或者大量超時，呼叫方能夠主動熔斷，以防止服務被進一步拖垮或者導致其他系統故障（雪崩效應）；如果情況又好轉了，電路又能自動恢復，這就是所謂的彈性容錯，系統有自恢復能力。

參考文章：http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service/

上面的A、B、C模型對於推送系統來說，

對於上面處於(2) 象限的訊息推送，可以考慮 能否採用上面 C模型，如果不能接受C模型的服務（暫時）不可用，則可能會降級為 A、B 模型，A模型犧牲效能，整個系統是否存在效能問題？B模型犧牲一致性，是否能採用軟狀態、最終一致性方案來彌補？

對於上面處於(3) 象限的訊息推送，宜採用 A 模型。

對於上面處於(4) 象限的訊息推送，宜採用 B 模型，A模型也可以，具體視情況而定。

A模型資料推送系統設計方案

在A模型中，效能不是關鍵。它的關鍵詞：效能不是瓶頸  資料要準確可靠

考慮點：

  1、如何保證資料100%不丟失？

  2、如何保證資料100%不重複？

不丟失：資料來後，先以最穩當的方式持久化下來，再推送出去，推送成功後，才刪掉持久化的資料，否則資料一直持久化直到超過儲存容量或者時間上限。（如果使用資料庫，可以考慮事務）

不重複：能夠識別每條資料的唯一性（最簡單的辦法就是每條資料有一個唯一標識），在記憶體資料庫中儲存一段時間已推送的資料標識（ID）的列表，當新的資料來了之後，和資料標識列表中的ID進行比較，如果存在則說明之前已經推送過這條資料，直接pass，否則推送資料並加入資料標識列表。

技術選型和系統處理資料流程：（純Java + Redis快取ID + 本地磁碟快取資料）

1）收到資料後，先將資料ID取出，去Redis裡已推送的資料ID的列表中查詢，如果找到這個ID，則說明資料已處理過，重複了，則丟棄該資料。否則繼續下面的步驟。

2）將資料和ID用Producer執行緒儘快寫入本地磁碟，以防丟失。

3）然後用Consumer執行緒將資料從磁碟讀取出來，然後嘗試推送出去。

4）如果推送成功，則標記該ID的資料為success並儲存到磁碟，然後繼續處理後面的資料。否則暫停或關閉接收 後續的資料（如果可以），如果不能暫停，則直接進入下面的第(5)步驟），

5）無限嘗試推送當前資料，直到故障解除，當前資料推送成功，

7）故障解除時，如果之前暫停或關閉了資料接收，則將其恢復。

8）繼續從磁碟取後面未處理的資料。

9）定期觸發一個非同步執行緒去清理磁碟上推送成功的資料，保持磁碟空間良好。

其他說明：

1）儘量將多種訊息合併在一個執行緒處理，如果技術或者業務上不能在一個執行緒去處理，則另起執行緒（或程序），與其他執行緒（或程序）隔離、資料完全獨立。

2）儘量控制在單機處理，如果一臺機器不夠，則多加幾臺機器，但每臺機器處理的資料完全獨立。

3）資料快取在本地磁碟上，只是一種簡單高效的策略，但使用不夠方便，也不便於管理，如果有高可用、高效能的redis，則建議建將資料快取在redis上。次之，可以換成mysql，如果網路環境穩定，可以連遠端mysql，否則可以將mysql和應用安裝在同一臺伺服器上。另外，也可以用sqlite檔案資料庫。

B模型資料推送系統設計方案

B模型的系統，不保證資料一致性。它的關鍵詞：效能和可用性優先。

設想這種場景：

一天有1億的資料要推送出去，但是在處理某條資料的時候報錯了，且重試了3次仍然不成功，後面還有大量資料等著推送，執行緒不能阻塞，那麼只能將推送失敗的資料記錄下來，繼續處理後面來的資料。

可以在 資料推送失敗或者接收方響應非常緩慢時，將資料記錄下來（比如記日誌，供人工排查補資料；或者轉存kafka，由補償程式處理），然後繼續接收後面的資料繼續推送。

首先，我們將容易產生故障的業務和資料分類，將容易發生故障的資料與其他資料隔離，以保證發生故障時，不影響其他資料的處理。

根據業務場景，按照資料分類，用單獨的執行緒處理，做故障隔離（某個執行緒發生故障時，不影響其他執行緒）。

其次，在故障發生持續時間長，或者故障發生頻繁的場景下，可能不適合用B模型，因為B模型不保證資料一致性，故障發生得越多，資料問題就會越嚴重，處理起來越麻煩。

在推送資料專案裡，如果發生故障可能持續時間很長，資料堆積很多，有這種情況下，就不建議使用B方案。

在故障發生率低、故障持續時間短的前提下，可以如下操作：

  如果推送失敗，不要阻塞後面的資料，採用將資料記錄下來（放記憶體裡面），等後面一批資料來後，同時處理，再次推送，如果這次推送仍然失敗，則再重複這個過程，一共重試3~5次，如果都失敗則進入C方案的流程（下面會講）。

上面這個方案，可以在故障持續時間短的情況下，解決推送問題。

C模型資料推送系統設計方案

C模型的系統，不保證系統高可用，換句話說，它寧願系統不可用，也要保證在系統可用的時間段內系統的高效能和資料的強一致性。它的關鍵詞：犧牲可用性 換一致性和效能。

可以在 資料推送失敗或者接收方響應非常緩慢時，且在C方案的補償機制下，系統仍無好轉，則關閉該資料的推送，同時觸發監控程式，通知人工處理，或者由 故障處理程式 去處理。

根據具體的業務場景，如果當某類資料多次無法推送時，主動關閉該資料的推送，同時觸發監控程式，通知維護人員，由維護人員決定，是否去處理故障，如果不需要處理，則該資料就一直關閉，如果需要處理，則當故障恢復時，重新啟動該資料的推送任務。也可以由monitor主動去監控資料推送是否恢復正常，恢復正常後，自動恢復推送。