一些业务逻辑####

发表于 2024/05/28

作者 klizzz

18 分钟阅读

一些业务逻辑####

[TOC]

# 确定原生事件是否可用

1. 原子事件与集群的对应

        
      
// 捕鱼原生事件号段
enum eDicFishEventSectionNo
{
	TK_ENUM_FISH_EVENT_SECTIONNO_BEGIN = 10009200,		// 开始
	TK_ENUM_FISH_EVENT_SECTIONNO_END = 10009599,		// 结束
};
// 千炮捕鱼原生事件号段
enum eDicQianPaoFishEventSectionNo
{
	TK_ENUM_QIANPAOFISH_EVENT_SECTIONNO_BEGIN = 10009600,		// 开始
	TK_ENUM_QIANPAOFISH_EVENT_SECTIONNO_END = 10009999,		// 结束
};
// 炸弹人：
{
	TK_ENUM_MENGQIUDAZHAN_ZHADANREN_SECTIONNO_BEGIN     = 10005200,		// 开始
	TK_ENUM_MENGQIUDAZHAN_ZHADANREN_SECTIONNO_END       = 10009199,		// 结束
}

不是上面三个集群都会发到默认集群（通用集群）

以上号段信息来自唐成龙，copy自CMT的代码。

2. 业务步骤

根据业务确定号段：

集群	sid 开始	sid 结束
萌球炸弹人	10005200	10009199
捕鱼	10009200	10009599
千炮捕鱼	10009600	10009999
地主、通用	10000000	10005199

在 10.30.127.15:3306 . API_TEST . flag_useraction_data 中根据上表的业务分布大概确定一个空的 sid 号。

flag_useraction_data 用于内部维护所有原生事件，记录信息较全，例如事件描述等。
CMA 监控验证一下 sid 是否被占用：

id 可能被其他业务占用做别的事情，因此也需要在监控中验证一下。

tkcvs-001-mysql.service.jjserv.local:4306 . CVS . define_esprule_general

内外网配置验证 sid 是否被占用。

SELECT * FROM define_esprule_general where sid IN (10002004);
SELECT * FROM define_esprule_cbmg where sid IN (10002004);
SELECT * FROM define_esprule_flag where sid IN (10002004);
SELECT * FROM define_esprule_jjby where sid IN (10002004);
SELECT * FROM define_esprule_mqzdr where sid IN (10002004);
SELECT * FROM define_esprule_qpby where sid IN (10002004);

表 define_esprule_general 用于配置规则。

每个 sid 对应的（原生）事件，可能会对应多个 define_esprule_general 中的规则。

外网需登录堡垒机。

在 10.30.127.15:3306 . API_TEST . flag_useraction_data 中插入该 id。

# EVT 根据日志排除 bug

积分 status 的含义：

status	含义
30	已经验证过正确的
10	正确
0	待验证
-20	验证错误
-80	下线

在 BTO 上下载 TKNOSService.log 日志。
直接看日志，可以定位到问题，直接解决。
日志只能定位到id，或者无法定位，需本地调试。

本地调试时，需确认 TKNOSService.ini 中的配置，以保证？

# 集群与 redis 集群的对应关系

积分cluster	redis实例
redis_evt_A	evt-001-redis、evt-004-redis
redis_evt_AA	evt-002-redis、evt-004-redis
redis_evt_old	evt-003-redis、evt-004-redis
ssdb_evt_manage	evtcycle-001-ssdb、evt-004-redis
ssdb_evt_B	evtssdb-001-ssdb、evt-004-redis
ssdb_evt_C	marker-001-ssdb
redis_evt_SSDB	evt-003-redis
redis_mq	mengqiu-001-redis
redis_flag	utd-001-redis
redis_fish	qpfish-001-redis
redis_jjfish	jjfish-001-redis
redis_jgbc	matchsave-001-redis
TKMarkerService	marker-001-ssdb

# 查询满足某个条件的所有用户的积分值

1. 业务来源

2. 业务目标

2.1 查询数据

对应正确的实例，知道必要信息后，进行数据查询：

2.2 处理 userID 数据

将返回的 .csv 文件中的数据按列整理好，返回给运维人员即可。

