分布式异步消息框架构件3 —— 自动消息路由

这个系列慢慢变成先设想后完成的模式了,上篇我们测试了以Yield当多任务处理.

楼主写了个小Demo也完成了类似功能,并且支持中途等待,直接等到完成回调后,继续处理下一阶段.

这个功能可以完成类似逻辑事件流,比如C需要等待A,B完成后再执行,而且写法也比较简单.直接上代码:

            //创建事件,把Handle丢入Yield队列,
            //执行当发现有等待Handle状态为YieldWating
            //放入YieldWating队列
            //回调时检查YieldWating队列,重新激活
            Context.Wating(WatingResultSubCall, (r) =>
            {
                myvalue = r;
                Console.WriteLine(myvalue);
            }, myvalue);
            yield return -1;

            Context.Wating(WatingResultSubCall, (r) =>
            {
                myvalue = r;
                Console.WriteLine(myvalue);
            }, myvalue);
            yield return -1;

            //返回后继续运行
            myvalue *= 100;
            Console.WriteLine(myvalue);

这是上一篇的总结吧.

今天要解决的是关于多个模块和数据之间的交互,众所周知框架尝试使用单线程来避免所有的锁和开销.

但是并不是所有任务都可以在一个线程中解决,我们需要更多独立的模块和更多独立的线程.

但是又不期望开发者在开发时明确区分这些模块.

最好类似正常的函数直接使用,那么才是一个"优雅"的使用方式.

常规的切片一般基于2种:

1.逻辑切片,独立的功能放在独立的线程或者独立的服务器中运行.比如一个单独的聊天模块,或者拍卖行模块.

2.数据切片,切分若干个大小的地图,用于分开负载,或者简单的分多个区,分散玩家.

但是经常会混合起来,若干个区域的玩家,使用若干个独立的功能.

但是对于框架来说并不关心"切片方式",仅关心"调用位置",既:

是否在当前线程中运行?

1.是,则丢入当前线程

2.否,则丢入路由模块,由路由模块寻找所在线程并丢入执行.

那么路由模块承担什么角色?

1.管理所有模块,它需要知道所有模块所在的线程或者服务器节点?

2.管理所有对象,面向对象的过程,我喜欢把方法集成在对象内,当然你也可以不用这么做.路由模块需要知道所有对象所在线程.

3.负责中转所有消息,不管是基于什么传输/跨线程/跨AppDomain/跨服务器,只要完成中转.

从以上分析可以看出,在这样的机制下,实现分布式是一个非常简单的逻辑,无需修改任何代码,只要路由支持转发消息.那么可以部署到任何位置.

唯一要做的只要指定初始化位置即可.

当然所有的编写规则必须经过所谓的代理逻辑,有点像AOP么,确实比较像,只要符合规范的编写过程,那么一切都不是问题.

时间: 2024-08-19 10:14:31

分布式异步消息框架构件3 —— 自动消息路由的相关文章

分布式异步消息框架构件 —— 设想

前几天在查看关于 Actor模式的一些资料,包括Erlang在游戏中一些资料,虽然本人不会Erlang但是稍微看了下编写方式.觉得还是有可借鉴的地方的.因为实在不熟悉不枉加评论了.这里说下自己的一些理解. 从这几年Erlang和函数式编程的崛起,引发OOP编程的一些不足,但是OOP并不妨碍获得相关的优点,只不过需要一些有效的框架和规范支持. 首先这里有几个简单的问题: 1.OOP方式面临多线程,跨进程访问问题,那么就有所谓的锁问题. 2.函数式编程的优点,不可变数据,并发时无需关心对象状态是否会

分布式异步消息框架构件2——yield机制及单线程多任务系统

上一篇这边进行了一些结构上的设想,主要的核心内容就是消息和单线程实现. 这篇就介绍下如何通过C#中yield关键字,达到单线程执行多任务实现. 首先了解下yield的使用..         public static IEnumerable<object> YieldTest()         {             int x = 0;             x++;             yield return x;             x++;            

消息框架 message

