架构二三事
1. 读写 Redis
两种结构方式，一个是星型，一个是链式，但是最根本的都有一个主(只写)，一个热备(HA用)，N 个只读从
- 星型
- 写主，会自动同步到热备 + N个从
- 优点
- 主从库都是各自独立，从库之间也是独立不影响的
- 主库同步到各个从库，中间复制的链路只有一层，此时延迟只和网络时延以及 cpu 压力有关
- 缺点
- 所有的数据同步都由主库执行，对主 Redis 的压力会比较大
- 链式
- 写主，会自动同步到热备 + 第一个从，接着由第一个从来同步给其余的从，链式方式，第一个同步给第二个，第二个同步给第三个
- 优点
- 可以无限扩展，主 Redis 的压力也会小
- 缺点
- 数据同步的链路很长，时延可能会很高
- 如果链路中有一个从 Redis 掉了，恢复很麻烦，需要让下一个结点连接到上一个结点
读写分离导致的最直接问题就是数据一致性，要采用独立分离，前提是可以容忍一定程度上的数据不一致
2. 云原生数仓
传统数仓大体分 ods → dw → dm → rpt 四层，外加一个 dim 层
云数仓的话一般会减少到3层
基于Starrocks或Doris来实现
① 前端埋点上报，数据同步到 ods层
② 业务库经数据同步到ods层
③ 最简单的可以直接在ods上添加视图
④ 再进一步的话，可以通过脚本的方式，定时执行sql，可以实现类似分层的效果，优点是比起下一种方式实现更方便，缺点是计算放在doris上，会导致cpu和内存使用率上升，可能会影响查询
⑤flink作业除了kafka2doris负责落数据，还需要将一些数据的关联也查询出来（这个地方的查询关联可能是从hbase维表查询关联），然后将一些表的关联放在flink中进行实现，最后把关联后的数据放入到doris中，这样可以降低doris的cpu和内存使用率，但是数据的关联实现逻辑会比较复杂