3. 业务步骤

3.1 确定积分值条件

根据业务来源确定 积分值条件，以上图为例，条件为 57820002 > 0

3.2 确定积分所在的实例

根据积分 id 可在 CVS 数据库中查到内容项，根据字段 cluster 知道积分所在集群。

例如 id = 57636002 时，根据以下 SQL 语句可查询到内容项：
1 select * from define_nosdata_jgbc where id in (57636002);
查询结果如下：

可知 cluster = redis_jgbc。
在外网拉一个配置文件 ClusterDefine.json，该 json 文件中的格式如下所示：（熟悉后此步骤可略过）

可查询到与 “redis_jgbc” 对应的实例为 “matchsave-001-redis.service.jjsrv.local:9379” ，

对应的实例 id 为 “matchsave-001-redis”。
在 数据库云平台 中找到该实例，积分的校对与批处理（提工单）都是从该实例进入：

3.3 确定积分存储结构

（1）普通积分

在 mis 系统上可查找 除存盘域外 的积分的存储结构：

如上图所示，即可知道该积分 id 对应的 field 值 与 key 值，userID 是为了查询随便输入的。

（2）存盘积分

存盘域积分的数据结构可通过两种方法查询：

经验推测：

存盘域积分即为记录在 define_nosdata_jgbc 上的积分。

存盘域积分一般为 normal 类型，该类型的 key 值结构为 namespace + ':' + userID。

同样以上面 id = 57636002 的积分为例，该积分的 key 为 MS:D57636:[0-9]*[0-9]。

MS:D57636:[0-9]*[0-9] 中的 [0-9]*[0-9] 为 redis_glob 表达式，代表任意数字。

例如当 userID = 123456789 时，其 key 为 MS:D57636:123456789 。

大概推测出积分的 key 结构后，可通过下面的第 4 步进行验证正确性。
代码查询：

所有的积分最后都会通过 TKNOSService.exe 进行查询，其积分结构也会通过代码攒出来。

先通过 MySQL 中记录的数据查找该积分的 modeltype ，再根据代码中该 modeltype 的 GetKeyField() 查找积分的数据类型，如下图所示：

3.4 验证积分存储结构

这一步很重要，是提工单前的最后一步。

（1）数据查询

在前面 3.2 中提到的实例右侧点击 “数据操作” 即可进入查询页面，输入查询条件，点击查询。

若数据结构不正确，查询内容为空，若有查询结果，即可证明该积分 id 的数据结构是正确的。

（2）数值查改

有时候通过上面的【数据查询】能正确的找到数据，但是点 “查看” 的时候没有正确的 field 值，这种情况也是存在的，代表该用户没有该积分。

这时候需要通过【数值查改】功能测试修改功能是否正确：

3.5 提工单

得到必要信息后，在实例的右侧点击 “数据批处理” ，即可填写、提交工单。

3.6 数据处理

提交工单后，吕开心等同事会将查询到的数据以 .csv 文件的形式返回。

将该 .csv 文件中的数据进行适当整理，返回给运维人员即可：

# 通过 CLS 日志线上 debug 确定问题

1. 业务来源

业务方在使用积分的时候出现问题，如下图所示的 bug 描述：

2. 步骤

2.1 确定积分的修改方式

先确定业务方是怎样修改的积分，直接调用 EVT 的接口？通过 ESP 来修改？还是什么其他的接口？

在 MIS 上通过账单查看该积分的修改记录：

如上图所示，该积分最近的 3 次修改均是通过 ESP 修改的。

本节以 ESP 修改积分为例，说明怎样添加 CLS 日志，来线上 debug 确定问题。

2.2 查询 ESP 规则表

通过以下 SQL 语句查询 ESP 规则表，确定是由 ESP 修改，且确定 ESP 规则：

        
      
 select * from define_esprule_general deg where content like '%60133011%';

修改上述 content 中的内容来定位 ESP 规则。

可以得到该 ESP 的规则 content：（以上述 SQL 语句的执行效果为例）

        
      
