CN113726896B - 基于商业智能房地产行业的任务分发系统 - Google Patents

Abstract

基于商业智能房地产行业的任务分发系统，包括：业务端，用于产生房地产相关的工作任务，并将所述工作任务发送到代理服务器，所述工作任务包括有效载荷和任务标签；任务执行端，用于向代理服务器发送订阅任务；所述代理服务器将根据接收到的工作任务，以及所述任务执行端的订阅任务，向所述任务执行端发送与订阅任务相关的工作任务。本发明通过任务订阅的方式，适应了房地产行业多人手多部门协同操作的庞杂业务流程，实现信息实时共享、多人协同管理。

Description

基于商业智能房地产行业的任务分发系统

技术领域

本发明房地产商业智能技术领域，更具体的说，特别涉及一种基于商业智能房地产行业的任务分发系统。

背景技术

随着房地产行业的不断深化，房产销售行业也同样急切面临着转型升级，由于该行业服务周期长，一个客户涉及多项业务，需多人手多部门协同操作。在如此庞杂的业务流程之下，实现信息实时共享、多人协同管理，就会产生了很多的困难，例如：企业员工在内部业务管理以及流程过程中，缺乏有效的信息反馈机制，员工反馈不及时；员工反馈工作自觉性不够，长期会影响员工沟通，导致出现业务办理拖沓；员工没有良好的工作习惯，每个人没有统一的规范进行管理自己的工作；人员流动性大换岗，离职时工作交接不全面，影响工作的延续性；人事统计员工工作业绩及表现，模糊不清，判断没有依据，数据不准确情况。

然而，现有技术中主要采用的是Kafka消息机制：

Kafka是一个消息系统，原本开发自LinkedIn，用作LinkedIn的活动流(ActivityStream)和运营数据处理管道(Pipeline)的基础。

