摘要:狀態機有三個特征狀態總數是有限的。由于有限狀態機的這些特征,我們可以把狀態轉移的過程做成類似這樣的狀態轉移表。
有限狀態機是什么
有限狀態機(英語:finite-state machine,縮寫:FSM)又稱有限狀態自動機,簡稱狀態機,是表示有限個狀態(State)以及在這些狀態之間的轉移(Transition)和動作(Action)等行為的數學模型。
狀態機有三個特征:
狀態(State)總數是有限的。
在任一時刻,只處于一種狀態。
在某種條件(Event)下,會從某種狀態轉移(Transition)到另一種狀態,同時執行某個動作(Action)。
從有限狀態機的定義和特征我們可以看到它的幾個重要概念:
狀態(State):包括初始狀態和事件觸發后的狀態,同時必須要有一個最終狀態。
事件(Event):觸發狀態機從一種狀態切換到另一種狀態。
轉移(Transition):狀態切換路徑,包含Event(觸發該轉移的事件),Source(源狀態),Target(目的狀態)。
動作(Action):表示在進行狀態轉移后要執行的具體行為。
由于有限狀態機的這些特征,我們可以把狀態轉移的過程做成類似這樣的狀態轉移表。
條件當前狀態 | 狀態A | 狀態B | 狀態C | 狀態D |
---|---|---|---|---|
條件X | 狀態B | 狀態C | 狀態D | ... |
條件Y | 狀態C | 狀態D | ... | ... |
條件Z | ... | 狀態A | 狀態A | 狀態A |
可以歸納為一個公式。
Old State + Event = New State
把上面的狀態轉移表用公式表達就是
狀態A + 條件X = 狀態B
狀態A + 條件Y = 狀態C
...
我們小時候都應該玩過貪吃蛇這個游戲,游戲規則不必再說,我們看看使用有限狀態機來實現這個游戲。
狀態轉移表:
條件當前狀態 | GAME_OVER | UP | DOWN | LEFT | RIGHT |
---|---|---|---|---|---|
EAT | ... | UP | DOWN | LEFT | RIGHT |
HIT | ... | GAME_OVER | GAME_OVER | GAME_OVER | GAME_OVER |
TURN_UP | UP | ... | ... | UP | UP |
TURN_DOWN | DOWN | ... | ... | DOWN | DOWN |
TURN_LEFT | LEFT | LEFT | LEFT | ... | ... |
TURN_RIGHT | RIGHT | RIGHT | RIGHT | ... | ... |
EAT:吃掉食物
HIT:撞墻或自己
TURN_UP:向上轉向事件
...
GAME_OVER: 為了簡便一點,我們讓它既是開始又是結束的狀態,當按下上下左右任一鍵時開始游戲。
UP: 向上前進狀態,此時可以吃掉食物,也可以撞到墻或自己,同時可以向左向右轉向,但按下向上或向下是不會觸發任何動作。
...
當我們把狀態轉移表定義好之后就會發現這個游戲剩下的部分非常好寫,而且邏輯非常清楚,這就是有限狀態機的好處。
有限狀態機在編程中有哪些應用詞法分析
正則表達式
網絡協議
游戲設計
自動電話客服
...
我們用有限狀態機做什么筆者目前所在的部門是正在使用OpenStack做電子網絡靶場的一個項目,必然少不了對虛擬機各項指標的采集,因此對采集進行監控也是必要的措施,以便在采集故障之后及時預警。
整個監控流程是由客戶端(Java微服務)往Kafka中發一條采集配置,采集端(Python)收到這條配置后進行解析配置,然后進行指標采集,同時往Kafka回傳一些運行信息,當想要停止采集時需要客戶端再次下發一條關閉配置,采集端進行執行并回傳至Kafka關閉信息。
看似這個過程十分簡單,像把大象裝進冰箱一樣簡單。
打開冰箱門。
把大象塞進行。
關上冰箱門。
使用有限狀態機來做其中的狀態轉移時真的就像是把大象塞進冰箱一樣簡單(其中使用restful接口接收客戶端的開始關閉配置,監聽kafka指定topic來處理采集端消息)。
定義狀態轉移表條件當前狀態 | Idle | processing | wait_close | exception | timeout | closed |
---|---|---|---|---|---|---|
start_conf | ||||||
error_conf | closed | |||||
pro_start | processing | |||||
heartbeat | processing | processing | ||||
error_runtime | exception | |||||
stop_conf | wait_close | wait_close | wait_close | |||
pro_stop | closed | closed | closed | |||
msg_timeout | timeout | timeout | timeout | timeout | ||
fix | closed |
事件
start_conf:客戶端(Java微服務)采集配置
error_conf:采集端(Python)配置解析錯誤
pro_start:采集端(Python)開始采集
heartbeat:采集端(Python)正在采集
error_runtime :采集端(Python)采集過程中出錯
stop_conf:客戶端(Java微服務)關閉配置
pro_stop: 采集端(Python)退出采集
msg_timeout:采集端(Python)消息超時
fix: 監控端 手動確認任務已經人為修復
狀態
Idle:收到采集配置后有限狀態機的默認狀態
processing:正在采集
wait_close :收到關閉配置后等待關閉
exception:采集異常
timeout:超時
closed:采集關閉
使用狀態機進行編碼筆者這里使用的庫是squirrel-foundation,支持多實例狀態機并且和spring進行整合也比較簡單。
總結有限狀態機能使我們從復雜的狀態轉移判斷中脫離出來,專心業務邏輯,并且避免狀態轉移過程的判斷錯誤,是一種很強大的模型。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/41050.html
摘要:前端與狀態現在的前端開發中,對于狀態的管理是重中之重。有限狀態機那么如何更好的管理前端軟件的復雜度的狀態機思想給出了自己的答案。有限狀態機并不是一個復雜的概念簡單說,它有三個特征狀態總數是有限的。 前提 在現在的前端社區,關于MVVM、Model driven view 之類的概念,已經算是非常普及了。React/Vue 這類框架可以算是代表。而自己雖然有 React/Vue 的使用經...
摘要:有限狀態機可以歸納出四個要素現態即當前的狀態。但狀態模式還有一點需要注意到,當采用子類繼承實現多種具體狀態的時候,注意控制狀態的數量,以免出現子類數量膨脹的現象在使用或等更完整面向對象語言時。 業務代碼開發久了,偶爾看看設計模式,總會讓自己有一種清新脫俗的感覺。總想把這種感覺記下來,但一想到要先起個恰如其分的標題和開頭,就讓我有一種百爪撓心的糾結,所以遲遲沒有開始。今天起更新我學習設計...
地址的識別和分析是本地搜索必不可少的技術,盡管有許多識別和分析地址的方法,最有效的是有限狀態機。一個有限狀態機是一個特殊的有向圖(參見有關圖論的系列),它包括一些狀態(節點)和連接這些狀態的有向弧。下圖是一個識別中國地址的有限狀態機的簡單的例子。每一個有限狀態機都有一個啟始狀態和一個終止狀態和若干中間狀態。每一條弧上帶有從一個狀態進入下一個狀態的條件。比如,在上圖中,當前的狀態是省,如果遇到一個詞...
閱讀 1854·2021-09-23 11:21
閱讀 703·2019-08-30 15:55
閱讀 838·2019-08-29 15:40
閱讀 535·2019-08-29 12:56
閱讀 3167·2019-08-26 12:00
閱讀 3559·2019-08-23 18:24
閱讀 2253·2019-08-23 17:08
閱讀 1642·2019-08-23 17:03