{
  "sid": 10001440,
  "desc": "明星复式赛用户比赛胜利次数",
  "level": 0,
  "module": [
    {
      "type": "decision",
      "title": 1,
      "next": 0,
      "decisionitem": [
        {
          "next": 2,
          "condition": {
            "logic": "single",
            "oper": "in",
            "valuebase": "MPID",
            "value": [
              2006431,
              2006432,
              2006433,
              2006434,
              2006435,
              2006401,
              2006402
            ]
          },
          "seq": 1
        }
      ]
    },
    {
      "type": "decision",
      "title": 2,
      "next": 0,
      "decisionitem": [
        {
          "condition": {
            "logic": "single",
            "oper": "in",
            "value": [
              2
            ],
            "valuebase": "OEValue"
          },
          "next": 3,
          "seq": 1
        }
      ]
    },
    {
      "type": "grow_modify",
      "title": 3,
      "next": 0,
      "balance": "N_60133011",
      "eid": 60133011,
      "mpid": "MPID",
      "pid": "__PID__",
      "ts": "__TS__",
      "value": 1
    }
  ]
}

这里的规则同样可以通过【ESP可视化配置平台】中来查询，比 json 更直观，但是没有 json 具体。

以上面同样的 ESP 配置为例：

2.3 确定 ESP 规则是否合规

得到 ESP 规则后，校验该 json 格式是否合法、是否符合业务需求。

2.4 添加线上 CLS 日志

若单看 json 字段不能确认问题的话，就需要通过 CLS 线上日志来确定问题。¹

仿照着已存在的数据，改一条数据，将监控结束时间 endtime 适当往后调整一下，CLS 监控就开始执行了。

对几个关键字进行解释：

to_cluster 关键字中填写 cls_hebbroker_general：针对 hebbroker 集群添加的 cls 监控，一般来说，不管是 evt 还是 esp 的请求，都会先经过 hebbroker 进行分发，所以在这里加日志会比较全。
stake 关键字中填写 PushSourceAsync ：stake 中填写的信息均是来自代码中的定义，每种含义具体看代码就 ok 了。

以 PushSourceAsync 为例，在 hebbroker 项目中的代码如下：

2.5 通过 CLS 日志确定问题

通过堡垒机，在对应的 mysql 存储库上看日志确定问题：

注：该实例需要在堡垒机上开通权限：cls-001-mysql.service.jjsrv.local:4306

# 服务升级/重启流程

1. 基本介绍

业务目标：将某个/某几个服务（.exe）进行重启或升级
基本思路：
- 确定目标机器： BTO 获取集群 IP 地址, 确定 IP 地址是否有效
- 确定 IP 有效：CMA 通过 DB 层看 IP 地址是否都有效（是否都有流量）
- IP 分组：将要升级/重启的所有实例分为AB两组，例子见文件夹 .\\BTO-升级切换集群配置
- 流量切出：修改 TKService.ini 中的 [TKHEBBrokerService] ，把要升级/重启的实例的流量切到其它实例上。修改成功后，查看 CMA 监控，指标都为 0 即代表流量切出成功。
- 服务升级/重启：查看 CMA 监控，确保服务升级/重启成功。
- 流量切回：把前面修改的 TKService.ini 中的 [TKHEBBrokerService] 再改回去。修改成功后，查看 CMA 监控，确保切回成功。

2. 具体步骤

首先需要提一个工单，主要是需要里面的操作序列号，后续操作都需要该序列号才能继续。

工单内容和形式如下图所示：

剩余的就按照前面的基本思路来走就行。
下图所示，就是在重启 10.30.127.190 实例上的服务过程中，CMA 相关监控的变化情况。

3. 确认是否存在连接

【MIS】-【运维管理】-【BTO平台】-【BTO生产环境】-【远程工具】

在上述位置执行如下命令：

# EVT 中判断为新用户的区间

如下号段的 userid 会被判断为新用户，存储目标为 redis-004 。

# 客户端可修改的积分号段

方块大战：[ 50370005 , 50370050 ]
象棋：[ 50340000 , 50369999 ]
其它：[ 49800000 , 49899999 ]

[ 49251000 , 49251099 ]

2025年5月12日与唐成龙确认了Lobby可修改的号段范围：

