高併發解決方案之Actor——第一節

還在爲狀態的併發控制而痛苦嗎？

 

還在由於數據庫瓶頸而痛苦嗎？

 

還在由於緩存的實時性控制而痛苦嗎？

 

還在爲了想分佈式，但又不知道怎麼下手而痛苦嗎？

 

Actor適合你！！！

 

1、什麼是Actor?

 

Actor提供了一個簡單的方式來構建無鎖分佈式大規模的應用程序,而不須要學習和應用複雜的併發和分佈式控制，先以電商場景爲例進行簡單介紹：

 

　　 商品庫：商品庫是電商的核心，商品庫裏包含成千上萬個商品。

 

　　 歷史問題：每一個商品須要提供高併發訪問，因此通常採用分佈式緩存，但分佈式緩存又引入狀態同步（庫存減小，價格變更)問題，這時候就須要如何精準快速的更新緩存。

　　 Actor解決問題：

　　1： 不在須要分佈式緩存 

　　　　每一個商品做爲一個有狀態的Actor存在集羣當中，成千上萬個商品會分散於整個集羣中，咱們不須要考慮某個商品存在於那個節點，咱們只須要經過商品ID就能直接訪問到集羣內存中的商品狀態，同時咱們還無需考慮節點失效的問題，當節點失效後，Actor集羣會自動把失效節點的商品Actor轉移到其它節點，對訪問者來講整個過程都是透明的。

 

　　2： 庫存減小再也不須要鎖和隊列。

　　　Actor是以單線程存在的，全部消息都是順序到達的(做特殊標記可讓讀消息併發到達，提升訪問吞吐)，多個訂單對庫存的操做不會形成併發狀態問題。

　　

　 　購物車：匿名用戶和會員都有可能產生一個購物車，購物車的響應速度，直接影響了用戶體驗。

 

　　 歷史問題：每次刷新頁面，都須要讀取用戶的購物車信息，若是每次都從DB獲取，將會存在很大問題，因此一半狀況，每一個購物車都會存在於緩存中，但也會引入緩存同步問題。另外購物車每次增減商品都會進行復雜的訂單計算(滿減，運費，折扣等等)，每次計算還須要考慮併發問題，同時計算完還須要及時更新緩存，整個流程複雜繁瑣，控制麻煩。

 

　　 ctor解決問題：每一個購物車做爲一個有狀態的Actor存在集羣的緩存中，每次訪問能夠直接從緩存中讀取到購物車數據。當用戶增減商品的時候，直接在緩存中完成計算，並直接完成狀態變動。

　　　　　　　　　　

總結：

 

Actor是分佈式存在的內存狀態及單線程計算單元，一個Id對應的Actor只會在集羣種存在一個（有狀態的 Actor在集羣中一個Id只會存在一個實例，無狀態的可配置爲根據流量存在多個）,使用者只須要經過Id就能隨時訪問不須要關注該Actor在集羣的什麼位置。單線程計算單元又保證了消息的順序到達,不存在Actor內部狀態競用問題。

 

　　這個特性讓你能夠很容易的開發一套高併發分佈式的高拓展系統，並且不用關注併發和分佈式控制。

 

 

Actor是永久存在的,一段時間沒有消息,Actor會失活,從內存中釋放,但只要有消息就會立刻激活,但激活過程對訪問者透明。

 

　　這個特性能很好的利用系統資源，並且提供了很友好的拓展，開發者能夠在Actor失活時作一些自定義操做(例如保存狀態),在激活時也能夠作自定義操做(例如加載狀態)

 

 

Actor和DDD,CQRS,Event Soucing設計模型有自然的融合性,基於Actor能夠很好的進行以上實踐.