ZSmart-CEP2.0分流配置文档.docxVIP

ZSmart-CEP2.0分流配置说明

为什么需要分流？什么是分流？

在CEP2.0中，信令的业务处理逻辑是通过事件处理网络（EPN）来表现的，EPN可以部署在一个或多个处理结点（PN）上。当EPN中的某一个处理逻辑由于数据流量过大或处理逻辑过于复杂等原因存在性能瓶颈时，会使用分流的方式来分担该结点的处理压力。

分流是通过增加进程或主机的方式，将存在瓶颈的业务环节进行分布式部署，最终提高处理性能的方式。

分流的原理是什么？

由于操作系统的进程并行度比线程高，单纯增加线程无法充分利用主机资源，所以在增加线程无法获得满意性能时，可以通过增加进程数，即多部署几个PN来充分发挥主机资源，提高处理性能。但是当流量过大，单主机资源不足时，就需要增加主机，在新增的主机上多部署几个PN来提高性能。

如图1，结点B是性能瓶颈，通过再增加一个分支，可以分担A分发给B的流量，消除性能瓶颈。但是A要把那些信令分给B，哪些信令分给B2呢？于是有一个分流规则的选择。分流规则有三种：

广播（默认），A将信令复制一份分别全量的发给B和B2。

随机，A随机的把信令发给B或B2。

字段哈希，根据信令某些字段的哈希值来判断分给B还是B2。

广播（BROADCAST），由于需要复制信令，B和B2都是接收全量的数据，无法达到分担流量的目的。所以该方式很少用，如果不配分流方式，默认为广播的方式。

随机（SHUFFLE），可以根据B和B的权重（weight）来分发信令，如果B和B2的权重相同，则双方各分担一半的流量；如果B的权重值为1，B2的权重值为2，则B分担1/3的流量，B2分担2/3的流量。

字段哈希（FIELD），可以根据信令的数据来做分发，带有业务属性，一般使用维度字段来做哈希，这样可以把相同维度的信令分给同一个结点。

一般，如果B是丰富或预处理PE，则使用随机的分发方式。如果B是统计PE则使用维度字段为哈希字段，使用字段哈希的分流方式。

注意：丰富PE如果没有采用丰富拉平的配置，则不能在之后做分流操作。

如何分流？各个配置属性代表什么含义？

pn_code表示PE需要部署在哪几个进程中，如：

pecode=tel_wap_tdr_100kso_path=xxxconfig_uri=xxx”pn_code=3000”

表示将PE[tel_wap_tdr_100k]只部署在PN[3000]上，此时只有一个PE的实例[tel_wap_tdr_100k@3000]

pecode=tel_wap_tdr_100kso_path=xxxconfig_uri=xxx”pn_code=3000,3001”

表示将PE[tel_wap_tdr_100k]分别部署在PN[3000]和PN[3001]上，此时存在两个PE的实例[tel_wap_tdr_100k@3000]和[tel_wap_tdr_100k@3001]共同完成该环节的业务处理。

group_code为分发组标识，接收相同事件且持有相同group_code的PE在同一个分发组内，其分发规则必须相同，如果为字段哈希分流，那么hash_fields也必须相同。group_code并不要求全局唯一，接收不同事件的的PE可以配置相同的group_code。group_code配置为0时不起作用。

is_private描述的是PE发出事件的影响范围，默认值为true，表示只有本PN内的PE才能接收到该PE发出的事件，如果配置为false，则所有PE都可以接收。

案例分析

以贵州3000中的某一片段为例：

ps_net_cdr从ztpclient_pe(3000)中接过来被tel_wap_tdr_100k(3500)和get_speed(30071)接收，这里是EPN的主流程，存在性能瓶颈，需要分流。

具体分流配置的步骤如下：

将除ztpclient_pe(3000)以外的其他PE中的pn_code=”3000”替换为pn_code=”3000,3001”

将ztpclient_pe(3000)设置is_private=”false”（见行1）

为tel_wap_tdr_100k(3500)和get_speed(30071)设置分流规则，指定分发组（见行8和行16-21）。

最后得到效果见图。