前言
在大型的分布式系统中,经常会涉及到状态的改变,这里的状态变化可以分很多种,最极端的情况是,任何状态之间都可以互相切换。这种状态之间的切换,转变,更加官方一点的称为叫状态机。这个词可能很多人会感到比较陌生,英文就是State Machine。所以如果大家在学习开源项目中,看到这个单词,指的就是状态机的意思。那么状态机有什么用途呢,为什么我们要定义这样一个概念呢?本文笔者就来简单聊聊状态机的管理。
状态机有何用
我们老是说状态机,状态机,那么它到底有何用呢?答案很简单,5个字:状态机管理。很明显,它的用途在于状态的管理。可能有些人会觉得奇怪,为什么需要引入状态机的概率来管理状态呢,一种简单的做法是在特定的条件下特定状态的更新,不就OK了吗。比如说下面这种方式:
switch(State s)
case s1:
s.setState(NewState1)
case s2:
s.setState(NewState2)
case s3:
s.setState(NewState3)
...
以上这种通过if语句或switch语句在条件判断,然后进行状态改变的逻辑,从原理上来说并没有错。但是大家想一想,如果系统够复杂,中间涉及的状态足够多,而且每个不同状态切换所需要的判定条件(这里可理解为触发的event事件)又不同,那么这种方式会带来很大的弊端,
状态多的情况下容易出错,而且维护成本很高,如果未来要更改状态规则的时候,无法全局修改。无法清晰了解整个状态变化过程。
所以在拥有复杂状态变化的情况下,我们一般的做法都是引入状态机管理对象,来专门做状态的更新。那么我们如何定义状态机管理对象呢?接着往下看。
状态机对象如何定义
在定义这个类对象之前,一般我们要先设计好系统的状态变化图,里面应该包含2大元素信息:
- 1.系统所有可能出现的状态
- 2.不同状态间进行切换的触发事件(event)。
这里笔者以Ozone中的Container状态机管理为例,如下所示:
// Client-driven Create State Machine
// States: <ALLOCATED>------------->CREATING----------------->[OPEN]
// Events: (BEGIN_CREATE) | (COMPLETE_CREATE)
// |
// |(TIMEOUT)
// V
//