[6000,6500] [6600,6900] [7200,7299] [20000,21000) [30000000,30109999] [50370005,50370050] [50340000,50369999] [49800000,49899999] [49251000,49251099]

# CMT 根据积分号段分发不同集群的对应关系

CMT会根据积分的号段，将目标积分的请求分发给对应的 EVT 集群，对应关系如下：（来自唐成龙）

[40000000,45009999] - 千炮集群
[45010000,49999999] U [50200000,50599999] – 休闲游戏集群
[50600000,52599999] – 用户标签集群
[52600000,54999999] – 捕鱼集群
[57000000,59999999] – 比赛存盘集群
[60000000,65009999] U [50000000,50199999] U [0, 39999999]– 通用集群

# 通过 ESP 落盘以供数数统计

落盘流程

ESP 通过 TKESPService.ini 中的 [Config]-DTCBillList 配置，读取要落盘的 sid 和对应的 billtype
ESP 通过 esp 配置接收到目标 sid 信息，将信息落盘到本地。文件路径如下所示：
DHL 采集，流转到 DTC，DTC 将账单落到 Kafka。
kafka 再落到 hive。
hive 后续流转到数数，数数提供统计方法。
【占位】

业务流程

1. 确定原子事件id

落盘的 sid 是有范围要求的，不同的 sid 会写到不用的本地文件中，对应关系如下表：

sid	文件名	DHL采集（待补充）
10000xxx	ESP_DATA_1_20250731_09.log	默认采集
10001xxx	ESP_DATA_2_20250731_09.log	默认采集
80000xxx	ESP_DATA_3_20250731_09.log	默认采集
其它	ESP_DATA_0_20250731_09.log	不操作

对应代码如下：

2. 新增 esp 配置

需要有 esp 配置来接收对应的原子事件，配置可参考10000316,10000904，配置如下：

        
      
{
  "desc": "赏金猎人活动目标、幸存成功、猎杀成功数据统计",
  "module": [
    {
      "starttime": "2025-07-30 00:00:00",
      "title": 1,
      "type": "filter_time",
      "next": 0
    }
  ],
  "sid": 10000904
}

3. 修改 esp.ini 配置

在 TKESPService.ini - [Config] - DTCBillList 中增加对应的 sid 和账单号。

配置示例如下，最新配置需参照线上。

        
[Config]
DTCBillList ="10000904:10000904,10000315:10000315,10000316:10000316,10000317:10000317,10000067:10000067,10000278:10000278,80000000:8541,80000001:8531,80000002:8501,80000003:8542,80000004:8543,10000307:8505,10000208:8508"

更新至除了回调之外的所有集群。

HIS 添加赛程回顾

# 参考²

工作, 业务相关

工作业务相关

本文由作者按照 CC BY 4.0 进行授权

# 确定原生事件是否可用

1. 原子事件与集群的对应

2. 业务步骤

# EVT 根据日志排除 bug

# 集群与 redis 集群的对应关系

# 查询满足某个条件的所有用户的积分值

1. 业务来源

2. 业务目标

2.1 查询数据

2.2 处理 userID 数据

3. 业务步骤

3.1 确定积分值条件

3.2 确定积分所在的实例

3.3 确定积分存储结构

（1）普通积分

（2）存盘积分

3.4 验证积分存储结构

（1）数据查询

（2）数值查改

3.5 提工单

3.6 数据处理

# 通过 CLS 日志线上 debug 确定问题

1. 业务来源

2. 步骤

2.1 确定积分的修改方式

2.2 查询 ESP 规则表

2.3 确定 ESP 规则是否合规

2.4 添加线上 CLS 日志

2.5 通过 CLS 日志确定问题

# 服务升级/重启流程

1. 基本介绍

2. 具体步骤

3. 确认是否存在连接

# EVT 中判断为新用户的区间

# 客户端可修改的积分号段

# CMT 根据积分号段分发不同集群的对应关系

# 通过 ESP 落盘以供数数统计

落盘流程

业务流程

1. 确定原子事件id

2. 新增 esp 配置

3. 修改 esp.ini 配置

HIS 添加赛程回顾

# 参考2

热门标签

# 参考²