Orleans的单线程执行模型

Orleans在默认情况下只创建一个grain的实例,并以单线程模型执行。如果同一个grain实例,在Orleans存在多个实例,就会产生并发冲突,单线程执行模型就可以完全避免并发冲突了。

但在特殊场景下,有些实例是需要创建多个实例或者以非单线程的执行方式来满足性能的需要;

如何支持创建多个实例

对于了解负载均衡的人,如果web服务器支持无状态(分布式Sesson或者cookie身份识别),会很容易做负载。同样的,对于grain来说,如果是无状态的,那么在系统中创建任意多的实例都是一样的,不存在状态不同步的问题。

那么如何在Orleans支持这样的grain呢?

Orleans提供了[StatelessWorker]的Attribute,标记为StatelessWorker的,Orleans会自动调整该grain的实例数量来满足系统的需要。而对于标记为StatelessWorker的Grain,一般只是根据参数调用其它的grain行为,自身没有也不需要保持任何状态。

当标记为StatelessWorker的Grain实例数量不足以应对当前系统的处理请求时,Orleans会自动在cluster中的其它Silo(grain的宿主容器)创建新的Grain实例,用以满足系统的处理需求。当系统热点过去后,如果该Grain一直闲置,是对系统资源的一种浪费,Orleans会自动释放这些闲置的Grain占用的资源。这种方式很像云计算中的弹性云计算的方式。

如何支持非单线程执行模式

分布式应用程序的本质是并行,但是并行带来了更多的复杂性。有两个方式可以降低这种复杂性

1.对Actor实例的内部状态以单线程方式访问

2.Actor之间不共享任何数据,仅仅通过消息进行交互

单线程的数据访问,避免了数据征用,大大降低了分布式应用的复杂性。所以Orleans默认是单线程的执行模式。但这种执行模式,也带来了死锁发生的可能性。

比如A发消息给B,等待B的响应

B收到消息后,又发消息给A,B开始等待A的响应

A由于正在等待之前发给B消息的响应,而无法处理B新发来的消息

A和B之间相互等待,产生了死锁。

而对于A和B之间2次消息并不会产生并发冲突,对于这样的,Orleans提供一种方式,允许grain以非单线程的模型执行。  [Reentrant] Attribute,标记了这个属性的Grain允许多次进入,即非单线程模型执行。

标记了[Reentrant]之后,我们在看之前A B的示例。

A发消息给B,等待B的响应

B收到消息后,又发消息给A,B开始等待A的响应

A因为标记了[Reentrant] ,可以接受并处理B发来的消息,A处理完毕后发回响应给B

B收到响应后,完成自己的处理过程,返回响应给A,完成整个调用

时间: 2024-10-11 15:24:00

Orleans的单线程执行模型的相关文章

Spark的应用程序执行模型

今天看了一篇名为Top 3 Troubleshooting Tips to Keep You Sparking的文章,讲述了一些编写Spark程序需要注意的地方,看完之后想要总结一下. Spark执行模型,总结为官方的架构图: 本文主要讨论Driver和Worker. 我们知道,对于Spark开发的分布式应用程序,和写普通的scala程序基本类似.所以这时往往会陷入一些误区: 在Spark开发的应用程序的对象里,我给他们分成2类对象: 1.闭包内的对象:即在类似map, filter, redu

c# 异步任务队列(可选是否使用单线程执行任务,以及自动取消任务)