活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。活动数据包括页面访问量(Page View)、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。运营数据指的是服务器的性能数据(CPU、IO使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。

近年来，活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分，这就需要一套稍微更加复杂的基础设施对其提供支持。

BrokerKafka集群包含一个或多个服务器，这种服务器被称为broker。

Topic每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。(物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处)。

PartitionParition是物理上的概念，每个Topic包含一个或多个Partition。

Producer负责发布消息到Kafka broker。

Consumer消息消费者，向Kafka broker读取消息的客户端。

Consumer Group每个Consumer属于一个特定的Consumer Group(可为每个Consumer指定group name，若不指定group name则属于默认的group)。

但是Kafka消息机制应用在房地产系统中，在一个客户涉及多项业务，需多人手多部门协同操作的庞杂业务流程中，实现信息实时共享、多人协同管理存在以下问题：

1、系统可用性降低。比如在系统中引入MQ(Message Queue)消息队列，那么万一MQ挂了怎么办呢？一旦MQ挂了，那么系统之间的通信就完全断开了，导致了系统不可用。一般而言，引入的外部依赖越多，系统越脆弱，每一个依赖出问题都会导致整个系统的崩溃。

2、系统复杂度提高。本来系统直接通过接口调用就可以了的，如果引入了MQ之后，就需要考虑MQ的各种情况，比如：消息的重复消费、消息丢失、保证消费顺序等等，使得系统越来越复杂。

3、数据一致性问题。比如A系统已经给客户返回操作成功，这时候操作BC都成功了，操作D却失败了，导致数据不一致。

所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。

因此，现有技术直接应用在房地产企业日常管理中存在的问题，有待于进一步改进和发展。

发明内容

(一)发明目的：为解决上述现有技术中存在的问题，本发明的目的是提供一种通过工作任务分配，替换现有通过业务流程实现房地产行业销售的系统。

(二)技术方案：为了解决上述技术问题，本技术方案提供基于商业智能房地产行业的任务分发系统，包括：

业务端，用于产生房地产相关的工作任务，并将所述工作任务发送到代理服务器，所述工作任务包括有效载荷和任务标签；

任务执行端，用于向代理服务器发送订阅任务；

所述代理服务器将根据接收到的工作任务，以及所述任务执行端的订阅任务，向所述任务执行端发送与订阅任务相关的工作任务。

所述基于商业智能房地产行业的任务分发系统，其中，有效载荷为任务对应的消息，任务标签包括：消息对应的任务种类、消息执行的任务角色、消息跳转策略；所述任务执行端通过任务标签中任务种类的选择，实现任务的订阅；所述任务分发系统包括任务角色单元，所述任务角色单元包括角色房地产行业对应的角色的规则设置和编辑。

所述基于商业智能房地产行业的任务分发系统，其中，所述任务执行端根据订阅的工作任务收到第一消息，执行第一消息完成任务；并产生第二消息，成为业务端，并将产生的第二消息后发送到代理服务器。

所述基于商业智能房地产行业的任务分发系统，其中，所述业务端、所述任务执行端分都安装实现任务分发的应用程序；所述应用程序的通过创建通信协议连接和代理服务器连接；之后应用程序和代理服务器之间设置虚拟连接以信道的连接方式，实现发布任务、订阅队列或接收任务。

所述基于商业智能房地产行业的任务分发系统，其中，所述通讯协议为传输控制协议。

所述基于商业智能房地产行业的任务分发系统，其中，所述代理服务器的任务路由包括三个部分：交换器、队列单元和消息绑定单元；所述消息绑定单元将收到的信息跟进预设策略形成不同的队列单元。

所述基于商业智能房地产行业的任务分发系统，其中，所述交换器包括direct、fanout、topic和headers。

所述基于商业智能房地产行业的任务分发系统，其中，所述代理服务器还包括任务分发单元，所述任务分发单元包括任务池分发机制，具体包括以下步骤；

多个业务端对应的任务队列顺序进入任务池暂存，任务池将存储的任务队列发送到批处理器，所述批处理器根据业务场景对应的业务端的订阅标签寻找对应的任务队列，并将对应的任务队列发送到相应的业务端。

所述基于商业智能房地产行业的任务分发系统，其中，当所述任务执行端和所述代理服务器断开连接，所述代理服务器自动把任务队列重新入队，发给另外一个任务执行端；当所述任务执行端拒绝接收任务，所代理服务器将工作任务重新发送给下一个任务执行端，或将工作任务从队列移除。

所述基于商业智能房地产行业的任务分发系统，其中，多个业务端之间的消息数据相互隔离。

(三)有益效果：本发明提供基于商业智能房地产行业的任务分发系统，通过任务梳理后，用任务订阅的方式来实现房地产行业销售，适应了房地产行业多人手多部门协同操作的庞杂业务流程，实现信息实时共享、多人协同管理。

附图说明

图1是本发明任务分发流程；

图2是本发明任务分发机制业务实现逻辑示意图；

图3是本发明角色分配串行方式实施例；

图4是本发明角色分配并行方式实施例；

图5是本发明角色分配异步处理方式实施例；

图6是本发明直接通过订单系统调用库存系统示意图；

图7是本发明通过任务队列实现订单系统、库存系统的解耦。

具体实施方式

下面结合优选的实施例对本发明做进一步详细说明，在以下的描述中阐述了更多的细节以便于充分理解本发明，但是，本发明显然能够以多种不同于此描述的其他方式来实施，本领域技术人员可以在不违背本发明内涵的情况下根据实际应用情况作类似推广、演绎，因此不应以此具体实施例的内容限制本发明的保护范围。

附图是本发明的实施例的示意图，需要注意的是，此附图仅作为示例，并非是按照等比例的条件绘制的，并且不应该以此作为对本发明的实际要求保护范围构成限制。

基于商业智能房地产行业的任务分发系统，包括：业务端、任务执行端和代理服务器，如图1所示。

所述业务端用于产生房地产相关的工作任务，并将所述工作任务发送到代理服务器，所述工作任务包括有效载荷和任务标签；所述任务执行端，用于向代理服务器发送订阅任务；所述业务端、所述任务执行端可以是计算机、智能手机、平板电脑等智能终端，所述业务端、所述任务执行端分都安装实现任务分发的应用程序。

有效载荷为任务对应的消息，任务标签包括：消息对应的任务种类、消息执行的任务角色、消息跳转策略；所述任务执行端通过任务标签中任务种类的选择，实现任务的订阅。

所述代理服务器将根据接收到的工作任务，以及所述任务执行端的订阅任务，向所述任务执行端发送与订阅任务相关的工作任务。

所述任务分发系统包括任务角色单元，所述任务角色单元包括角色房地产行业对应的角色的规则设置和编辑。所述任务角色单元依照房地产行业对应的角色将各个所述业务端、所述任务执行端根据角色规则进行角色设置和编辑。例如：所述任务角色单元将各个所述业务端、所述任务执行端设置不同角色，具体包括董事长、总经理、拓展部经理、项目总监、系统管理员、策划经理、策划人员、市场总监、市场经理、市场业务、案场助理、案场经理、案场销售、人事经理、人事、财务、行政等角色，以及各个角色对应的功能设置，比如，董事长的任务执行端每日跳转公司运营新数据查看提示，以提示董事长每天查看BI驾驶舱。

本发明智能房地产中的任务角色种类繁多，不同角色对应的任务功能或者说任务规则繁多，为了能够尽快命中。本发明设置网状的任务角色规则链条、与任务角色规则链条顺序对应却独立保存的消息订阅和发送规则链条。所述消息订阅和发送规则链条，分别对应各个任务角色的消息订阅标签和产生消息标签。本发明根据任务消息订阅和推送的数量，形成不同的任务消息片。所述任务角色消息片包括：以角色中消息订阅和发送规则为分组的任务消息片，例如当产生新的可以销售的楼盘任务信息，需要发送给订阅的不同角色的任务执行端时，将订阅该任务信息对应的任务角色组成一个任务消息片，在产生相应任务消息片的任务消息时，直接将任务信息发送给对应任务消息片内的所有任务执行端；以区域中消息订阅和发送规则为分组的任务消息片，例如当产生新的上海区域的待售信息时，订阅该区域待售任务的任务执行端组成一个任务消息片，在产生该区域的任务消息时，直接将任务信息发送给对应区域的任务消息片内的所有任务执行端。本发明消息跳转策略中，应用任务消息片优先进行刷选，以提高任务消息的发送速度。所述应用程序通过创建通信协议连接和代理服务器连接，所述通信协议可以是传输控制协议；之后应用程序和代理服务器之间设置虚拟连接以信道的连接方式，实现发布任务、订阅队列或接收任务。

所述任务执行端根据订阅的工作任务收到第一消息，执行第一消息完成任务；并产生第二消息，成为业务端，并将产生的第二消息发送到代理服务器。例如：角色为总经理的任务执行端接收到新线索提示，当点击新线索提示时，此时角色为总经理的任务执行端跳转至楼盘线索页，总经理对楼盘新线索进行查看，至此，完成第一消息的工作任务，角色为总经理的任务执行端成为总经理的业务端，总经理根据查看的楼盘新线索，通过角色为总经理的业务端新建楼盘线索，角色为总经理的业务端将新建的新楼盘线索发送至所述代理服务器。

所述代理服务器的任务路由包括三个部分：交换器、队列单元和消息绑定单元；所述消息绑定单元将收到的信息跟进预设策略形成不同的队列单元。

所述代理服务器还包括任务分发单元，所述任务分发单元包括任务池分发机制，具体包括以下步骤；

多个业务端对应的任务队列顺序进入任务池暂存，任务池将存储的任务队列发送到批处理器，所述批处理器根据业务场景对应的业务端的订阅标签寻找对应的任务队列，并将对应的任务队列发送到相应的业务端。

各个角色的业务端之间的消息数据相互隔离。所述代理服务器可以设置虚拟主机在各个实例间提供逻辑上分离，使得不同业务端安全保密的运行数据，不仅将代理服务器中不同的业务端、任务执行端区分开，而且避免了队列和交换器的命名冲突。

所述任务角色单元根据业务关系逻辑表对各个业务端、任务执行端进行角色规则设置和编辑，下面结合业务关系逻辑对所述任务分发系统进行举例说明。

所述业务端、所述任务执行端安装有实现任务分发的应用程序，所述任务角色单元依照业务关系逻辑对应角色将各个所述业务端、所述任务执行端根据角色规则进行角色设置和编辑。

本申请中基于商业智能房地产行业的任务分发系统，通过工作任务梳理实现将行业房地产行业楼盘销售，替换了原有通过梳理业务流程实现房地产行业楼盘销售的系统，使现有的任务系统，减少了操作难度，避免了用户使用前需要大量的培训，用户只需要在固定时间段内打开系统，完成当前角色的工作任务即可，并且在绩效计算中，任务分发系统可以计算并显示每个用户工作任务总量，以及任务量完成情况，通过数据对员工进行考核，避免了人事统计员对于员工工作业绩及表现，模糊不清，判断没有依据，数据不准确情况的问题。

下面对本申请中基于商业智能房地产行业的任务分发系统，各个所述业务端、所述任务执行端的角色设置和实现，根据业务关系逻辑表进行举例说明。

董事长，任务类别至少包括BI类(商业智能类)：

角色为董事长的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和每次触发计数加一次的触发结果。角色为董事长的任务执行端在预设周期内进行任务提示，执行人(董事长)点击任务提示，跳转至BI首页，查看BI驾驶舱，任务完成，触发结果计数加一次。其中，预设周期为每天；任务提示语为“公司运营最新数据快去看一下吧”；点击任务提示跳转至BI首页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

另外，角色为董事长的任务执行端的工作任务包括下述中，角色为总经理任务执行端的所有的工作任务。

所述任务执行端接收订阅任务包括两种方式：

一种是通过basic.consume命令，订阅某一个队列中的工作任务,channel(信道)会自动在处理完上一条消息之后，接收下一条工作任务。(同一个channel工作任务处理是串行的)。只要有任务来临，消费者就会自动接收，除非关闭channel或者取消订阅，否则客户端将会一直接收队列的工作任务。

一种是通过basic.get命令，主动获取队列中的工作任务，每次从队列中只获取一条工作任务。另外，多个任务执行端可以订阅同一个队列。

所述任务分发系统采用了2种方式，当第一种方式发生异常时，可以主动触发第二种方式。

所述任务执行端拒绝接收订阅任务包括两种方式：

当任务执行端和代理服务器断开连接，代理服务器自动把任务重新入队，发给另外一个任务执行端。

当任务执行端拒绝接收任务，采用basic.reject的命令。当reject的requeue参数设定为true，代理服务器会将工作任务重新发送给下一个任务执行端，而设定为false，代理服务器会将工作任务从队列移除，不发送给下一个任务执行端。

所述任务分发系统优先采用第一种接收订阅任务的方式。

在所述任务分发系统中，为了负载均衡，优选使用队列。

总经理，任务类别至少包括BI类、项目类、市场类、案场类、行政类、财务类人事类、策划类：

角色为总经理的任务执行端的BI类任务与董事长任务执行端的BI类任务相同，这里不再进行说明。

角色为总经理的任务执行端的项目类任务包括有七个，

第一，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和新建楼盘线索一次计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至楼盘线索页，查看新的楼盘线索，并新建楼盘线索，成为角色为总经理的业务端，并将产生的新建楼盘线索发送到代理服务器，任务完成，触发结果新建楼盘线索计数加一次。其中，预设周期为每月；任务提示语可以是“虾有虾路，蟹有蟹路您有新线索赶紧添加吧”；点击任务提示跳转至楼盘线索页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第二，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和跟进楼盘一次计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至楼盘线索页，查看楼盘线索，并跟进楼盘线索，成为角色为总经理的业务端，并将产生的跟进楼盘线索发送到代理服务器，任务完成，触发结果跟进楼盘线索计数加一次。其中，预设周期为每月；任务提示语可以是“新的线索跟进要勤快哦”；点击任务提示跳转至楼盘线索页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第三，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和楼盘线索查看计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至员工提供楼盘线索，查看楼盘线索，任务完成，触发结果楼盘线索查看计数加一次。其中，预设周期为每周；任务提示语可以是“员工提供的线索赶紧看看吧”；点击任务提示跳转至员工提供楼盘线索通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第四，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和楼盘线索跟进查看计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至员工跟进楼盘线索，查看员工跟进楼盘线索情况，任务完成，触发结果楼盘线索跟进查看计数加一次。其中，预设周期为每周；任务提示语可以是“看看员工的线索情况吧”；点击任务提示跳转至员工跟进楼盘线索通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第五，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和项目开始启动计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至楼盘线索页，启动调研楼盘项目，成为角色为总经理的业务端，并将产生启动调研楼盘项目的工作任务发送到代理服务器，任务完成，触发结果项目开始启动计数加一次。其中，预设周期为每月；任务提示语可以是“线索信息完善后，就启动楼盘深入调研吧”；点击任务提示跳转至楼盘线索页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第六，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和新建关系人成功后计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，新建关系人，成为角色为总经理的业务端，并将新建的关系人发送到代理服务器，任务完成，触发结果新建关系人成功计数加一次。其中，预设周期为每月；任务提示语可以是“决定你命运的大V，赶紧保存起来”；点击任务提示跳转至新建关系人通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第七，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和按七大任务员工提交完成接标成功计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至风险评估页，查看项目七大任务接标成功项目，任务完成，触发结果按七大任务员工提交完成接标成功计数加一次。其中，预设周期为每季度；任务提示语可以是“看看项目调研的怎么样”；点击任务提示跳转至风险评估页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

角色为总经理的任务执行端的市场类任务包括有二个，

第一，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和进入查看员工分销页面计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至员工新入分销列表，查看员工新入分销列表，任务完成，触发结果楼盘线索查看计数加一次。其中，预设周期为每月；任务提示语可以是“看看员工的分销多不多”；点击任务提示跳转至员工新入分销列表通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第二，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和进入查看员工分销跟进页面查看计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至员工分销跟进列表，查看员工分销跟进列表，任务完成，触发结果进入查看员工分销跟进页面查看计数加一次。其中，预设周期为每月；任务提示语可以是“检查员工们对分销服务好不好”；点击任务提示跳转至员工分销跟进列表通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

角色为总经理的任务执行端的案场类任务包括有三个，

第一，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和会议查看一次计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至会议详情，查看会议记录，任务完成，触发结果会议查看计数加一次。其中，预设周期为每日；任务提示语可以是“看看今天的会议记录”；点击任务提示跳转至会议详情通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第二，角色为总经理的任务执行端，任务触发逻辑包括，根据周期触发的触发条件，和楼盘销控查看一次计数加一次的触发结果。角色为总经理的任务执行端在预设周期内进行任务提示，执行人(总经理)点击任务提示，跳转至楼盘销控页，查看楼盘销控，任务完成，触发结果楼盘销控查看计数加一次。其中，预设周期为每周；任务提示语可以是“看看楼盘卖了多少套吧”；点击任务提示跳转至楼盘销控页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第三，角色为总经理的任务执行端，任务触发逻辑包括，有被发送到本人的触发条件，和有待办任务，查看后消失的触发结果。角色为总经理的任务执行端在接收到发送给总经理的工作任务提示，执行人(总经理)点击任务提示，跳转至汇报详情页，查看工作汇报，任务完成，触发结果待办任务消失。其中，将任务指定给角色为总经理的任务执行端，是通过任务标签实现；任务提示语可以是“工作汇报可是干货，好好看看”；点击任务提示跳转至汇报详情页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

角色为总经理的任务执行端的行政类任务包括有四个，财务类任务包括有二个，人事类任务包括有一个，触发条件为周期触发，因此，再次不再一一进行详细的陈述。

角色为总经理的任务执行端的策划类任务包括有三个，

第一，角色为总经理的任务执行端，任务触发逻辑包括，有新的楼盘推文发送成功的触发条件，和有待办任务，查看后消失的触发结果。代理服务器接收到新的楼盘推文后，角色为总经理的任务执行端接收到发送给总经理的工作任务提示，执行人(总经理)点击任务提示，跳转至楼盘推文页，查看楼盘最新推文，任务完成，触发结果待办任务消失。其中，将任务指定给角色为总经理的任务执行端，是通过任务标签实现；任务提示语可以是“楼盘名称：有新推文啦”；点击任务提示跳转至楼盘推文页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第二，角色为总经理的任务执行端，任务触发逻辑包括，有楼盘信息变更的触发条件，和有待办任务，查看后消失的触发结果。代理服务器接收到楼盘信息变更后，角色为总经理的任务执行端接收到发送给总经理的工作任务提示，执行人(总经理)点击任务提示，跳转至楼盘详情页，查看楼盘信息维护，任务完成，触发结果待办任务消失。其中，将任务指定给角色为总经理的任务执行端，是通过任务标签实现；任务提示语可以是“楼盘名称：信息有变化喽”；点击任务提示跳转至楼盘详情页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

第三，角色为总经理的任务执行端，任务触发逻辑包括，有新的分销推文发布成功的触发条件，和有待办任务，查看后消失的触发结果。代理服务器接收到新的分销推文后，角色为总经理的任务执行端接收到发送给总经理的工作任务提示，执行人(总经理)点击任务提示，跳转至宣传推送页，查看楼盘信息维护，任务完成，触发结果待办任务消失。其中，将任务指定给角色为总经理的任务执行端，是通过任务标签实现；任务提示语可以是“又有新的消息给分销啦”；点击任务提示跳转至楼盘详情页通过任务标签的消息跳转策略实现；对任务提示的点击通过输入设备实现。

角色为总经理的任务执行端、业务端的应用程序和代理服务器之间设置的信道的虚拟连接可以是，创建高级消息队列协议信道进行任务传输，实现发布工作任务、订阅队列或订阅任务。

此时所述代理服务器的任务路由包括三个部分：交换器、队列单元和消息绑定单元；所述消息绑定单元将收到的信息跟进预设策略形成不同的队列单元。

具体的说，当业务端将工作任务发送给队列时，首先会发送给交换器。然后根据确定的规则(路由键)，决定工作任务投递到那个队列/而队列通过路由键绑定到交换器，此处确定的规则可以是预设规则。

通过创建的高级消息队列协议信道实现工作任务、订阅队列或订阅任务，不仅可以完成不同的使用场景；而且对于发送任务给代理服务器的业务端来说，无需关心服务的另外一端的逻辑(即队列和任务执行端)。

所述交换器包括四种类型：direct(控制器)、fanout(分列)、topic(主题)和headers(头部标题)，优选使用direct，topic交换器。

在所述任务分发系统中还包括房地产其它对应角色的任务执行端、业务端，具体角色除董事长、总经理外还可以包括拓展部经理、项目总监、系统管理员、策划经理、策划人员、市场总监、市场经理、市场业务、案场助理、案场经理、案场销售、人事经理、人事、财务、行政等。每个任务执行端、业务端根据对应角色保存的消息订阅和发送规则链条确认任务触发逻辑。

每个角色的业务执行端、业务端根据任务需求进行设置：任务类别、任务周期、任务提示语、触发条件、跳转策略及任务触发逻辑等。

下面为角色为董事长、总经理的业务逻辑表：

这里不再对每个职务的任务执行端、业务端工作任务内容进行具体说明，但是不同职务的业务端产生的不同的任务信息，通过在所述代理服务器设置虚拟主机在，实现各个实例间提供逻辑上分离，使得不同业务端安全保密的运行数据，不仅将代理服务器中不同的业务端、任务执行端区分开，而且避免了队列和交换器的命名冲突。此时，只需要运行一个Rabbit(代理服务器)，根据需求启动或关闭vhost(虚拟主机)即可，具体实现方式如下：

查看Rabbit运行哪些vhost(查看服务器运行哪些虚拟主机代码)：

rabbitmqctllist_vhosts；

创建vhost(创建虚拟主机代码)：rabbitmqctladd_vhost[vhost_name]；

删除vhost(删除虚拟主机代码)：rabbitmqctldelete_vhost[vhost_name]。

所述代理服务器的任务分发单元包括任务池分发机制，业务端触发工作任务，多个业务端对应的任务队列顺序进入任务池，任务池将任务队列暂存，任务池将存储的任务队列发送到批处理器，所述批处理器根据业务场景对应的业务端的订阅标签寻找对应的任务队列，并将对应的任务队列发送到相应的业务端，如图2所示。

在所述任务分发系统中设定每个队列和交换器的durable属性为True，用于防止重启和掉电而导致队列和交换器消失。

为了避免工作任务数据不丢失，工作任务的投递模式选项(delivery_mode)设置为2，并将工作任务发送到持久化交换器，到达持久化队列，此时，数据实现持久化。

为了避免工作任务发送到持久化交换器时，出现宕机，造成工作任务无法持久化，可以使用以下方式实现：

第一，高级消息队列协议事务，将信道设置成事务模式，然后通过信道发送所有想确认的任务，一旦完成，提交事务。如果第一条命令执行失败，后面的命令也将会被忽略。

第二，发送方确认模式，是使业务端可以异步的发送工作任务，同时异步的接收确认。如果工作任务丢失，会收到一个nack任务，如果成功，则会收到一个nack任务。

但是由于事务的粒度较粗，大大降低了代理服务器的效率，而发送方确认模式同事务相比，没有了任务回滚的概念，对代理服务器的性能影响可以忽略不计。因此在所述任务分发系统中，最优使用发送方确认模式，来保证工作任务发送到持久化交换器时，出现宕机，造成工作任务无法持久化。

关于工作任务的存储：

每个工作任务都指定它的队列，每个队列在存在不同的物理分区内，每个物理分区存储对应队列的所有工作任务和索引文件。例如：创建topic1和topic2两个topic，且分别有13个和19个分区，则整个集群上会相应会生成共32个文件夹(所用集群共8个节点，此处topic1和topic2 replication-factor均为1)。

每个日志文件都是一个log entrie序列，每个log entrie包含一个4字节整型数值(值为N+5)，1个字节的"magic value"，4个字节的CRC(循环冗余)校验码，其后跟N个字节任务的有效载荷。每条任务都有一个当前分区下唯一的64字节的offset(开端)，它指明了这条任务的起始位置。磁盘上存储的任务格式为：

1

2 message length：4bytes(value 1+4+n)

3 “magic”value：1bytes

4 crc：4bytes

5 payload：n bytes

log entries分成多个segment(片段)，每个segment以该segment第一条任务的offset(开端)命名并以“.”为后缀。另外会有一个索引文件，它标明了每个segment下包含的log entry的offset范围。

因为每条工作任务是被append(附加)到物理分区中，属于顺序写磁盘，因此效率非常高，保证了本系统高吞吐率。每个队列的物理分区内会保留所有的工作任务，无论工作任务被消费与否。

当因为磁盘限制时，对数据的删除的方式包括两种：

第一，基于时间对数据进行删除，例如，通过配置$/config/server.properties删除一周前的数据；

第二，基于物理分区文件大小进行删除，例如，在物理分区文件超过1GB时删除旧数据。

需要说明的是，所述任务分发系统中读取特定任务的时间复杂度为O(1)，与文件大小无关，所以这里删除过期文件与提高所述任务分发系统性能无关。选择具体的删除策略只与磁盘以及具体的需求有关。所述任务分发系统会为每一个消费组保留一些元数据任务信息——当前消费的任务的position(位置)，也即offset(开端)。这个offset由任务执行端控制。正常情况下任务执行端会在消费完一条任务后递增该offset。任务执行端可以将offset设成一个较小的值，重新消费一些任务。因为offet由Consumer控制，所以代理服务器是无状态的，它不需要标记哪些工作任务被哪些消费过，也不需要通过缓存代理去保证同一个消费组只有一个任务执行端能消费某一条工作任务，因此也不需要锁机制，进一步保证了本系统的高吞吐率。

业务端发送工作任务到缓存代理时，会根据分区机制选择将其存储到哪一个分区内，不同的工作任务并行写入不同缓存代理的不同分区里，实现了负载均衡，极大的提高了吞吐率。具体可以在$_HOME/config/server.properties中通过配置项num.partitions来指定新建队列的默认分区数量，也可在创建队列时通过参数指定，同时也可以在队列创建之后通过所述任务分发系统的修改工具进行修改。

在发送一条工作任务时，可以指定这条工作任务的key，业务端根据这个key和分区机制来判断应该将这条工作任务发送到哪个分区。分区机制可以通过指定业务端的分区，可以通过class这一参数来指定，该class可以实现业务端分区接口。如果key可以被解析为整数则将对应的整数与分区总数取余，该任务会被发送到该数对应的分区。(每个分区都会有个序号,序号从0开始)。

例如：将上述中的类作为partition.class，并通过代码发送20条任务(key分别为0，1，2，3)至topic3(包含4个Partition)。

则key相同的任务会被发送并存储到同一个分区里，而且key的序号正好和分区序号相同。(分区序号从0开始，key也从0开始)。具体可以是通过Java程序调用任务执行端后打印出的任务列表。

使用Consumer high level API时，同一队列的一条工作任务只能被同一个消费组内的一个任务执行端消费，但多个消费组可同时消费这一工作任务。

所述任务分发系统用来实现一个队列工作任务的广播(发给所有的任务执行端)和单播(发给某一个任务执行端)的手段：一个队列可以对应多个消费分组。如果需要实现广播，只要每个任务执行端有一个独立的分组就可以了。要实现单播只要所有的任务执行端在同一分组里。用消费分组还可以将任务执行端进行自由的分组而不需要多次发送任务到不同的队列。

所述任务分发系统同时提供离线处理和实时处理。使用分布式实时计算对任务进行实时在线处理，同时使用分布式批处理计算进行离线处理，同时将数据实时备份到另一个数据中心，只需要保证这三个操作所使用的任务执行端属于不同的消费分组即可。

这里对上述进行举例说明：首先创建一个Topic(名为topic1，包含3个Partition)，然后创建一个属于group1的Consumer实例，并创建三个属于group2的Consumer实例，最后通过Producer向topic1发送key分别为1，2，3的任务。结果发现属于group1的Consumer收到了所有的这三条任务，同时group2中的3个Consumer分别收到了key为1，2，3的任务。

所述任务分发系统选择由业务端向代理服务器推送工作任务，并由消费分组从代理服务器拉取工作任务。在本系统中，推送模式(push)和拉取模式(pull)各有优劣。

推送模式很难适应消费速率不同的消费者，因为工作任务发送速率是由代理服务器决定的。推送模式的目标是尽可能以最快速度传递任务，但是这样很容易造成任务执行端来不及处理任务，典型的表现就是拒绝服务以及网络拥塞。而拉取模式则可以根据任务执行端的消费能力以适当的速率消费工作任务。

在所述任务分发系统中优选使用拉取模式。拉取模式可简化代理服务器的设计，任务执行端可自主控制消费任务的速率，同时任务执行端可以自己控制消费方式，具体包括：批量消费、逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

消息投递保证机制包括以下三种：

At most once任务可能会丢，但绝不会重复传输；

At least one任务绝不会丢，但可能会重复传输；

Exactly once每条任务肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。

当业务端向代理服务器发送工作任务时，一旦这条任务被送交，由于副本机制的存在，工作任务就不会丢。但是如果业务端发送工作任务给代理服务器后，遇到网络问题而造成通信中断，那业务端就无法判断该条任务是否已经被送交到代理服务器。业务端可以生成主键关键字，发生故障时幂等性的重试多次，这样就做到了Exactly once。一条工作任务业务端到代理服务器是确保了At least once，可通过设置业务端异步发送实现At mostonce。

针对consumer high level API对任务从代理服务器到任务执行端的消息投递保证机制语义进行说明。

在从代理服务器读取工作任务后，可以选择送交，该操作会在Zookeeper中保存该任务执行端在该分区中读取的工作任务的开端。该任务执行端下一次再读该分区时会从下一条开始读取。如工作任务未送交，下一次读取的开始位置会跟上一次工作任务送交之后的开始位置相同。当然可以将任务执行端设置为自动提交，即任务执行端一旦读到数据立即自动送交。上述内容确保了所述业务分发系统的Exactly once。所述业务分发系统任务执行端读取完工作任务后，进行进一步处理，而工作任务处理与送交的顺序在很大程度上决定了工作任务从代理服务器到任务执行端的delivery guarantee semantic。

读完任务先送交再处理工作任务：这种模式下，如果任务执行端在送交后还没来得及处理任务就工作异常了，下次重新开始工作后就无法读到刚刚已提交而未处理的任务，这就对应于At most once。

读完工作任务先处理送交：这种模式下，如果在处理完任务之后送交之前任务执行端工作异常了，下次重新开始工作时还会处理刚刚未送交的工作任务，实际上该工作任务已经被处理过了。这就对应于At least once。

工作任务都有一个主键关键字，所以工作任务的处理往往具有幂等性，即多次处理这一条工作任务跟只处理一次是等效的，那就可以认为是Exactly once。

当使用Exactly once时，需要协调工作任务的开端和实际操作的输出。具体的做法可以是引入两阶段提交。当让工作任务的开端和操作输入存在同一个地方时，Exactlyonce会更简洁和通用。也可以是任务执行端拿到工作任务后把数据放到分布式文件系统，把最新的工作任务的开端和数据本身一起写到分布式文件系统，那就可以保证数据的输出和工作任务的开端的更新要么都完成，要么都不完成，间接实现Exactly once。现有的highlevel API，offset是存于Zookeeper中的，无法存于分布式文件系统，而low level API的offset是由自己去维护的，可以将之存于分布式文件系统中。

所述任务分发系统中默认保证At least once，并且允许通过设置业务端异步提交来实现At most once。当使用Exactly once时，本系统还包括外部存储系统。

所述任务角色单元对各个业务端、任务执行端进行角色分配完成后可以通过发送注册邮件、注册短信来进行通知。

所述任务分发系统的任务角色单元完成业务端或任务执行端的角色分配具体实现流程包括：

第一，串行方式，成功将注册信息写入数据库后，发送注册邮件，再发送注册短信，全部完成后再返回给业务端或任务执行端，此种为串行方式；

第二，并行方式，将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信，全部完成后再返回给业务端或任务执行端，此种为并行方式，并行方式相对于与并行的方式，缩短了处理的时间；

第三，异步处理方式，成功将注册信息写入数据库后，将发送注册邮件、发生注册短信的任务写入任务队列，然后返回给业务端或任务执行端，注册邮件、注册短信的发送需要异步去任务队列读取；

下面进行具体说明：

假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次(1000/150)。并行方式处理的请求量是10次(1000/100)，如图3、4所示。

而异步处理方式中，如图5所示，业务端或任务执行端的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。发送注册邮件、发送注册短信写入任务队列后，直接返回，因为写入任务队列的速度很快，基本可以忽略，所述业务端或任务执行端的响应时间可能是50毫秒，此时系统的吞吐量提高到每秒20QPS。比串行提高了3倍，比并行提高了两倍，因此所述任务分发系统最优使用异步处理方式。

在所述任务分发系统中，所述代理服务器将所述业务端产生房地产相关的工作任务进行写入存储后，将所述工作任务写入订阅队列后，返回所述业务端，此时任务执行端根据订阅任务对订阅的任务队列进行异步读取，读取对于的工作任务信息。

在所述任务分发系统中，有房屋出售时，案场销售的业务端可以直接通过订单系统调用库存系统的接口，通知库存系统根据订单对库存进行删减，如图6所示。

若库存系统无法访问，则订单减库存将失败，从而导致订单失败，因此所述任务分发系统在处理过程中间插入了一个隐含的、基于数据的接口层，在房屋出售时：订单系统完成持久化处理，将任务写入任务队列，返回业务端订单下单成功；库存系统订阅下单的任务，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存的删减操作，如图7所示。避免了，在下单时库存系统不能正常使用，影响正常下单，在保证订单系统、库存系统遵守同样的接口约束下，实现订单系统与库存系统的应用解耦，从而允许独立的扩展或修改订单系统、库存系统两边的处理过程。

所述任务分发系统还可以使用消息机制：通过系统内部的存储(DB/缓存)来触发对应的业务节点。当业务端需要产生工作任务时，消息机制触发插入存储(DB/缓存)数据，任务执行端通过http等形式轮询的形式来获得工作任务，来达到对应的任务执行端对应的工作任务的效果。

所述的任务分发系统，针对房产行业做了特殊的行业特性的任务分发。所有的系统内员工都是任务的产生者和消费者，都身兼2种身份。通过业务流的流转，到达所有的行为都会进行有效的任务分发机制，来完善整个的业务的到达率/完成率。

所述的任务分发系统，可以直接根据提示进行任务处理，无需大量的培训，减少了操作难度，大大提高了员工的自觉性和积极性，极大降低了培训成本，提高了使用频率，提高了企业的管理水平，从而提高了用户实施使用成功率。

另外，传统企业员工在内部业务管理以及流程过程中，缺乏有效的信息反馈机制，员工反馈不及时，而所述任务分发系统中，业务流程反馈及时(周期性任务为周期触发，触发任务在接收到相关的任务后，任务执行端就会接收到相关工作任务)，并且可以即时通信，将立即要办理的，或者已经办理的事项给自己一个信息反馈或者给别人一个反馈，让任务执行端第一时间收到；同时，主管上级定期查看员工的工作情况，提高员工工作自觉性，并且员工的每个任务都具有时效性，对于超时的任务会额外提醒，并给予更多时间进行补充；培训员工良好工作习惯：对工作进行了梳理形成了按日，周，月，季等工作周期，让事项根据周期的变化，形成了有规律的循环；提升员工工作延续性：有对任务进行分派，当人员离岗可以及时将任务分派给其它员工，继续完成相应的工作，避免了人员流动性大换岗，离职时工作交接不全面，影响工作的延续性的问题；便捷的人员考核统计：人事统计员根据每个员工，每月需要做的任务，并统计完成情况，通过数据对员工进行考核，避免了人事统计员对于员工工作业绩及表现，模糊不清，判断没有依据，数据不准确情况的问题。

由于任务队列解耦了处理过程，所以增大任务入队和处理的频率，只需要另外增加处理过程即可，不需要改变代码、不需要调节参数，简化了扩展过程。

任务队列能够使关键组件顶住突发的访问压力，不会因为突发的超负荷的请求而完全崩溃。

任务队列降低了进程间的耦合度，当一个处理任务的进程挂掉，加入队列中的任务仍然可以在系统恢复后被处理。

本发明具有任务角色节点网络图，本发明的任务队列，可以对挂掉的进程进行数据提取和分析，将挂掉进程的任务角色提取，并将提取的任务角色在任务角色节点网络图中进行匹配，获取同等级和上一级别的任务角色节点，并在后续任务队列中优先处理和发送。所述优先发送的同等级和上一级别的任务角色节点添加进程挂掉提示。

通过分区内任务的有序性，保证数据会按照特定的顺序来处理。

任务队列通过一个缓冲层来帮助任务最高效率的执行，有助于控制和优化数据流经过系统的速度。

任务队列提供了异步处理机制，允许用户把一个任务放入队列，不即时处理，根据用户需要再去处理。

以上内容是对本发明创造的优选的实施例的说明，可以帮助本领域技术人员更充分地理解本发明创造的技术方案。但是，这些实施例仅仅是举例说明，不能认定本发明创造的具体实施方式仅限于这些实施例的说明。对本发明创造所属技术领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出若干简单推演和变换，都应当视为属于本发明创造的保护范围。

Claims (9)

1.基于商业智能房地产行业的任务分发系统，其特征在于，包括：

业务端，用于产生房地产相关的工作任务，并将所述工作任务发送到代理服务器，所述工作任务包括有效载荷和任务标签；

任务执行端，用于向代理服务器发送订阅任务；

所述代理服务器将根据接收到的工作任务，以及所述任务执行端的订阅任务，向所述任务执行端发送与订阅任务相关的工作任务；

所述任务执行端根据订阅的工作任务收到第一消息，执行第一消息完成任务；并产生第二消息，成为业务端，并将产生的第二消息后发送到代理服务器；

所述代理服务器包括任务角色单元，所述任务角色单元包括角色房地产行业对应的角色的规则设置和编辑；所述任务分发系统设置网状的任务角色规则链条、与任务角色规则链条顺序对应却独立保存的消息订阅和发送规则链条，所述消息订阅和发送规则链条，分别对应各个任务角色的消息订阅标签和产生消息标签；

所述任务分发系统根据任务消息订阅和推送的数量，形成不同的任务消息片，所述任务角色消息片包括：以角色中消息订阅和发送规则为分组的任务消息片，以区域中消息订阅和发送规则为分组的任务消息片；消息跳转策略中，应用任务消息片优先进行刷选。

2.根据权利要求1所述基于商业智能房地产行业的任务分发系统，其特征在于，有效载荷为任务对应的消息，任务标签包括：消息对应的任务种类、消息执行的任务角色、消息跳转策略；所述任务执行端通过任务标签中任务种类的选择，实现任务的订阅。

3.根据权利要求1所述基于商业智能房地产行业的任务分发系统，其特征在于，所述业务端、所述任务执行端分都安装实现任务分发的应用程序；所述应用程序通过创建通信协议和代理服务器连接；之后应用程序和代理服务器之间设置虚拟连接以信道的连接方式，实现发布任务、订阅队列或接收任务。

4.根据权利要求3所述基于商业智能房地产行业的任务分发系统，其特征在于，所述通讯协议为传输控制协议。

5.根据权利要求3所述基于商业智能房地产行业的任务分发系统，其特征在于，所述代理服务器的任务路由包括三个部分：交换器、队列单元和消息绑定单元；所述消息绑定单元将收到的信息跟进预设策略形成不同的队列单元。

6.根据权利要求5所述基于商业智能房地产行业的任务分发系统，其特在于，所述交换器包括direct、fanout、topic和headers。

7.根据权利要求5所述基于商业智能房地产行业的任务分发系统，其特在于，所述任务分发单元包括任务池分发机制，具体包括以下步骤；

多个业务端对应的任务队列顺序进入任务池暂存，任务池将存储的任务队列发送到批处理器，所述批处理器根据业务场景对应的业务端的订阅标签寻找对应的任务队列，并将对应的任务队列发送到相应的业务端；

代理服务器具有任务角色节点网络图，任务队列对挂掉的进程进行数据提取和分析，将挂掉进程的任务角色提取，并将提取的任务角色在任务角色节点网络图中进行匹配，获取同等级和上一级别的任务角色节点，并在后续任务队列中优先处理和发送，优先发送的同等级和上一级别的任务角色节点添加进程挂掉提示。

8.根据权利要求7所述基于商业智能房地产行业的任务分发系统，其特征在于，当所述任务执行端和所述代理服务器断开连接，所述代理服务器自动把任务队列重新入队，发给另外一个任务执行端；当所述任务执行端拒绝接收任务，所代理服务器将工作任务重新发送给下一个任务执行端，或将工作任务从队列移除。

9.根据权利要求2所述基于商业智能房地产行业的任务分发系统，其特征在于，多个业务端之间的消息数据相互隔离。

Images