精华内容
下载资源
问答
  • 1、局部异常 2、全局异常 1. 单例模式 单列模式的关键就是在系统运行期间,某个类有且只有一个实例,好处就在于可以对资源重复的利用,节约重复创建和销毁的成本。 注:实现方式前提要私有化无参构造 1、...

    1. 1、单列模式

    		1、懒汉模式
    		2、饿汉模式
    		3、静态内部类
    

    2. 1、异常处理

    		1、局部异常
    		2、全局异常
    

    1. 单例模式

    单列模式的关键就是在系统运行期间,某个类有且只有一个实例,好处就在于可以对资源重复的利用,节约重复创建和销毁的成本。
    
      注:实现方式前提要私有化无参构造
    
    1. 1、懒汉模式

      public class Single{
      	
      	//接收自己的实例
      	private static Single single ;	
      
      	//私有化构造,外部不能直接实例
      	private Single(){
      	
      	}   
      
      	//外部通过该静态方法,实例化对象,如果为空 则实例化,
      	//不为空 则 返回原有的
          public static Single getSingle(){
              if (single == null){
                  single = new Single ();
              }
              return single ;
          }				
      
      }
      

    注意:懒汉模式相对比较简洁,但是要考虑线程并发的问题,如果是多个线程,安全性就不高,但是可以使用同步锁修饰,Synchronize ,安全性虽然高了,但是因为加锁,所以性能会没有之前那么好。

    1. 2、饿汉模式

      public class Single{
      
      	//自己先实例化
      	private static Single single = new Single();	
      
      	//私有化构造,外部不能直接实例
      	private Single(){
      	
      	}   
      
      	//外部通过该静态方法,获取对象
          public static Single getSingle(){
              return single ;
          }				
      
      }
      

    注意:饿汉模式因为自己开始就已经实例化好了,要用直接调用方法就可以了,不用考虑安全性,性能比较好,但是也有缺陷,因为是一开始不管用不用都会实例化一次,所以如果你要是不用,就会造成浪费。

    1. 3、静态内部类

      	public class Single{
      
      		//接收自己
      		private static Single single;	
      	
      		//私有化构造,外部不能直接实例
      		private Single(){
      		
      		}   
      		//静态内部类
      		public static class SingleHelper{
      				private static final Single INSTANCE = new Single();
      		}
      	
      	    public static Single getSingle(){
      	    	single = SingleHelper.INSTANCE ;
      	        return single ;
      	    }			
      		public static Single test(){
      			return single;
      		}	
      	
      	}
      

    利用懒加载机制保证初始化SingleHelper.INSTANCE 时只有一个线程,这种方式不会一开始就初始化,而是要你主动调用 getSingle()方法时才会装载,保证了线程安全,又避免了同步带来的性能影响。

    2、异常处理

    1. 1、局部异常处理
      Spring MVC框架的局部异常处理使用@ExceptionHandler注解实现,它的作用范围就是,写这个注解的Controller

      	//捕获异常信息,跳转到你指定的页面
      	//value= 你要捕获的异常
      	@ExceptionHandler( value = (RuntimeException.class) )
      	public String handlerException(RuntimeException e, HttpServletRequest req){
      		//将异常信息储存到Request作用域
      		req.setAttribute('e',e);
      		//你要跳转的错误页面
      		return "error";
      	}
      
    2. 2、全局异常处理
      全局异常处理是指将应用程序中抛出的所有异常统一处理的一种机制,使用SimpleMappingExceptionResolver类实现,需要在你的springmvc.xml文件中配置全局异常处理代码。

      	<beanclass="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
              <property name="exceptionMappings">
                  <props>
                      <prop key="java.lang.RuntimeException">error</prop>
                  </props>
              </property>
      	</bean>
      

    注意:因为exceptionMappings这个属性是Properties类型的,所有是键值对,key表示你捕获的异常,需要全限定名,error表示出现这个错误要跳转的页面。
    全局异常处理获取异常信息值的方式需要是 ${Exception.message}

    展开全文
  • 最近想深入学习LabVIEW,对于控件的使用上遇到了选择上的问题,如何合理的使用控件引用、属性节点、局部变量全局变量等,结合帮助文档和网上资料,总结如下: 1、全局变量和局部变量 局部变量和全局变量是内存...

    最近想深入学习LabVIEW,对于控件的使用上遇到了选择上的问题,如何合理的使用控件引用、属性节点、局部变量全局变量等,结合帮助文档和网上资料,总结如下:

    1、全局变量和局部变量

    局部变量和全局变量是内存数值操作,属性节点是对控件值的属性进行的操作。理论上,变量的效率比属性节点高。局部变量的作用域是整个VI,它用于在单个VI中传输数据;全局变量的作用域是整台计算机,它主要用于多个VI之间共享数据。

    但在实际写程序中,大量全局变量的应用和不必要的局部变量会拖慢程序的性能和可读性,并且一般使用变量的时候有很大的随意性,导致后期维护的难度增加,牵一发而动全身,改变了一次赋值后要挨个去找这个变量的影响应用范围。再者,根据实际经验,全局变量在多层VI嵌套之后再赋值,另个一VI或同VI中其他循环对数据进行轮询,会出现两者不同步的现象,原因可能有循环的时间间隔不同,内存相应时间不同等,尤其是在通讯数据处理过程中,隐藏了很大的BUG。以下为官方帮助文档内容

    谨慎使用局部变量和全局变量:

    局部和全局变量是高级的LabVIEW概念。它们不是LabVIEW数据流执行模型中固有的部分。使用局部变量和全局变量时,程序框图可能会变得难以阅读,因此需谨慎使用。错误地使用局部变量和全局变量,如将其取代连线板或用其访问顺序结构中每一帧中的数值,可能在VI中导致不可预期的行为。滥用局部变量和全局变量,如用来避免程序框图间的过长连线或取代数据流,将会降低执行速度。

    局部变量和全局变量的初始化:

    如需对一个本地或全局变量进行初始化,应在VI运行前将已知值写入变量。否则变量可能含有导致VI发生错误行为的数据。如变量的初始值基于一个计算结果,则应确保LabVIEW在读取该变量前先将初始值写入变量。将写入操作与VI的其它部分并行可能导致竞争状态。

    要使变量初始化在VI其他部分执行之前完成,可将把初始值写入变量的这部分代码单独放在顺序结构的第一帧。也可将这部分代码放在一个子VI中,通过连线使该子VI在程序框图的数据流中第一个执行。

    如在VI第一次读取变量之前,没有将变量初始化,则变量含有的是相应的前面板对象的默认值。

    竞争状态:

    两段或更多代码并行执行并访问同一部分内存时会引发竞争状态。如果代码是相互独立的,就无法判断LabVIEW按照何种顺序访问共享资源。

    竞争状态会引起不可预期的结果。例如,两段独立的代码访问同一个队列,但是用户未控制LabVIEW访问队列的顺序,这种情况下会引发竞争状态。

    竞争状态随着程序运行的时间因素而改变,因此具有一定的危险性。操作系统、LabVIEW版本和系统中其他软件的改变均会引起竞争状态。

    如改动了VI的时间要素(例如,更新操作系统或LabVIEW版本),请检查访问同一部分数据的并行代码,并使用定时条件来控制哪一部分代码首先执行。

    使用局部变量和全局变量时的竞争状态:

    对同一个存储数据进行一个以上更新动作均会造成竞争状态,但是竞争状态通常在使用局部变量和全局变量或外部文件时出现。以下程序框图显示了一个局部变量造成竞争状态的范例。

    该VI的输出,即本地变量x的值取决于首先执行的运算。因为每个运行都把不同的值写入x,所以无法确定结果是7,还是3。在一些编程语言中,由上至下的数据流模式保证了执行顺序。在LabVIEW中,可使用连线实现变量的多种运算,从而避免竞争状态。下列程序框图通过连线而不是局部变量执行了加运算。

    提示:  如必须在局部变量或全局变量上执行一个以上操作,则应确保各项操作按顺序执行。

    如两个操作同时更新一个全局变量,也会发生竞争状态。如要更新全局变量,需先读取值,然后修改,再将其写回原来的位置。当第一个操作进行了读取-修改-写入操作,然后才开始第二个操作时,输出结果是正确的,可预知的。第一个操作读取值,然后第二个操作读取值,则两个操作都修改和写入了一个值。这样操作造成了读取-修改-写入竞争状态,会产生非法值或丢失值。

    要避免全局变量引起的竞态,可使用功能全局变量(高级应用暂不介绍)保护访问变量操作的关键代码。使用一个功能全局变量而不是多个本地或全局变量可确保每次只执行一个运算,从而避免运算冲突或数据赋值冲突。

    使用局部变量时应考虑内存:

    局部变量复制数据缓冲区的数据。从一个局部变量读取数据时,便为相关控件的数据创建了一个新的缓冲区。

    如使用局部变量将大量数据从程序框图上的某个地方传递到另一个地方,通常会使用更多的内存,最终导致执行速度比使用连线来传递数据更慢。如在执行期间需要存储数据,可考虑使用移位寄存器。

    使用全局变量时应考虑内存:

    从一个全局变量读取数据时,LabVIEW将创建一个数据的副本,保存于该全局变量中。

    操作大型数组和字符串时,将占用相当多的时间和内存来操作全局变量。操作数组时使用全局变量尤为低效,原因在于即使只修改数组中的某个元素,LabVIEW仍对整个数组进行保存和修改。如一个应用程序中的不同位置同时读取某个全局变量,则将为该变量创建多个内存缓冲区,从而导致执行效率和性能降低。

    2、属性节点

    获取(读取)和/或设置(写入)引用的属性。通过属性节点对本地或远程应用程序实例、VI或对象获取或设置属性和方法也可通过属性节点访问LabVIEW类的私有数据。

    属性节点可自动调整为用户所引用的对象的类。LabVIEW的属性节点可访问XML属性、VISA属性、.NET属性和ActiveX属性。

    连线引用句柄至引用输入端可指定执行该属性的类。例如,要指定的类是VI类、通用类或应用程序类,可连线VI、VI对象或应用程序引用至引用输入端。节点将自动调整为相应的类。此外,也可右击节点,在快捷菜单中选择类。

    可将LabVIEW类连接至属性节点的引用输入。如该LabVIEW类拥有属性节点可用的访问器VI,可通过属性节点读取或写入访问器。

    属性节点在Labview中是一个很重要的概念,属性节点用于访问控件的属性,例如需要改变控件在前面板的大小,运行时候的状态等都需要通过属性节点来进行操作,与引用结合起来讲就是属性节点可以设置引用的属性。Labview的属性节点功能强大,不同的控件有不同的引用,这些不同的引用都可以通过各自的属性节点来进行设置,但需要注意的是,属性节点的执行效率比较低,甚至比全局变量的效率还要低,所以NI一般建议少用属性节点。

    3、控件引用

    在Labview中称为引用句柄,在Windows编程中,引用句柄指的是指向指针的指针,换句话说,引用句柄保存的是其他一些数据类型的地址,例如窗口句柄。在Labview中,控件的引用句柄指的也是指向特定数据类型的指针,在Labview中,控件的引用句柄是长度为四个字节,引用句柄不但能够表示控件的类型,还与空间一一对应,这是通过句柄的编号来实现的,引用句柄自身未代表任何空间,但是通过引用句柄指向特定的实例后,就可以操作具体的控件了,简单的理解就是通过对引用句柄的操作,可以改变控件的属性参数。

    参考资料:

    (1)https://www.cnblogs.com/yuexinzheng1989/p/4443048.html

    (2)NI官方帮助文档

    展开全文
  • 全局空间和局部空间

    千次阅读 2018-10-03 17:07:01
    全局空间和局部空间 操作系统需要把程序加载到内存并运行程序.其次,操作系统要提供大量的实例和数据供程序调用.使用这些操作系统提供的服务,可以极大简化程序编写,并在访问设备时消除潜在的竞争和冲突. 所以每个任务...

    全局空间和局部空间

    • 操作系统需要把程序加载到内存并运行程序.
    • 操作系统要提供大量的实例 , 数据或服务供程序调用,以简化程序编写.
    • 同时在访问设备时消除潜在的竞争和冲突.

    所以每个任务包含两个部分:全局部分和私有部分.

    • 全局部分是所有任务共有的,含有操作系统的软件和库程序,以及可以调用的系统服务和数据;
    • 私有部分包括每个任务各自的数据和代码.如图:
      Alt
      左是每个任务的全局空间和局部空间,右是多任务的全局空间和局部空间.

    震惊!!每个任务的地址空间竟有 64TB?

    GDT最大的尺寸是 216 字节,又每个段描述符占 8 字节,所以GDT可以划分 213 个段,即 8192 个.又GDT的 0 号描述符不能使用,故实际是 8191 个段,但这只有 4GB可以忽略不计.又段内偏移地址是 32 位,段的长度最大是 4GB,因此,一个任务的全局空间,其总大小为 213 × \times × 232 = 245 字节,即 32TB.
    同理,局部描述符表LDT可以划分 213 个,即 8192 个描述符,每个段的长度最大是 4GB.故,一个任务的局部空间,其总大小为 213 × \times × 232 = 245 字节,即 32TB.
    这样一来,每个的总地址空间为 32+32=64TB ,但在一个 32 根地址总线的处理器上,无论如何不能这么巨大的存储空间.但其实这些只是虚拟的地址空间.操作系统允许程序的编写者使用这么巨大的地址空间编写程序.
    这就是说编译器不考虑处理器的寻址空间的大小,也不考虑物理内存的大小,它只负责编译程序.但是,当程序超出理内存的大小时,或操作系统无法分配这么大的物理内存空间时,怎么办?
    同一块物理内存,可以让多个任务,或者多个任务的不同段使用.

    1. 当执行或者访问一个新的段时,如果它不在物理内存中(描述符的"P"位为 0 ,这时会引发中断),而且也没有空闲的物理内存来加载它
    2. 那么操作系统将在内存查找一个暂时用不到的段,把它换出到磁盘中,并把腾出的空间分配给马上要访问的段
    3. 然后改变段的描述符,使之指向这段内存空间(同时描述符的"P"位改为 1 ,这之后中断返回).
    4. 下一次,当换出的段又用到时,再按同样的方法加载到内存.
    展开全文
  • 问题三:数据不一致 当协调者向参与者发送提交请求后发生了局部网络异常,或者在发送提交请求过程中协调者发生了故障,就会导致只有一部分参与者接收到了提交请求,这部分参与者接到请求后就会执行提交操作,而未...

    目录

    一、分布式事物:本地事务和分布式事务(2PC+3PC)+传统分布式事务的问题

    (一)本地事务和分布式事务(2PC+3PC)

    (1)两阶段提交协议2PC

    (2)三阶段提交协议3PC

    (二)对于微服务,传统分布式事务存在的问题

    二、CAP理论和BASE思想

    1.CAP理论

    一致性Consistency:

    可用性Availability:

    分区容错性PartitionTolerance:

    2.BASE思想

    BasicallyAvailiable(基本可用):

    SoftState(软状态):

    EventualConsistency(最终一致性):

    3.CAP理论和BASE思想的关联性

    三、可靠事件模式

    1.基本思路

    (1)用户下单

    (2)交易支付

    (3)订单更新

    2.关键点

    3.解决方案

    4.实现策略

    (1)事件确认组件

    (2)事件恢复组件

    (3)实时消息传递组件

    四、补偿模式

    1.基本思路

    2.关键点

    3.解决方案

    五、Sagas长事务模式--错误管理模式,同时用于控制复杂事务的执行和回滚

    1.基本思路

    2.解决方案

    六、TCC模式

    1.基本思路

    2.解决方案

    3.实现策略

    七、最大努力通知模式

    1.基本思路

    2.解决方案

    八、人工干预模式

    1.基本思路

    2.解决方案

    九、数据一致性模式总结

    参考书籍、文献和资料:


    一、分布式事物:本地事务和分布式事务(2PC+3PC)+传统分布式事务的问题

    (一)本地事务和分布式事务(2PC+3PC)

    传统单体应用一般都会使用一个关系型数据库,好处是使用ACID事务特性,保证数据一致性只需要开启一个事务,然后执行更新操作,最后提交事务或回滚事务。更方便的是可以以借助于Spring等数据访问技术和框架后只需要关注引起数据改变的业务本身即可。

    但是随着组织规模不断扩大、业务量不断增加,单块应用不足以支持庞大业务量和数据量,就需要对服务和数据进行拆分,拆分后就会出现两个或两个以上的数据库的情况,此时不能依靠本地事务得以解决,需要借助于分布式事务来保证一致性,常说的就是保持强一致性的两阶段提交协议和三阶段提交协议。

    (1)两阶段提交协议2PC

    准备阶段:由协调者提议并收集其他节点参与者的反馈(提议的节点为协调者,参与决议的节点为参与者)。

    执行阶段:根据反馈决定提交或中止事务。

    如图,协调者发起一个提议分别询问各参与者是否接受场景,然后协调者根据参与者的反馈,提交或中止事务。

    注意:只有当所有参与者都同意才提交,否则只有有一个不同意就中止。            

    但是,2PC有其固有的三大问题:

    问题一:同步阻塞问题

    执行过程中,所有参与者都是事务阻塞型的。当参与者占用公共资源时,其他第三方节点访问公共资源就不得不处于阻塞状态。

    问题二:单点故障

    一旦协调者发生故障,参与者会一直阻塞下去。特别是在第二阶段,协调者发生故障,则所有参与者还处于锁定资源的状态中,但是无法完成后续的事务操作。

    问题三:数据不一致

    当协调者向参与者发送提交请求后发生了局部网络异常,或者在发送提交请求过程中协调者发生了故障,就会导致只有一部分参与者接收到了提交请求,这部分参与者接到请求后就会执行提交操作,而未接收到提交请求的机器就无法执行事务提交,于是就出现了数据不一致的问题。

    (2)三阶段提交协议3PC

    与2PC相比,3PC主要有两个改动点:在协调者和参与者之间都引入了超时机制+把准备阶段一分为二

    3PC:CanCommit + PreCommit + DoCommit,具体操作如下

    CanCommit阶段:协调者向参与者发送提交请求,参与者如果可以提交就返回Yes响应,否则返回No响应。

    PreCommit阶段:协调者根据参与者的响应情况来决定是否可以进行事务的PreCommit操作。

    如果协调者从所有参与者获得反馈都是Yes响应,那么就执行事务的预执行;

    如果有任何一个参与者向协调者发送了No响应,或者等待超时后没有收到参与者的响应,那么就执行事务的中断。

    DoCommit阶段:执行提交或中断事务。当协调者没有收到参与者发送的ACK响应,就会执行中断事务。

    可见,3PC主要解决了2PC的单点问题和同步阻塞问题。

    (二)对于微服务,传统分布式事务存在的问题

    在微服务架构中,传统分布式事务并不是实现数据一致性的最佳选择,主要有三大问题:

    问题一:对于微服务架构来说,数据访问变得更加复杂,为达到微服务间的松耦合和高度独立,数据是微服务私有的,唯一可访问的方式就是通过API,采用2PC/3PC难度太大。

    问题二:不同的微服务经常使用不同的数据库,但是在微服务架构中,服务会产生不同类型的数据,关系数据库不一定是最佳选择,很多微服务会采用SQL和NoSQL结合模式,如搜索引擎、图数据库等NoSQL数据库大多数都不支持2PC/3PC。

    问题三:当数据被拆分了或者在不同的数据库存在重复数据的时候,锁定资源和序列化数据来保证一致性就会变成一个非常昂贵的操作,会给系统的吞吐量以及扩展性带来巨大的挑战。

    对于微服务架构,建议采用一种更为松散的方式来维护一致性,也就是所谓的最终一致性,对于开发者而言,实现最终一致性的方案可以根据不同的业务场景做不同的选择。

    二、CAP理论和BASE思想

    1.CAP理论

    指的是在一个分布式系统中,无法同时实现一致性Consistency、可用性Availability和分区容错性PartitionTolerance。

    对于典型分布式系统而言,如图所以,这三个概念可以做以下解释:

    一致性Consistency:

    指分布式系统中的所有数据备份在同一时刻是否拥有同样的值。

    可用性Availability:

    指在集群中一部分节点故障后,集群整体是否还能正常响应请求。

    分区容错性PartitionTolerance:

    相当于通信的时限要求,系统如果不能在一定时限内达到数据一致性,就意味着发生了分区情况,也就是说整个分布式系统就不在互联了。

    由于当前网络硬件肯定会出现延迟丢包等通信异常问题,三态性不可避免,所以分区容错性必须实现。

    2.BASE思想

    BASE=BasicallyAvailiable(基本可用)+SoftState(软状态)+EventualConsistency(最终一致性)

    BASE理论是对CAP理论的延伸,基本思想是即使无法做到强一致性,应用可以采用适合的方式达到最终一致性。

    BasicallyAvailiable(基本可用):

    指分布式系统在出现故障的时候,可以损失部分可用性,需要保证和核心可用。服务限流和降级就是其基本表现。

    SoftState(软状态):

    指允许系统存在中间状态,而中间状态不会影响整体可用状态。分布式存储中一般一份数据都有有若干个副本,允许不同节点间副本同步的延时就是软状态的体现。

    EventualConsistency(最终一致性):

    指系统中所有的数据副本经过一定时间后,最终能够达到一致的状态。

    CAP的一致性就是强一致性,这种一致性级别是最符合用户直觉的,用户体验好,但实现起来对系统性能影响较大弱一致性正好相反。BASE中的最终一致性可以看做是弱一致性的一种特殊情况。

    3.CAP理论和BASE思想的关联性

    CAP理论和BASE思想实际上是有关联的,基本关系如图所示:                                                          

    CAP理论和BASE思想讨论的意义在于即使无法做到强一致性,我们也可以采用合适的方式达到最终一致性,这点对微服务架构很重要。最终一致性的方法重要有以下六种分别讲解。

    在微服务架构中,比如,对于一个完整的下单操作而言,订单服务和支付服务都是业务闭环中的一部分,在一个完整的业务操作流程中需要保证各自数据的正确性和一致性。

    三、可靠事件模式

    1.基本思路

    尝试将订单和支付两个微服务进行分别管理,并需要一个媒介用于这两个微服务之间进行数据传递,一般而言,消息中间件MOM适合扮演数据传递媒介的角色。引入消息中间件后下单操作流程可以拆分为如下三个步骤:

    (1)用户下单

    当用户使用订单服务下单时,一方面订单服务需要对所产生的订单数据进行持久化操作,另一方面,也需要同时发送一条创建订单的消息到消息中间件。

    (2)交易支付

    当消息中间件接收到订单创建消息,就会把消息发送到支付服务。

    支付服务接收到订单创建消息后,同样对该消息进行业务处理并持久化。当所有关于支付相关的业务逻辑执行完成以后,支付服务需要向消息中间件发送一条支付成功的消息。

    (3)订单更新

    支付成功消息通过消息中间件传递到订单服务时,订单服务根据支付的结果处理后续业务流程,一般涉及订单状态更新、向用户发送通知内容等内容。

    2.关键点

    对于以上三个闭环管理,仔细分析整个过程,不难发现存在如下三个基本问题:

    (1)某个服务在更新了业务实体后发布消息失败;

    (2)服务发布事件成功,但是消息中间件未能正确推送事件到订阅的服务;

    (3)接受事件的服务重复消费事件。

    针对第三个问题,是最为容易解决的,一般处理方法是由业务代码控制幂等性,例如支付服务传入一个订单时,可以通过判断该订单所对应的唯一ID是否已经处理方式来避免对其再次处理。

    但是前两个问题概括起来就是要解决消息传递的可靠性问题,这个是可靠性事件模式实现数据最终一致性的关键点。要做到可靠消息传递,需要消息中间件确保至少投递一次消息,目前主流的消息中间件都支持消息持久化和至少一次投递的功能。所以,我们需要考虑的是,如何原子性的完成业务操作和发布消息。

    订单服务同时需要处理数据持久化和消息发送两个操作,这就需要考虑两个场景:

    (1)如果数据持久化操作失败,显然消息不该被发送;

    (2)如果数据持久化操作成功,但消息发送失败,那么已经被持久化的数据需要被回滚以还原到初始状态。

    对应这两个场景基本实现流程图如下:

    在逻辑上是可行的,但在运行中,需要考虑很多意想不到的场景,主要有以下两个实际问题:

    (1)实际问题一:典型的依旧是分布式环境下所固有的网络通信异常问题,消息中间件返回通信发生故障,如下图分析:              

    (2)实际问题二:订单服务投递消息后等待消息返回,当消息返回时,订单服务挂了,也会导致数据不一致,如下图分析:

    3.解决方案

    解决上面的问题可以使用一个本地事件表。

    微服务在进行业务操作时需要将业务数据和事件保存在同一个本地事务中,由本地事务保证更新业务和发布事件的原子性。

    发布的事件被保存在本地事务表中,然后该服务实时发布一个事件通知关联的业务服务,如果事件发布成功则立即删除本地事件表中的事件。      

    由于事件消息发布可能会失败或无法获取返回结果,我们需要使用一个额外的“事件恢复”服务来恢复事件,该事件恢复服务定时从事件表中恢复未发布成功的事件并重新发布,只有重新发布才删除保存在本地事件表中的事件。

    注意,事件恢复服务保证了事件一定会被发布,从而确保数据的最终一致性。

    4.实现策略

    在实现上,首先考虑在可靠事件模式中存在一个事件生产者。该事件生产者处于操作的主导地位, 并根据业务操作通过事件的方式发送业务操作的结果(在上例中,订单服务就是事件的生产者),其次,事件消费者是被动方,负责根据事件来处理自身业务逻辑(上例中的支付服务属于事件消费者)。

    有了事件生产者和事件消费者后,我们关注事件服务,事件服务的主要作用就是管理本地事件表,它能存储、确认并发送事件,同时根据不同状态查询事件信息并确定事件已被事件消费者成功消费。事件服务有三大组件:       

    (1)事件确认组件

    表现为一种定时机制,用于处理事件没有被成功发送的场景。

    例如,订单服务在完成业务操作之后需要发送事件到本地事件表,如果这个过程中事件没有发送成功,我们就需要对这些事件重新发送,这个过程为事件确认。

    (2)事件恢复组件

    同样表现为一种定时机制,根据本地事件表中的事件状态,专门处理状态为已确认但还没有成功消费且已超时的事件。

    基本的事件恢复策略就是向消费者重新发送事件,并在消费成功后更新事件状态,并在本地事件表中进行逻辑删除。

    (3)实时消息传递组件

    基于特定的消息中间件工具和框架将事件作为消息进行发送的组件。

    目前可供选择的主流消息中间件包括RabbitMQ、ActiveMQ、RocketMQ、Kafka等。

    四、补偿模式

    1.基本思路

    基本思路在于使用一个额外的补偿服务来协调各个需要保证一致性的微服务,补偿服务按顺序依次调用各个微服务,如果某个微服务调用失败就撤销之前所有已经完成的微服务,补偿服务对需要保证一致性的微服务提供补偿操作。

    举例当中涉及两个微服务,订单微服务和支付微服务,为其提供补偿操作,如果支付服务失败,就需要取消之前的下单服务。

    为降低开发的复杂性和提高效率,补偿服务通常实现为一个通用的补偿框架,补偿框架提供服务编排和自动完成补偿的能力。

    2.关键点

    对于补偿服务而言,所有服务的操作记录是一个关键点,操作记录是执行取消操作的前提。

    举例中,订单服务与支付服务需要保存详细的操作记录和日志,这些日志和记录有助于确定失败的步骤和状态,进而明确需要补偿的范围,然后获取所需补偿的业务数据。

    如果只是订单服务失败,那么只需要补偿一个服务就可以,如果支付服务也失败了,对两个服务进行回滚。

    补偿操作要求业务数据包括支付时的业务流水号、账号和金额。理论上可以根据唯一的业务流水号就能完成补偿操作,但提供更多的数据有益于微服务健壮性。

    3.解决方案

    实现补偿模式的关键要素就是记录完整的业务流水,可以通过业务流水为补偿操作提供需要的业务数据。

    补偿服务可以从业务流水的状态中知道补偿的范围,补偿过程中需要的业务数据同样可以从记录的业务流水中获取。

    补偿服务作为一个服务调用过程同样存在调用不成功的情况,需要通过一定的健壮性机制来保证补偿的成功率,补偿的相关操作本身需要具有幂等性。

    补偿服务健壮性策略:需要根据服务执行失败的原因来选择不同的重试策略,如图所示:                                         

    (1)服务重启:如果失败的原因不是暂时的,而是由业务因素导致的业务错误,需要对问题进行修正后重新执行。

    (2)立即重试:对于网络失败或数据库锁等瞬时异常,重试在很大程度上能够确保任务正常执行。

    (3)定时调用:一般会指定调用的次数上限,如果调用次数达到上限也就不再进行重试。

    如果通过服务重启、立即重试、定时调用等策略依旧不能解决问题,则需要通知相关人员进行处理,即人工干预模式。

    五、Sagas长事务模式--错误管理模式,同时用于控制复杂事务的执行和回滚

    1.基本思路

    长时间持续的事务无法简单地通过一些典型的ACID模型以及使用多段提交配合持有锁的方式来实现。Sagas用于解决这个问题,和多段式分布式事务处理不同,Sagas会将工作分成单独的事务,包含正常额操作和回滚的操作。

    对于开发者而言,不是将所有微服务都定义为分布式的ACID事务,以下单行为为例,将其定义为一个整体,其中包含如何去生成订单以及如何去取消订单,对于支付而言也需要提供同样的逻辑。

    可以将订单和支付服务组合在一起构成一个服务链,然后将整个服务链加密,这样只有该服务链的接收者才能够操控这个服务链。

    当一个服务完成后,会将完成的信息记录到一个集合中,之后可以通过这个集合访问到对应的服务。

    当一个服务失败时,服务本身将本地清理完毕并将消息发送给该集合,从而路由到之前执行成功的服务,然后回滚所有的事务。

    2.解决方案

    在Sagas事务模型中,一个长事务是由一个预定义好执行顺序的子事务集合和他们对应的补偿子事务集合所组成。

    典型的一个完整的交易由T1、T2、......、Tn等多个业务活动组成,每个业务活动可以是本地操作或者是远程操作,而每个业务活动都有对应的取消活动C1、C2、......、Cn。

    所有的业务活动在Sagas事务下要么全部成功,要不全部回滚,不存在中间状态。对于一个Sagas链路而言,各个业务活动执行过程中都会依赖上下文,每个业务活动都是一个原子操作,并提供执行和取消两个入口。

    需要设计一个存储模型来保存执行上下文并通过该存储模型来索引到对应的服务。

    存储模型中包含两个内部结构,一个是完成的任务,一个是等待执行的任务。如果成功就会将任务向前执行,如果失败就向后执行。

    实现上的一种思路可以采用队列和栈数据结构,一方面使用队列来向前执行,另一方面使用栈来向后执行。

    注意,当执行取消操作进行事务操作失败时需要记录失败事务日志,通过重试策略进行重试,对重试失败的执行定时重试,在有问题时则进行人工干预。

    六、TCC模式

    1.基本思路

    一个完整的TCC业务由一个主服务和若干个从服务组成,主服务发起并完成整个业务流程。

    从服务提供三个接口:Try、Confirm、Cancel:

    Try接口:完成所有业务规则检查,预留业务资源。

    Confirm接口:真正执行业务,其自身不做任何业务检查,只使用Try阶段预留的业务资源,同时该操作需要满足幂等性。

    Cancel接口:释放Try阶段预留的业务资源,同样也需要满足幂等性。

    举例来看,订单系统拆分成订单下单和订单支付两个场景,使用TCC模式后执行效果如下:

    (1)Try阶段:尝试执行业务。

    一方面完成所有业务检查,如针对该次订单下单操作,需要验证商品的可用性以及用户账户金额是否够。

    另一方面需要预留业务资源,如把用户账户余额进行冻结用于支付该订单,确保不会出现其他并发进程扣减账户余额导致后续支付无法进行。

    (2)Confirm阶段:执行业务。

    Try阶段一切正常,则执行下单操作并扣除用户账号中的支付金额。

    (3)Cancel阶段:取消执行业务。

    释放Try阶段预留的业务资源,如果Try阶段部分成功,如商品可用且正常下单,但账户余额不够而冻结失败,则需要对产品下单做取消操作,释放被占用的该商品。

    2.解决方案

    TCC服务框架不需要记录详细的业务流水,完成Confirm和Cancel操作的业务由业务服务提供。

    TCC模式同样有两个阶段组成

    第一阶段:

    主业务服务分别调用所有从业务的Try操作,并在活动管理器中登记所有从业务服务。当所有从业务服务的Try操作都调用成功或者某个从业务的Try操作失败,进入第二个阶段。

    第二阶段:

    主业务根据第一阶段的执行结果来执行Comfirm或Cancel操作。

    如果第一阶段所有Try操作都成功,则主业务服务调用所有从业务活动的Confirm操作。

    如果第一阶段中失败,则调用Cancel操作。

    整体上,一个完整的TCC事务参与方包括三个部分:

    (1)主业务服务

    整个业务的发起方,在订单处理场景中,订单应用系统即是主业务服务。

    (2)从业务服务

    负责提供TCC业务操作,是整个业务活动的操作方。

    从业务必须实现Try、Confirm和Cancel三个接口,供主业务服务调用。Confirm和Cancel接口需要具备幂等性,订单的下单服务与支付服务即是从业务服务。

    (3)业务活动管理

    管理控制整个业务活动,包括记录维护TCC全局事务状态和每个从业务服务的子事务状态,并在业务活动提交时确认所有从业务服务Confirm操作,在业务活动取消时调用所有从业务服务的Cancel操作。

    3.实现策略

    在实现TCC模式上,最重要的工作是设计一个稳定的、高可用的、扩展性强的TCC事务管理器。

    在一个跨服务的业务操作中,首先通过Try锁住服务中业务资源进行资源预留,只有资源预留成功了,后续的操作才能正常进行。Confirm操作是在Try之后进行的对Try阶段锁定的资源进行业务操作,Cancel在所有操作失败时用于回滚。

    TCC的操作都需要业务方提供对应的功能,在开发成本上比较高,推介TCC框架有:

    (1)http://github.com/protera/spring-cloud-rest-tcc;

    (2)http://github.com/changmingxie/tcc-transaction;

    (3)http://github.com/liuyangming/ByteTCC;

    (4)http://github.com/QNJR-GROUUP/EasyTransaction;

    (5)http://github.com/yu199195/happylifeplat-tcc;

    (6)https://www.atomikos.om/Blog/TCCForTrasationMangementAcrossMicroservices。

    七、最大努力通知模式

    1.基本思路

    本质上是一种通知类的实现方案。

    基本思路是通知发送方在完成业务处理后向通知接收方发送通知消息。

    当消息接收方没有成功消费消息时,消息的发送方还需要进行重复发送直到消费者消费成功或达到某种发送总之条件。

    消息发送方可以设置复杂的通知规则,利于采用阶梯式事件通知方式。

    通知接收方也可以使用发送方所提供的查询和对账接口获取数据,用于恢复通知失败所导致的业务数据。

    以支付宝为例,通知回调商户提供的回调接口,通过多次通知、查询对账等手段完成交易业务平台间的商户通知。

    2.解决方案

    实现上比较简单,基本系统结构中的通知服务包括三大组件:

    (1)查询组件

    通发送方处理业务并把业务记录保存起来,查询组件提供查询入口供通知接收方主动查询业务数据,避免数据丢失。

    (2)确认组件

    当通知接收方成功接收到通知时,需要与通知发送方确认通知已被正常接收。确认组件接收到确认消息之后就会更新业务记录中的状态,通知组件根据状态就不需要再发送通知。

    (3)通知组件

    通知组件根据业务记录向通知接收方发送通知,在发送通知的过程中需要保存通知记录,并根据业务记录的状态以及现有的通知记录确定下一次发送通知的策略。

    注:最大努力通知模式适合于业务最终一致性的时间敏感度比较低的场景,一般用于类似支付宝与商户集成类跨企业的业务活动。

    八、人工干预模式

    1.基本思路

    严格意义上并不是一种数据一致性的实现机制,当前面讲的各种模式都无法满足需要时,人工干预模式更多的是一种替代方案。

    对于一些重要的业务场景下,由于前面几种模式中因为网络三态性无法解决问题的情况,需要人工干预来保证真正的一致性。常用手段为定期对账等。

    2.解决方案

    实施前提是需要一个后台管理系统,提供操作不一致的基本入口。

    周期性的对账机制需求,对账机制基于业务数据,业务双方根据各自系统内所产生的订单或支付记录,相互对比发现数据不一致的情况,然后通过线下付款等形式形成一致的操作结果。

    九、数据一致性模式总结

    对于金融、支付等业务体系,数据一致性要求极高,需要保证严格的实时一致性要求。

    对于基于社交类的应用场景,可以采用局部实时一致、最终全局一致的实现思路。

    微服务架构里面建议“兜底”思维,即不管实现方案是否完美,最后都要有一个备选方案,备选方案不一定满足日常业务场景,但当出现异常情况时,可通过备选完成正常业务的闭环。

    参考书籍、文献和资料:

    【1】郑天民. 微服务设计原理与架构. 北京:人民邮电出版社,2018.05

    【2】尹吉欢. Spring Cloud微服务全栈技术与案例分析. 北京:机械工业出版社,2018.08

    展开全文
  • static有两种用法:面向...全局变量、局部变量、静态全局变量、静态局部变量的区别  C++变量根据定义的位置的不同的生命周期,具有不同的作用域,作用域可分为6种:全局作用域,局部作用域,语句作用域,类作用域,
  • 最近在学习设计模式中的单例模式时,里面用到了一个全局变量,虽然早在学习VB的时候就明白什么是全局变量,但从来没有区分过。比如有全局静态变量、局部变量、局部静态变量等,那么他们之间又有什么区别呢!强烈的...
  • 全局局部函数

    千次阅读 2014-09-06 02:16:10
    全局局部函数   全局局部函数是为了支持16bit的程序移植,或者是为了维护程序对16bit Windows的兼容性。从32bit Windows起,全局函数和局部函数的实现是封装一个相关的堆函数,这个堆函数用进程的默认堆的句柄...
  • 单例模式全局变量出现的问题

    千次阅读 2017-07-24 20:12:41
     第一种方式: 既然是全局变量惹的祸,那就将全局变量都编程局部变量,通过方法参数来传递。  第二种方式: jdk提供了java.lang.ThreadLocal,它为多线程并发提供了新思路。 ( 当使用ThreadLocal维护变量时,...
  • LBP(局部二进制模式)

    万次阅读 2016-06-11 10:12:18
    LBP(Local Binary Patterns ,局部二进制模式)是一种理论简单、计算高效的非参数局部纹理特征描述子。由于其具有较高的特征鉴别力和较低的计算复杂度, 近期获得了越来越多的关注,在图像分析、计算机视觉和模式识别...
  • 全局变量、静态局部变量、静态全局变量都在静态存储区分配空间,而局部变量在栈分配空间。 全局变量本身就是静态存储方式,静态全局变量当然也是静态存储方式。这两者在存储方式上没有什么不同。区别在于非静态...
  • 一、首先简要介绍局部变量和全局变量区别 (1)作用域 全局变量具有全局作用域,适用于所有源文件。但在不包含全局变量定义的文件中,需使用extern关键字声明这个全局变量后,方可正常使用。 静态全局变量也具有...
  • 进程有独立的地址空间,一个进程崩溃后,在保护模式下不会对其它进程产生影响,而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量,但线程之间没有单独的地址空间,一个线程死掉就等于整个进程死掉,...
  • 从80386开始,CPU有三种工作方式:实模式,保护模式和虚拟8086模式。只有在刚刚启动的时候是real-mode,等到操作系统运行起来以后就切换到protected-mode。实模式只能访问地址在1M以下的内存称为常规内存,我们把...
  • C++ 局部静态变量,全局变量,全局静态变量,局部变量的区别和联系C++变量根据定义位置的不同,具有不同的作用域,作用域可分为6种:全局作用域,局部作用域,语句作用域,类作用域,命名作用域和文件作用域。...
  • CPU实模式和保护模式 cpu的保护模式由来 分段机制 8086的诞生,标志着Intel 正式进入了x86时代,这是个多么具有纪念意义的日子:1978-6-8。同时,8086的诞生也是处理器内存寻址技术的第一次飞跃。 对于...
  • 自调函数:和普通函数的区别时编译到该函数时立即执行,所以...局部变量和全局变量的区别 <script> var a = 10;//全局变量 function zi(){ var a = 5;//局部变量 console.log(a);// 输出5; } z...
  • 设计模式:23种设计模式综述

    千次阅读 2016-10-17 22:12:39
    设计模式(Design Patterns) ——可复用面向对象软件的基础  设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被...
  • #1.声明并初始化 SET @count=1; #2.赋值 SELECT COUNT(*) INTO @count FROM employees; #3.使用 SELECT @count;

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 88,878
精华内容 35,551
关键字:

局部模式全局模式存储模式