状态机

转：http://feixiao.github.io/ Raft是什么？ 一致性算法允许一组机器像一个整体一样工作，即使其中一些机器出现故障也能够继续工作下去。 一致性算法是从复制状态机的背景下提出的。在这种方法中，一组服务器上的状态机产生相同状态的副本，并且在一些机器宕掉的情况下也可以继续运行。复制状态机在分布式系统中被用于解决很多容错的问题。 Raft 是一种为了管理复制日志的一致性算法。 Raft 一致性算法 Raft 通过选举一个高贵的领导人，然后给予他全部的管理复制日志的责任来实现一致性。领导人从客户端接收日志条目，把日志条目复制到其他服务器上，并且当保证安全性的时候告诉其他的服务器应用日志条目到他们的状态机中。拥有一个领导人大大简化了对复制日志的管理。 通过领导人的方式，Raft 将一致性问题分解成了三个相对独立的子问题。 领导选举：一个新的领导人需要被选举出来，当先存的领导人宕机的时候 日志复制：领导人必须从客户端接收日志然后复制到集群中的其他节点，并且强制要求其他节点的日志保持和自己相同。 安全性：如果有任何的服务器节点已经应用了一个确定的日志条目到它的状态机中，那么其他服务器节点不能在同一个日志索引位置应用一个不同的指令。（？？？怎么理解？） Raft 基础 一个 Raft 集群包含若干个服务器节点；通常是5个，这允许整个系统容忍2个节点的失效。在任何时刻

sofia模块在freeswitch中的位置非常重要， 所有的sip通话都和它有关, 那么我们就看一下该模块的执行流程。 一、 实现的功能： 1. sip注册; 2. 呼叫; 3. Presence; 4. SLA， 等。 二、 主要的方法， 有三个， 分别为： [cpp] view plain copy #define SWITCH_MODULE_LOAD_FUNCTION(name) switch_status_t name SWITCH_MODULE_LOAD_ARGS #define SWITCH_MODULE_RUNTIME_FUNCTION(name) switch_status_t name SWITCH_MODULE_RUNTIME_ARGS #define SWITCH_MODULE_SHUTDOWN_FUNCTION(name) switch_status_t name SWITCH_MODULE_SHUTDOWN_ARGS [cpp] view plain copy </pre><pre name= "code" class= "cpp">SWITCH_MODULE_LOAD_FUNCTION(mod_sofia_load); SWITCH_MODULE_SHUTDOWN_FUNCTION(mod_sofia_shutdown); SWITCH_MODULE

事件 static QEvt const *tableQueueSto[N_PHILO]; 本事件精妙之处在于使用地址而不是实际的事件，通过指向地址，事件可以任意扩展。 订阅 static QSubscrList subscrSto[MAX_PUB_SIG]; 订阅的好处不用在驱动中写发送消息，在订阅任务中不需要写发送任务，可以减少程序之间的耦合。 MAX_PUB_SIG 是最大消息数目。 软件定时器 QTicker_ctor(&l_ticker0, 0U); /* ticker AO for tick rate 0 */ 软件定时器初始化。 // 启动软件定时器任务 QACTIVE_START(the_Ticker0, (uint_fast8_t)(N_PHILO + 1), 0, 0, 0, 0, 0); 在QPC中增加了 任务实现实现软件定时器，代码看起来稍微冗杂了一点，实际是在定时中断中 发送了一个基准消息给指定的任务，任务再去处理，而不是原来必须在中断中处理，这样做可以让中断只作为响应而不作为处理。 另外一个一直在中断中处理，定时器消息可以选择有无缓冲区，一个缓冲区还是多个缓冲区。 意思只要定义了事件队列就定义了至少一个元素，不要去修改别人的代码，看不懂证明还没有理解到。 尤其是嵌套部分比较复杂，程序执行很多层状态机，然后再出去。 事件队列，这个比较特别

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 最近 Spring 家族又填新丁 —— Spring Statemachine，Spring 状态机： Spring Statemachine 1.0.0 Released http://spring.io/blog/2015/10/13/spring-statemachine-1-0-0-released Spring Statemachine Homepage http://projects.spring.io/spring-statemachine/ 之所以介绍这个项目是因为状态机是一个解决某些复杂逻辑的不错的选择。之前在做一个即时通信项目的时候就大量使用了状态机的设计。原因也很简单，就是系统中存在大量各式各样的状态，以及能使系统在这些状态之间转换的事件。采用状态机的设计便是自然而然的事情。 但是当时我们项目的状态机实现并不好，复杂笨重。其中一个缺点是，状态转换的定义语法复杂，可读性差。但无奈当时市面上并没有太好的通用的状态机框架可供使用。后来无意间发现了 Apache Mina 中的状态机实现其实还不错，用法简单。所以后来就参考 Mina 实现了一个可用 Annotation 定义事件 Transaction 的状态机实现，并用它改进项目中设计。当然后来因为换工作，这些改进就没有继续。 当然，用

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 介绍 Spring状态机为程序开发员提供了传统状态机和Spring应用程序使用，有以下特性： 易于使用的状态机的用例 层次的状态机结构缓解复杂状态机的配置 状态机提供更复杂的配置状态 使用触发器、转移、警卫以及动作 类型安全的配置适配器 状态机的事件监听器 IOC将状态机和bean整合 名词解释 State Machine 将状态结合、转移、事件整合到一起 State 一个不变的状态模型 主要由一个事件修改实体的状态 Extended State 扩展状态是一组特殊的变量保存在一个状态机来减少所需的数据量。 Transition 源状态和目标状态之间的关系，它可能是复合过度的一部分，将状态机配置从一个状态到另一个地方,响应状态机的一个特定类型的事件的发生。 Event 一个实体发送一个状态驱动各个状态的变化 Initial State 状态机特殊的开始状态. 初始状态标记在一个状态或者一个区域上. 一个状态的多个区域都可能回到初始状态 End State 一种最终状态，一种特殊的状态表示完成封闭区域，如果封闭区域直接包含在一个状态机状态机和其他地区也完成了，然后它意味着整个状态机完成。 History State 伪状态可以记住它的最后活动的状态， 存在两种类型历史状态. Choice State

QP简介　　 　　QP（Quantum Platform）是一个轻量级的、开源的、基于状态机的、事件驱动型应用程序框架。这个框架包括四部分： 　事件处理器(QEP)； 　轻量级的事件驱动框架(QF)； 任务调度微内核(QV、QK、QXK)； 　　实时跟踪调试器(QS)。 （1）QEP 　　Quantum Event Processor是一个通用的，可移植的，可重用的状态机引擎。 　　QEP允许你直接把UML样式的状态图映射为代码。 　　QEP提供了传统的简单平面状态机和层次式状态机。QEP可以直接操作事队列和事件分发机制。 （2）QF 　　QF是一个通用的，事件驱动的应用框架，是一个实时框架，面向嵌入式系统。 　　QF被设计成和QEP，RTOS协同工作。 　　QF包含了事件队列，活动对象，事件遍历等。 （3）QK 　　QK是一个轻量级可抢占型实时内核 　　QK是一个极小的，按RTC习惯的，执行独立任务的内核。 　　QK必须和QF版本相匹配。 （4）QS 　　一个强大的调试工具 QEP (Hierarchical Event Processor） 　　事件处理器，也可以理解为一个状态机引擎，当有事件需要处理时，调用当前状态的状态函数处理这个事件，并处理调用状态函数的返回值，根据返回值进行相应的状态变换(如转移到父状态)。而且状态引擎也处理某状态的进入(ENTER)、退出(EXIT)

constructor()：构造函数 执行：组件加载钱最先调用一次，仅调用一次。 作用：定义状态机变量。 注意：第一个语句必须为super(), 否则会报错： 'this' is not allowed before super() constructor(props) { super(props); this.state = { content:null, } } componentWillMount() 执行：组件初始渲染(render()被调用前)前调用，仅调用一次。 作用：如果这个函数调用的setState改变了组件的某些状态，react会等待setState完成后再渲染组件。 注意：子组件也有componentWillMount函数，在父组件的该函数调用后再调用。 render() 执行：componentWillMount调用之后， componentDidMount调用之前。 作用：渲染挂载组件。 触发：1、初始化加载页面，2、状态机改变setState，3、接收新的props（父组件更新） 注意：组件必要函数，不能在函数内使用setState改变状态机。 componentDidMount() 时间：render之后被调用，仅调用一次。 作用：渲染挂载组件，可以使用refs(react支持的一个特殊属性，可以将它加在render函数返回的组件元素上，起一个标记作用

简单介绍构建游戏AI所需要的一些工具：状态机，层次状态机，行为树的区别以及联系 Finite State Machines(有限状态机） 1. 基本节点是状态。他包含了一系列运行在该状态的行为以及离开这个状态的条件。 2. 这是图。状态可以任意跳转,实现简单,但是对于大的状态机很难维护.状态逻辑的重用性低. 3. 每一个状态的逻辑会随着一些新状态的增加而越来越复杂。维持状态的数量和状态逻辑复杂性是一个很大的难点。需要合理的分割以及重用状态。 4. 状态机状态的复用性很差，一旦一些因素变化导致这个环境发生变化。你只能新增一个状态，并且给这个新状态添加连接他以及其他状态的跳转逻辑 5. 状态机的跳转条件一旦不满足，就会一直卡在某一个状态（整个状态机就会卡住） Hierarchical FSM(层次状态机) 1. 基本的概念和状态机一样。 2. 可以将一些状态节点的归结成一个超级状态（Super-States），共享一些状态跳转逻辑（Generalized Transitions）。相对于状态机，它主要提供了可重用得跳转条件。 3. 绝大多数层次状态机设计的时候，每一个子状态通常只包含在一个Super-States里面。(如果A,B两个Super-State都包含相同的子状态，则A,B分别添加两个不同的子状态实例) 4. 超级状态跳转依然需要考虑很多不同的子状态的情况

在分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本（replica）, 这些副本会放置在不同的节点上。这些数据节点可能是物理机器，也可能是虚拟机。为了对用户提供正确的CURD等语意，我们需要保证这些放置在不同节点上的副本是一致的，这就涉及分布式事务的问题。 本文介绍分布式事务处理方案之一的两阶段提交协议。 分布式事务 分布式事务是指发生在多个数据节点之间的事务，分布式事务比单机事务要复杂的多。在分布式系统中，各个节点之间在是相互独立的，需要通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确地知道其他节点的事务执行情况。所以从理论上来讲，两个节点的数据是无法达到一致的状态。如果想让分布式部署的多个节点中的数据保持一致性，那么就要保证在所有节点数据的写操作，要么全部都执行，要么全部都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果，所以它也就不知道本次事务到底应该commit还是rollback。所以，常规的解决办法就是引入一个"协调者"的组件来统一调度所有分布式节点的执行。 为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议（Two Phase Commitment Protocol）

基于定时器扫描的状态机按键，实现单击、双击、长按、短长按、超长按的按键识别 说明 本按键例程是基于10ms的定时器扫描，实现了单击、双击、长按、短长按、超长按的按键识别。希望对你也有帮助。 使用说明： 传入一个读取按键管脚电平的函数指针 该函数为返回bool类型，调用参数void 指针赋值给read_key 本例程按键管脚电平低为按下 若电平高为按下，则将返回值取反 注意自己需要提前做好GPIO初始化，设定管脚为输入等 参考如下： bool read_key1 ( void ) // 读按键1管脚电平 { return HAL_GPIO_ReadPin ( KEY0_GPIO_Port , KEY0_Pin ) ; } bool read_key1 ( void ) // 读按键1管脚电平 { return nrf_gpio_pin_read ( KEY1_PIN ) ; } 传入一个按键回调事件的函数指针 该函数为返回void类型，调用参数void 指针赋值给single_click_callback、long_press_callback、double_click_callback、short_long_press_callback、long_long_press_callback 参考如下： void main_key_release_handle ( void ) //