使用demo,(.net framework 4.0 自行添加async wait 扩展库) class Program { static void Main(string[] args) { Console.WriteLine("主线程"+Thread.CurrentThread.ManagedThreadId); var asyncTaskQueue = new AsyncTaskQueue { AutoCancelPreviousTask = true, // 自动取消之前的任务

ASP.NET执行模型之IIS服务器处理流程

之前在网上看过很多对这方面的讲解,但个人觉得看下来过于 "深奥",不容易理解,所以想用更简单的方式进行阐述,便于理解. 本次我们重点分析用户请求到页面呈现过程中Web服务器的处理过程.我们从ASP.NET站点的一个页面请求开始说起,先看下面对于某个请求的简单执行模型 (注意这是对asp.net站点Index.aspx页面的第一次请求,所以需要进行动态编译): 我们通过ASP.NET的执行模型简单的描述了一次web请求过程,注意在不同的IIS版本中,处理模型和通信方式是不一样的,在IIS

CLR执行模型

1:首先先明确CLR的概念: 1:首先先明确CLR的概念:  CLR(Common Language Runtime):公共语言运行时,是一个可由多种编程语言使用的"运行时"; 在运行时,CLR根本不关心开发人员用的是哪一种语言来变写代码,它只关注语言是否是面向CLR(面向运行时)的. 2:CLR的核心功能包括: 内存管理.程序集加载.安全性.异常处理和线程同步. 3:如图: 无论是用的是哪一种编译器,结果都是一个托管模块(managed module),托管代码时一个标准的32位/6

【Framework】HTTP运行期与页面执行模型

HTTP运行期 HTTP运行期处理客户端应用程序(例如Web浏览器)进入的一个Web请求,通过处理它的应用程序的适当组件路由请求,然后产生响应并发回提出请求的客户端应用程序. 进入的HTTP Web请求最先由IIS Web服务器接收到,它在此请求基于ASP.NET已注册处理的扩展名传送到ASP.NET ISAPI上. HTTP运行期首先创建一个HttpContext对象的实例,它包含了当前正在处理的请求信息,接着创建在处理逻辑中涉及到的所有其他组件都可以使用的上下文对象.HttpContext实

TT和chrome执行模型对比分析

老大让写一篇高大上的博文,那么如何才能高大上呢?从某种角度讲只要迎合老大的口味给他一篇重口味的岛国动作片剖析就能轻松过关: 从程序员角度讲,能写出高大上的范围有很多,如程序架构,算法分析.编程语言理解.操作系统理解.知名开源程序的原创分析.优秀博文的翻译等都能吸引许多同学的兴趣.今天我再教一招让博文高大上有营养的捷径就是攀高枝,用你现有的程序框架和知名的开源架构做比较剖析.今天我选择走捷径,为同学们来分析下我最近在负责的一款im客户端产品--TeamTalk(简称TT)和chorme执行模型的区

01_CLR执行模型

1:首先先明确CLR的概念: CLR(Common Language Runtime):公共语言运行时,是一个可由多种编程语言使用的"运行时"; 在运行时,CLR根本不关心开发人员用的是哪一种语言来变写代码,它只关注语言是否是面向CLR(面向运行时)的. 2:CLR的核心功能包括: 内存管理.程序集加载.安全性.异常处理和线程同步. 3:如图: 无论是用的是哪一种编译器,结果都是一个托管模块(managed module),托管代码时一个标准的32位/64位Microsoft Wind

CLR执行模型《CLR via c#》第一章

这是我看<CLR via c#>第四版的一些小笔记和总结,如有不对的地方,欢迎指出. <CLR via c#>第一章CLR的执行模型讲的是如何将源代码生成为一个应用程序,或者生成为一组可重新分发的组件(文件)- 这些组件(文件)包含类型(类和结构等),解释了应用程序如何执行. CLR(common language runtime ,公共语言运行时),顾名思义,它是一个可以支持多种语言的“运行时”. 通常我们c#程序的执行过程是 CLR的JIT(即时编译器)把IL代码编译成机器指令

01.由浅入深学习.NET CLR 基础系列之CLR 的执行模型

.Net 从代码生成到执行,这中间的一些列过程是一个有别于其他的新技术新概念,那么这是一个什么样的过程呢,有什么样的机制呢,清楚了这些基本的东西我们做.Net的东西方可心中有数.那么,CLR的执行模型是一个什么样的过程呢? 将源代码编译成托管模块 --> 将托管模块合并成程序集 --> 加载公共语言运行时 --> 执行程序集的代码 目录 将源代码编译成托管模块 将托管模块合并成程序集 加载公共语言运行时 执行程序集的代码 本地代码生成器:NGen.exe Framwork类库入门 通用类