在网页应用中,我们经常需要在处理完表单或其它类型的用户输入后,显示一个通知信息给用户. 对于这个需求,Django提供了基于Cookie或者会话的消息框架messages,无论是匿名用户还是认证的用户.这个消息框架允许你临时将消息存储在请求中,并在接下来的请求(通常就是下一个请求)中提取它们并显示.每个消息都带有一个特定的level标签,表示其优先级(例如info. warning或error). 一.启用消息框架 Django的messages消息框架的实现,依赖messages中间件和对应的

Python开发【模块】:Celery 分布式异步消息任务队列

Celery 前言: Celery 是一个 基于python开发的分布式异步消息任务队列,通过它可以轻松的实现任务的异步处理, 如果你的业务场景中需要用到异步任务,就可以考虑使用celery, 举几个实例场景中可用的例子: 你想对100台机器执行一条批量命令,可能会花很长时间 ,但你不想让你的程序等着结果返回,而是给你返回 一个任务ID,你过一段时间只需要拿着这个任务id就可以拿到任务执行结果, 在任务执行ing进行时,你可以继续做其它的事情. 你想做一个定时任务,比如每天检测一下你们所有客户的

消息框架的一种实现

自从在Android中用上了消息框架,屡试不爽.不管是主线程发任务到后台线程,还是后台线程返回结果到主线程,甚至是完全在主线程中的调用,都用发消息-监听消息-收消息这种方式处理,真是解耦利器. 之前写过的两篇文章:用消息机制获取网络数据 和 用消息机制解耦Activity跳转. 之前在工程中都用的是开源的EventBus,很好用,但是因为是定制好的,缺少很多灵活性,监听方法不可改名,不可从父类override,不可以通过泛型参数声明,等等. 自己尝试用Handler实现了一个消息框架,还没完全搞

九、EnterpriseFrameWork框架基础功能之消息管理

记得阿朱在<走出软件作坊>一书中有一章讲客户提的需求太邪门了,鼠标键盘不太会用要程序员开发一个语音输入功能,还要系统中带类似QQ的功能:确实刚开始的客户的想法有点天真,但是随着信息化的越来越普遍,客户对信息系统也比较了解,特别年轻的信息管理人员,除了接受能力强,并且长期站在客户的角度对信息系统也有一些独特的见解,跳出技术框框外的想法: 其中有个年轻的信息人员聊天的时候说了一些对系统的要求,其中有一个功能是这样的,部门人员向库房申请一批物资,以前的做法就是先把申请单内容录入系统,然后再电话通知库

搞懂分布式技术19:使用RocketMQ事务消息解决分布式事务

搞懂分布式技术19:使用RocketMQ事务消息解决分布式事务 初步认识RocketMQ的核心模块 rocketmq模块 rocketmq-broker:接受生产者发来的消息并存储(通过调用rocketmq-store),消费者从这里取得消息. rocketmq-client:提供发送.接受消息的客户端API. rocketmq-namesrv:NameServer,类似于Zookeeper,这里保存着消息的TopicName,队列等运行时的元信息.(有点NameNode的味道) rocketm

[编织消息框架]前言

出书缘由 本项目名叫onequeue意为一流消息队列,参考对象为kafka 虽然最终结果可能达不到一流水准,但那不是主要的,主要是做的心态保持一流的态度 为什么作为kafka参考,又为什么自己重新做? 我在预研kafka发现在发送消息时网络断开会造成消息丢失,而底层没有提供失败回调给开发者使用,在某些场景来讲不允许丢消息的 进一步深入看下源码,虽然某些领域kafka开者人员很熟悉但综合水平觉得不如我,所以产生写消息框架的想法 面向读者 如果你喜欢网络传输,数据存储方向,那么本书会非常适合你,但你

微信公众号开发之自动消息回复和自定义菜单

(一)微信公众号开发之VS远程调试 (二)微信公众号开发之基础梳理 (三)微信公众号开发之自动消息回复和自定义菜单 前言 上一篇我们大致讲解了下微信公众号开发的基本原理和流程概述.本章主要是对文本消息回复和自定义菜单做一个记录和分解 消息回复 处理请求,并响应 1)关注 也可参考官网文档:https://mp.weixin.qq.com/wiki 当微信用户关注公众账号时,可以给其适当的提示.可以是欢迎词,可以是帮助提示.示例代码如下: class EventHandler : IHandler