消息隊列數(shù)據(jù)流
這部分會簡要介紹一種異步消息傳遞系統(tǒng)，在某種意義上講是在數(shù)據(jù)庫和RPC的折中方案。他與RPC相似點在于都是一個客戶端用一個很短的延遲將請求傳遞給另一個進程。他與數(shù)據(jù)庫相似點在于他并不是通過網(wǎng)絡直接將數(shù)據(jù)發(fā)送給對方進程，而是通過一個消息傳遞代理,message broker，broker可以臨時儲存消息。跟RPC相比，消息隊列有幾個明顯的好處
- 當接收方臨時不可用時，broker可以充當緩存臨時將消息儲存起來，這就提高了整個系統(tǒng)的可靠性。
- 當一個處理進程崩潰后，他能夠自動的將沒處理的消息重新發(fā)給另一個處理進程，使得消息不會丟失。
- 發(fā)送客戶端不在需要知道接收進程的ip和端口號，這在云端部署的時候特別有用
- 允許一個消息發(fā)送給多個接收方
- 在邏輯層面上將客戶端和服務器，在消息隊列中我們稱為發(fā)送者和接收方，進行了解耦。發(fā)送發(fā)只需要發(fā)布消息，而不再關(guān)心誰去消費這些消息
但是有一個問題和RPC不太相同，消息隊列只是單向的。也就是說發(fā)送方?jīng)]辦法指望從接收方獲得什么反饋。如果硬要發(fā)送反饋也是可以，但是一般都是通過另外一個消息通道完成的，也就是說這是一個異步的過程。發(fā)送方只管發(fā)送消息，不管這個消息是不是已經(jīng)投遞給了接收方或者是不是已經(jīng)處理過了。發(fā)完了就不管了。
message broker（消息傳遞中間件）
過去這個組件都被大型商業(yè)公司承保了，但是現(xiàn)在有很多開源工具可供選擇，RabbitMQ, ActiveMQ, HornetQ, NATS, Apache Kafka 都是比較有名的工具。消息隊列的實現(xiàn)細節(jié)在不同項目中都不相同，總的來說都是這么一個流程。一個進程將消息發(fā)送到一個指定名字的隊列(queue)或者主題(topic)中， broker保證消息能夠至少傳遞給一個消費者(consumer) 或者訂閱者(subscribers), 對于同一個topic，可能會有多個生產(chǎn)者和消費者。
一個topic一般都是單向的數(shù)據(jù)流，但是消費者可能同時需要發(fā)布消息給另一個消費者，這就形成了一個生產(chǎn)消費鏈，上級發(fā)送消息給下一級，下一級再生產(chǎn)消息給下下一級?；蛘呦M者需要把消息發(fā)送到反饋隊列傳給發(fā)布者，這就和RPC的request/response模式很像了。
message broker不對數(shù)據(jù)模型有任何要求，因為一個消息只是一個字節(jié)流兒加一個metadata而已，所以你可以使用任意編碼格式。如果你的編碼能夠做到向前向后兼容，那就就獲得了極大的靈活性。你可以任意的修改你的發(fā)布者和消費者，或者按照任意順序去部署他們。
如果你的消費者需要再發(fā)布一個消息到他的下游，你需要注意保留那些未知字段，就好像之前數(shù)據(jù)庫遇到的問題一樣，不要出現(xiàn)把新加的未知字段搞丟的情況出現(xiàn)。
分布式actor框架
actor model 是一種編程模型，他能讓你編寫的單進程得程序獲得并發(fā)的效果。每個線程在邏輯層面封裝成一個actor.每個actor實際代表一個線程或者某一個實體。這些實體擁有自己的內(nèi)部狀態(tài)，這些狀態(tài)并不與外界共享，他們通過異步發(fā)送和接收消息的方式和其他actor進行通信。消息的傳輸是不可靠的，在特定的場景下，消息是可能丟失的。每個actor每次只處理一個消息，所以也不用操心什么多線程的問題，那些死鎖或者其他奇奇怪怪的問題都不用擔心了。 另外每個actor可以由框架獨立部署。
在分布式actor框架下(distributed actor frameworks), 這個編程模型可以方便的把一個應用部署成多機應用。無論消息的發(fā)送者和接收者是不是在同一個節(jié)點上，他們都是用相同的消息傳輸機制。如果在不同節(jié)點上，那就會消息編碼成字節(jié)流，發(fā)送到對應節(jié)點然后進行解碼處理。
actor model相比RPC，有著更好的位置透明性，也就是你不再需要關(guān)心你的接收方到底是跟你在同一個機器上，還是不在。因為actor model本身就假設(shè)消息是可能會丟的，所以有些事情模型框架就幫你處理了。盡管消息如果通過網(wǎng)絡進行傳輸，在延遲上會比在單機上處理慢，但是整體上來說，本地和遠程通信在actor model下的區(qū)別還是要少一些的。
一個分布式的actor框架就是把一個broker和一個actor model集成為一個框架。盡管如此，如果你想做到灰度更新，你還是需要擔心向前向后兼容的問題。
下面是3個主流的框架，
- Akka使用java默認的編解碼庫，并不提供向前向后兼容性。但是你可以把它編碼庫替換掉，比如用Protocol Buffer就可以支持灰度更新了。
- Orleans默認情況下使用自定義的編碼格式，無法支持灰度更新。如果你要更新你的數(shù)據(jù)格式，你需要啟用一個新的消息集群，把老的集群的消息導到新的上面，然后停掉老的(這簡直了啊！)但是他和Akka一樣，可以替換掉默認的編碼庫
- Erlang OTP，十分令人吃驚，修改消息的schema是一個異常困難的事情。灰度更新雖然可以，但是要十分十分的小心。一種目前還在試驗的數(shù)據(jù)類型，map，可能會讓他在未來方便一些。
