问一个数据双写与性能优化的问题

[piecezzz]

背景:

项目的数据库是一主一从。但是从库不能给应用使用，是数据库 team 备份容灾用的。这一点挺奇怪的，也不能申请多的从库。所以应用只能连接一个主库。

解决方法:

为了减轻数据库的压力，我们将数据库的所有业务表都冗余到了 ES （ ES 是集群），哪怕是走主键查询，也走 ES 。我最开始不建议这样子做，但是因为前面的背景，我也没有什么好的 idea

为了解决写的问题。我们用了 2 套解决方案：

1. 代码双写
在应用代码里面进行双写，一个事务内：先写 db -> 后写 es(包括 flush)。flush 是为了让其他端能及时读取到，虽然这样做比较消耗性能。目前以我们的体量跑起来没什么问题

2. flink CDC
读取数据库的 binlog ，然后 flink CDC 及时同步到 ES （包含所有业务表）。这个方案解决的核心问题是我们有连表查询的需求，在 ES 里面做了 2 张业务大宽表。附带方便：
数据初始化数据到 ES ；
方便手动刷数据库数据后就自动同步到 ES ；
如果代码里面对双写有遗漏，也可以及时弥补数据的不一致

注意我们是 2 套方案都用了

我的疑惑：
1. 双写采用了 2 套方案。flush 会立刻往 ES 所有节点写，这样做是不是非常不合适？而且已经有代码双写(方案 1)的前提下，flink CDC 除了解决宽表的问题，其他的单表同步是不是多余的，浪费性能？
2. 在目前的条件下（数据库只能一主供应用使用），这样的解决方案是否是最优的？或者说有其他更好的方案么？

PS: 我们的项目是 ToB 的，整体没有电商流量那么大

[Thiece]

flush 操作会给 ES 集群带来压力，尤其是在高并发的情况下。
可以引入一个缓存层（如 Redis ），缓存部分高频查询的结果。

[sujin190]

不 join 单表读有啥压力。。别过度优化啊，复杂查询大多也能接受延时，还是异步同步好吧

[zhuisui]

ES 集群维护起来比数据库方便是吧。。。
流量不大数据量不大，提高主库的硬件性能不行吗，搞这么复杂的方案

[chendy]

都有功夫整 es 集群了，分点配置给数据库就完事了
没啥极端情况的话，2b 业务，mysql 机器配置拉高点都能硬抗

[akira]

ES 集群 的资源给 mysql ，直接 mysql 一把梭 搞定。。。搞那么复杂干嘛，就是为了好看么

[jack778]

@akira 增加就业岗位和工作量, 码农造福码农

[hsymlg]

所有业务表都弄上去，主键查询也走 ES 。。还 flush ，盲猜数据量和并发不高，请使用 mysql ，怕 mysql 出现性能问题就不要写联表查询，让代码去做。

[onceMore]

一主多从+灾备，从库的延迟几乎可以忽略，根据业务属性，去决定读主库、从库，这样业务架构简单，对业务代码，担心的话加点钱配置高一点。

如果是联表跑数据、数据报表场景，也专门搞个从库。

简单就是快。

[zhuisui]

@onceMore 主从的延迟还是存在的，看数据量和业务吧，还是见到过几次因为业务逻辑不合理而出现数据一致性问题的情况。

[onceMore]

@zhuisui #9 对，在主库出现大的事务或者大量插入可能会出现延迟