关于数据库容灾缓存方案的咨询

54 天前
 seedhk

数据库版本

阿里云 RDS SQLSERVER

需求

需求是因为老项目的长 SQL 实在是过于多了,几百行的 SQL 一找一个准,去优化 SQL 工作量非常大。

导致生产环境数据库很不稳定,经常因为 SQL 引起数据库不可用导致被客户投诉罚钱,问了阿里云他们推荐高可用集群,但是阿里云高可用对于小企业来说实在是太贵了。迁移下云又需要比较专业的 DBA 来运维数据库,小企业老板估计也不会同意。

做了什么

已经做了这几步:

  1. 使用了 DTS ,同步主库的数据到从库,基本上实现了读写分离;

  2. 拆分了核心业务,但是核心业务仍然有访问数据库的需求,因此万一数据库不可用时,如何保证核心业务的正常运行,成为了一个大问题;

想做什么:

领导提了一个想法:能否通过在中间加一层缓存层的方式,比如 Redis ,核心业务的增删改查先走 Redis 。一段时间后落库,这样即使数据库挂了,只要能撑住 10 分钟数据库就能恢复。

其他方案:

将数据库和接口都进行拆分,拆成多服务,需要对应数据的,走接口进行查询调用

不知道有没有其他更好的方案,求大佬们指教,谢谢~

5079 次点击
所在节点    程序员
103 条回复
isSamle
53 天前
目前的方案是读从 redis ,低频写的话正常写,高频写的话用消息队列慢慢消费
fengpan567
53 天前
扯犊子呢,缓存到 redis 碰到大 key 怎么办,为啥不优化 sql
huBane
53 天前
Redis 确实可行,老项目 sql 优化已经十分困难,我做过一个老项目优化就是中间做了一层 redis ,低频操作正常写库,高频查的走 redis 系统性能提升非常明显。
mark2025
53 天前
@wxw752 我公司是进销存场景,提升大概 30% 左右吧
datoujiejie221
53 天前
我们用的 mysql ,开始也有这个问题,说一下我们的方案
1 写了个监听 binlog 的服务,数据发生变化刷新 redis 。
2 写了个脚本统计慢查询日志,针对频繁出现的 sql 进行优化,用了一个开源的工具 archery 去做可视化分析和 sql 优化。
3 统计类的查询放到 doris 去做,效果提升明显,并且大部分 sql 都不用改。
1 和 3 都用了 flink-cdc 的方案去做数据同步。
ala2008
53 天前
@huBane 我们项目也是,加了缓存,起飞。因为查的数据访问频次很高和重复
netnr
53 天前
OP 但凡搜一下也不会说 好像不支持从库
感觉搞个从库是目前最优方案了
wxw752
53 天前
@mark2025 #84 肯定不能你百分之多少我百分之多少,然后 op 以此作为依据是否采用,这不成了小马过河了嘛。

在这里几十层楼都是集思广益,提供给 op 思路,让 op 去逐个尝试。
spritecn
53 天前
阿里的集群,好像不贵..2*4 双节点版和 4*8 机器差不多一个价,并且现在送代理..并且读写分离完后,CPU 点用比之前还低,别问我怎么知道,还有上读写分离还是要看看代码怎么写,有些 save 马上就查的业务代码可能得改改
spritecn
53 天前
@spritecn 忘了说了我是 mysql
lambdaq
53 天前
读写分离为啥还会卡啊?前面推荐 clickhouse 的只能解决 olap 导致卡的问题,也就是只读的 sql 。

如果你又读又写,还锁表导致的卡,业务还复杂的一批,那没救了。混吃等死吧。谁碰谁倒霉
dd102
53 天前
@seedhk 阿里云 顶配 16C 64G 为啥配置这么低?阿里云没有解决方案嘛
BadAngel
53 天前
阿里云没有分布式数据库中间件么?
华为云 DDM 直接把数据库导进去,自动分库分表,搞定
BadAngel
53 天前
@BadAngel 哦,SQLServer ,当我没说
ZiLong
53 天前
我有一个疑问,升级 sql 配置的钱出不起,能有钱上 OLAP ,印象中 OLAP 比关系型的更贵的多,而且 OLAP 基本底层架构基本都是分布式的,运维也非常复杂。
我的想法还是把耗时的,拖垮数据库的 sql 结果查询出来,可以放在一张预存结果表或者 redis ,尽量不要让查询打到数据库,然后慢慢梳理优化 sql 、表结构、表数据,感觉这才是最经济,见效最快的。
laminux29
53 天前
思路错了。

SQL 有 bug 属于重大缺陷,应该立即下成本去修复或重写,而不是去找什么 HA 方案。不然最后一堆脏数据写到库里,系统没办法运行了。

微软这类大公司,都有过这种黑历史时期。就像 Intel 之前自家晶圆厂存在工艺问题,不好好修复,而是选择强行冲,最后搞成这个鬼样子。虽然 15 代 Ultra 倒吸牙膏,但选择台积电,至少方向掰回来了。另外就是暴雪,早期暴雪,宁愿拖延跳票,也不愿意把不成熟的游戏放出来,所以暴雪早期口碑一直很好。
seedhk
53 天前
@mark2025 #74 是的,ES 的方案不太适合我目前的业务场景,IDC 没有 DBA 也没法做,加钱? 难啊 哈哈哈
@v2orz #75 目前可能考虑这个方案,在看优缺点
@dengtongcai #76 双刃剑把算是,又好吃也有坏处,配置基本上拉满了,SQL 也在一直优化中
@Meld #77 谢谢,昨天咨询了一个大数据的前同事,也说 doris 比较适合
@zhoujinjing09 #78 我是 mssql ,AnalyticDB 是 mysql 的,不适用 谢谢
seedhk
53 天前
@datoujiejie221 #85 这个思路也是不错的,谢谢您提的想法。我去看看我们的数据库是否能实现这个
@netnr #87 我去问了阿里云的客服,我们是 web 版本,而且是基础版,要从库要升级到集群版,中间还夹了个 HA 版
@spritecn #89 我这边看到一年要 2 30W ,也不算低了,没办法是小公司,属于是既要又要还要了
@lambdaq #91 目前基本上的大 SQL 和都迁移到 DTS 同步的从库去了,但还是担心主库会挂,所以想找个方案
@dd102 #92 问了就说升级到高版本,花更多的钱
@ZiLong #95 是的,就是您说的这个思路
@laminux29 #96 谢谢您的建议,SQL 优化一直有在做,但是工作量太大了,远水解不了近渴
ttkanni
53 天前
@seedhk
按照 OP 的描述,最优的方案就是从库+Redis ,读写分离,从库承担读压力,Redis 做读缓存(视业务情况)。
如果是单纯保障 RDS 稳定,可以考虑把 SQL 限流打开,免费版也能用个基础的,开高级版能针对 SQL 限流。一个月好像就百来块,针对 SQL 限流能缓解慢 SQL 堆集耗尽 RDS 资源的问题,但业务那边的沟通得做好。

领导提的方案有很大的场景缺陷,延迟落库并不会显著环节数据库的压力,同时延迟落库存在数据差异,万一缓存穿透,业务直接读库,数据不一致完蛋。
npe
53 天前
短期增加配置、长期优化 SQL 和业务逻辑,以及考虑使用 OLAP 数据库来处理复杂查询,如 ClickHouse 或 Doris 。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/1098113

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX