状态机

在编程中，幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数指的是那些使用相同参数重复执行也能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。比如说getIdCard()函数和setTrue()函数就是幂等函数。 幂等在我的理解里就是，一个操作不论被执行多少次，产生的效果和返回的结果都是一样的。 一个幂等的操作典型如：把编号为5的记录的A字段设置为0这种操作不管执行多少次都是幂等的。 一个非幂等的操作典型如：把编号为5的记录的A字段增加1这种操作显然就不是幂等的。 幂等的方案 1.查询操作：Select是天然的幂等操作。 查询一次和查询多次，在数据不变的情况下，查询的结果都是一样的。 2.删除操作：删除操作也是幂等的，删除一次和删除多次都是把数据删除。 因为删除操作通常是定向的，比如通过id去删除数据，如果该id在数据库中存在对应记录，则删除该记录；如果该id在数据库中不存在对应记录，也是执行的删除记录操作，只是没有实质性地删除到记录而已，却也不会有其他的副作用。 但是如果删除操作具有返回值的话，可能返回的结果会不一样，比如删除一条记录之后返回这条记录中的某个值，如果删除的数据不存在（已经在第一次的删除请求中被删除了），返回的就是空值了。 3.唯一索引：通过在数据库表的一个字段上建立唯一索引可以有效防止新增脏数据。

libev 是 一种 “事件驱动”的编程框架，所谓“事件驱动”，简单地说就是就是 有什么动作（点按钮、中断），程序就执行什么操作（中断服务函数、回调函数），当然事件不仅限于用于的操作，只要是定义好的，各种突发、预设的各种将要发生的事情，都是事件。这里，我对CPU相对熟悉一些，可以把“事件驱动”理解为 自定义软件中断。这里我们举几个案例来分析： 案例1： 状态机FSM 状态机是一种常用的编程框架，本质上讲，状态机也是一种事件驱动，“状态”就相当于“事件”，不同状态执行不同的代码功能，这里的代码功能就相当于 事件对应的 驱动 功能。 案例2：硬件中断 硬件中断是 最典型的 事件驱动，只不过这里的中断是CPU厂家预设的，当发生某一硬件中断时，执行对应的 中断服务函数，这里的 “中断”就是 “事件”，而 中断服务函数 就是 驱动。 案例3：功能 回调函数 我们在使用 一些 SDK 的时候，很多的SDK 都会提供 接口 和回调函数，这种回调 函数 也是事件驱动模型，只不过这些 事件 是SDK 定义好的，回调函数 是允许用户 自定义的 事件驱动 函数。 libev 提供了基本的 IO 事件、定时器事件、信号事件，这三种事件用的比较多，这里的IO就是针对 文件描述符，在Linux下，一切设备都是 文件，所以 IO 事件可以针对 所有的外设备，比如网口、socket，串口，文件等。定时器

无论是Paxos还是Raft，它们都是致力于维护一RSM(Replicated State Machine)，如上图所示。对于RSM来说，状态存储是非常关键的 (Replicated State Machine)状态机：一致性group的节点的某个时刻的状态(比如数据库里x=1,y=1是一个状态)转移可以看成自动机里的一个状态，所以叫状态机。 Replicated Log: 包含了来自客户端的用于执行在状态机上的命令(操作)。 /*--> */ /*--> */ /*--> */ /*--> */ ETCD架构图 /*--> */ /*--> */ Snapshot处理流程：https://www.jianshu.com/p/cf4f0d3ae253 /*--> */ /*--> */ 从etcd的架构图中可以看到，etcd主要分为四个部分： HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。 Store：这个模块顾名思义，就像一个商店把etcd已经准备好的各项底层支持加工起来，为用户提供五花八门的API支持，处理用户的各项请求。 用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等，是etcd对用户提供的大多数API功能的具体实现。 Raft： raft 状态机，raft强一致性算法的具体实现

一、背景 我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。 例如： 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱； 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的； 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。 等等很多重要的情况，这些逻辑都需要幂等的特性来支持。 二、幂等性概念 幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。 在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。 这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数. 更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 我的理解：幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的 三、技术方案 1. 查询操作 查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作 2. 删除操作 删除操作也是幂等的，删除一次和多次删除都是把数据删除。

SOFAStack （ S calable O pen F inancial A rchitecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠，来自中国移动。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号： SOFA:JRaftLab/ ，文末包含往期系列文章。 SOFAJRaft： https://gitee.com/sofastack/sofa-jraft 导读 本文主要介绍 SOFAJRaft 在日志复制和管理中所采用的快照机制。考虑到单独介绍 SOFAJRaft 中的快照机制原理和实现或许有一些唐突，我会先通过一个读者都能够看得明白的例子作为切入点，让大家对快照这个概念、它可以解决的主要问题，先有一个比较深刻的理解。 一、快照的概念与特点 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块

Source 幂等的概念 幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。 复制代码 在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，”getUsername()和setTrue()”函数就是一个幂等函数。 用通俗的话讲：就是针对一个操作，不管做多少次，产生效果或返回的结果都是一样的 举几个例子： 比如前端对同一表单数据的重复提交，后台应该只会产生一个结果 比如我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱 比如发送消息，也应该只发一次，同样的短信如果多次发给用户，用户会崩溃 比如创建业务订单，一次业务请求只能创建一个，不能出现创建多个订单 复制代码 还有很多诸如此类的，这些逻辑都需要幂等的特性来支持。 实现幂等性的技术方案 查询操作 查询一次和查询多次，在数据不变的情况下，查询结果是一样的，select是天然的幂等操作。 删除操作 删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个)。 唯一索引，防止新增脏数据

3． 下位机中的数据接收和协议解析 下位机接收数据也有两种方式，一、等待接收，处理器一直查询串口状态，来判断是否接收到数据。二、中断接收。两种方法的优缺点在此前的一篇关于串口通信的文章中详细讨论过。得出的结论是采用中断接收的方法比较好。 数据包的解析过程可以设置到不同的位置。如果协议比较简单，整个系统只是处理一些简单的命令，那么可以直接把数据包的解析过程放入到中断处理函数中，当收到正确的数据包的时候，置位相应的标志，在主程序中再对命令进行处理。如果协议稍微复杂，比较好的方式是将接收的数据存放于缓冲区中，主程序读取数据后进行解析。也有两种方式交叉使用的，比如一对多的系统中，首先在接收中断中解析“连接”命令，连接命令接收到后主程序进入设置状态，采用查询的方式来解析其余的协议。 以下给出具体的实例。在这个系统中，串口的命令非常简单。所有的协议全部在串口中断中进行。数据包的格式如下： 0x55, 0xAA, 0x7E, 0x12, 0xF0, 0x02, 0x23, 0x45, SUM, XOR, 0x0D 其中0x55, 0xAA, 0x7E为数据帧的帧头，0x0D为帧尾，0x12为设备的目的地址，0xF0为源地址，0x02为数据长度，后面接着两个数据0x23, 0x45，从目的地址开始结算累加、异或校验和，到数据的最后一位结束。 协议解析的目的，首先判断数据包的完整性，正确性

第三次报告： 理解Paxos协议 一、 Paxos协议背景 什么是Paxos协议？ 一般地，从客户端和服务器的角度，任何一个分布式系统都可以理解成由一个服务器集合和一个客户端集合组成，一个或多个客户端向一个或多个服务器发送命令，服务器接收到命令后，执行相应操作以提供服务。可以将每个服务器建模成一个 决定状态机 (DSM：对任意输入只有唯一状态转移路径的状态机)。它具有自身的状态，在接收到客户端的命令后，作出相应的响应，进而状态发生转移。 现在考虑一个简单的存储数据A的服务。最简单的情况下，该服务对应的服务器集合只有一个元素，也就是说只有一个服务器负责处理来自客户端的对数据A的写入。这个服务器对应的状态机的状态可以定义为： 数据A的值 。当客户端的命令到来时，服务器状态机做出响应，并导致状态转移。即使有多个客户端发送命令，因为只有单个服务器且输入是离散的，因此只需要这个服务器决定执行哪个命令。 然而，当单个服务器出现故障甚至宕机，那么这个服务就会无法使用。为避免这种情况，负责数据A存储服务的服务器集合应该包含多个服务器，这样即使其中某(几)个服务器发生故障，其它服务器应当也能提供服务。这种当系统部分出错仍能提供服务的概念被称为错误容忍(Fault tolerant)。 现在，服务器集合中的每个服务器都要维护自己的状态机。每个状态机的状态都是自己那份数据A的值。显然，由于状态机是决定的

##一：需求 RPG游戏中 角色，怪物的状态种类比较多， 因此需要对基本状态进行抽象，通过子类继承的方式来构建一个易于扩充的框架。 整体需求即是： 1：能够方便的构建新的AI 2：能够方便的增加 角色状态 3：状态代码之间 逻辑独立，修改不会产生副作用 ##二设计 核心思想是构建一个基本的状态机，通过在每个状态中填充不同的逻辑代码，来构建不同的AI行为表现，同时通过组合不同的状态构建不同的状态机结构。 ![在此输入图片描述][1] [1]: http://static.oschina.net/uploads/space/2015/0227/132157_jV0j_186074.png 首先确定有多少种大的AI状态，继承AIState 产生基本状态子类 ![在此输入图片描述][2] [2]: http://static.oschina.net/uploads/space/2015/0227/132710_XN5A_186074.png 继承这些基础子状态，构建实际的AI状态 ![在此输入图片描述][3] [3]: http://static.oschina.net/uploads/space/2015/0227/132947_KmCa_186074.png ##三接口设计和 进一步扩展性 接口设计： AICharacter是一个状态机，状态机的基本接口包括： AddState

上篇用了另一种方式构造词法分析，总体来说实现的过程比较明确，但是我们可以看到，上篇的分析仅仅只进行了少量的单词分析，如果将C语言中的32个保留字还有其他的操作符以及界限符加进入，其构造的状态机会异常的庞大，所以接下来将简化其状态机，使用查询匹配的方式，很明显这种方式有很大的确定，在该系列博客第一篇谈到，但是对于C语言这样的来说，构造完全的状态机太费事了，所以这也是一种取舍的方式。 下面是简化版的状态机，注意：该状态机只能区分单词的种类，单词的ID是通过遍历比较匹配得到的。 下面由于时间关系暂时先写到这，后面会继续写。 来源： https://www.cnblogs.com/listenscience/p/11935380.html