球球各位大佬出出方案, 谢谢! Orz!
1
laozhoubuluo 2022-04-01 18:26:55 +08:00
没看懂是增量数据应用新规则还是全量数据应用新规则。
我感觉可以在节点维护一个数据结构用来表示当前版本的规则数据,考虑到规则数据需要提前运算可能需要下发 Redis 库 IP 之类的信息。 改完之后相当于下发时间和切换时间解耦了,下发时间可以任意(比如 10 分钟后生效),节点到点切换规则就可以。 当然这么玩需要下面的机器配置 NTP 服务器保证时钟基本一致,否则还得清理脏数据。 |
2
hannibalm 2022-04-01 18:52:32 +08:00
直接说说这个需求的背景
|
3
wukuai 2022-04-01 19:15:20 +08:00
2PC
|
4
MoYi123 2022-04-01 19:57:51 +08:00
可以在用户查询的时候实时计算吗?
|
5
THESDZ 2022-04-01 21:38:51 +08:00
1.同时是指同一个事物?或者说用户的感知是这一百万条数据是一个事务更新的?
2.实时性是指?1.百万数据同步到数据库的时间间隔?,2.用户从发起更新开始~阅读到最新的数据间隔 1.假设说是真.实时,那就要拓展机器,队列+消费者,数据要强 - 1.1.给我狠狠地堆性能 2.假设是假实时,那就包装起来,模拟各种数据库落盘的分层操作和记录日志做合并 - 2.1.最近看到的一个 SLM-DB ,只看其实现原理即可 - 2.2.参考 es 近实时策略 - 2.3.考虑垂直切分数据+alias - - 2.3.1.用户直接查询 alias,alias 映射作为动态的 - - 2.3.2.可以减少缓存压力 |
6
slomo OP @laozhoubuluo 会保证计算时间内没有规则的新增和更改. 规则本身是确定的, 只是不同批量的数据需要对应不同规则去计算
|
7
slomo OP @hannibalm 百万会员在年终进行等级重算. 不同等级对应不同重算规则. 需要更新成长值积分(另一个服务). 因为等级关联打折等情况, 所以如果算的慢, 就会造成经济损失
|
9
slomo OP @THESDZ
1. 不需求同一事物, 之前数据量比较小, 所以用单机器 ForkJoinPool 去跑的. 2. 实时性主要指用户以及其他服务可见的实时性, 写库不需要高实时性, 这也是为什么想先放在 redis 中 |
10
laozhoubuluo 2022-04-02 13:49:05 +08:00
@slomo 如果是这样的需求的话,不如考虑给用户等级查询这块改一下,存储的时候用户等级伴随有效期,读取的时候判断是否有效,无效的话按照新规则重算。
举例:用户 A 的数据在去年 12.31 23:59:59 失效,01.01 00:00:00 时用户 A 请求用户等级接口的时候,服务判断 2021 年数据为脏数据之后自动调用规则判断 2021 年全年消费数据生成新规则并写入,有效期到今年年底。另外安排一个服务在低峰期对未调用接口的用户主动进行重算,避免有些直接取数据库的地方有误差(例如数仓)。 |
11
slomo OP @laozhoubuluo 嗯嗯, 惰性更新这块是肯定要做的~
请问另一个请求在低峰期去请求接口这块, 大佬有什么好的实现思路吗? flink 时间窗口统计接口请求, 低于某值发送消息触发这样可行吗? 但是感觉复杂度又高了不少 |
12
laozhoubuluo 2022-04-02 14:05:48 +08:00
@slomo 您说的会更智能,不过一年跑一两次的话,看下流量曲线就能知道大致的低峰期了,完了在大致的低峰期内按照合适的频率给接口打请求或者塞到消息队列里完事。比如一般的业务 2-5 点低峰,那就 2:00-3:00 完成按最后登录或者什么其他指标排序的前 1/6 ,3:00 - 5:00 完成 2/3 ,5:00-6:00 完成最后 1/6 。
|
13
slomo OP @laozhoubuluo 嗯嗯, 其实还是因为我说的只是极端情况. 目前等级的有效期有自然年, 相对天, 月, 年这些. 主要用到的是自然年. 所以等级重算这个任务每天都要去跑, 只是在年终的时候, 数据量会很大~
感谢大佬提供思路~ |
14
hannibalm 2022-04-02 20:18:05 +08:00 via Android
感觉没必要集中一起刷新等级。就在客户主表上打标记,下次客户发起任何交易自动先刷新等级
|