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

感觉你需要的是一个网关，对流量进行拦截，限流，限频。从而服务降级，来保证数据库不崩溃。
当你数据库慢的时候，前端不断的重试，刷新，加重数据库的卡死。

要看业务规模 和 架构。
redis 确实做过库存扣件最后落 db 。
infoq 写过快手等电商系统， 对于直播超大秒杀百万 qps 直接走 redis 。
你们有这个业务场景，和维护 redis 库存的技术能力吗？

感觉和数据库容灾没啥关系，和你们项目的脏 SQL 关系更大。
即使做了容灾，运行这些 SQL 还是会出现问题。

如果核心业务也涉及复杂的查询，那怎么堆配置都是没用的，根本问题解决不了，还是得老老实实优化查询。

1 、缓存肯定要加的，你说的 sql 复杂，估计查询也慢
2 、阿里云应该直接支持配置从库啊，不用自己搞
3 、sql 优化吧

@blackeeper #21 是这样的，越是不可用的时候，用户越会不断重试刷新，因为解决这类问题，不是一套工具或者一个方案能解决的。相关的熔断限流都有，现在想解决的是数据库挂了的问题；
@mangodai #22 有这个能力就不会问这个问题了 哈哈哈
@0x663 #23 根本问题就在大 SQL ，但是远水解不了近渴，得先想数据库挂了如何处理的问题
@bellx #24 核心业务少，SQL 优化耗费的时间和精力都能接受
@ala2008 #25 好像 sqlserver 不支持从库

@seedhk 那 sqlserver 够垃圾的，迁移到 pg 或 mysql 吧哈哈

SQL 太复杂，一查几百行，表数据量又太大 导致大量的慢 sql ，是不是瓶颈在于查询而不是新增和修改？这样的话我感觉用 Redis 替代 Mysql 查询不合适，原因是即使前台没有显式的调用这些复杂 sql ，在相关业务进行新增和修改时也调用复杂 sql 同步到 Redis ；如果说不调用 sql 直接将数据存到 Redis ，那能不能确定由复杂 sql 组成的数据可以通过简单的 Redis 命令重新组成，我感觉挺困难的；还有数据量太多的话假设 Redis 挂掉，AOF 恢复是需要时间的，在这段时间内服务不可用；综上，我感觉 Redis 不合适。 解决办法根据描述我感觉：1.针对那些很复杂、数据量又特别多导致慢 sql 的表，将这数据同步到 ES 的一个索引中，组成一个大宽表，所有有关的复杂查询全走 ES 2.每次新增或修改时使用消息队列同步到 ES ，不能直接同步（或者现在有一些同步组件可以用） 3.如果有很多复杂查询但彼此不相关就需要多个索引了 4. 如果条件允许的话针对这些复杂的查询单独拆出来组成查询服务 5.分库分表还是有必要搞的，不过根据我的经验用过 Sharding 和 Mycat ，复杂的 sql 还是歇菜 6. 优化还得继续，慢 sql 报警不知道有没有 7.业务上能不能限制一下查询条件，比如起始时间什么的 8.有没有数据冷热分离的可能性？ 9.据说 PG 很强，但我没有用过，得试试

定期捞慢 sql ，然后拆分优化或者跳过。既然你们钱不够，那就靠人力解决。
不是很赞同直接引入 redis ，可以分析出慢的地方，sql 优化成本很高的时候，针对这一部分做一些缓存。sql 虽然几百行，但是多花一些时间，逐步分析，测试到位问题不大。

@ala2008 这个真迁不了 哈哈哈 工作量太大了
@heiya #28 谢谢大佬的回复，原先的方案确实不合适，我已经否了，现在在考虑新的方案，主要是解决如何避免数据库挂了，以及如果数据库挂了如何保证业务可用的问题，针对您说的这几点我概括一下，您看我说的对不对

1. 如果是将大数据量的表同步到 ES ，那如何解决关联查询的问题？ 还是说将关联查询的结果直接同步到 ES ？

2.阿里云的 rds sqserver 好像不支持从库，只能通过 DTS 同步。

3.索引是肯定有的，但是数据量太大，优化的工作量也不小，目前同步在做；

4.将核心业务迁出来，包括代码和数据库，避免影响到核心业务。

5. 分库分表暂时没有

6. 慢 SQL ，大 SQL 的报警都有，但是优化难度很大

7. 业务上的限制条件也是有的

8. 问了阿里云客服，除了买高可用和 DTS ，没有其他方案，自己做了部分冷数据的备份，但也仅仅是备份

9. 更换数据库成本太高了，而且领导层不一定支持，我综合一下方案往上提

@z1829909 人力更不够(笑哭)，而且 SQL 强关联业务，又不可能扔了业务需求完全不做来改 SQL 。

@seedhk 或者组里安排一个人专职优化 sql ，或者轮岗，每人定期来一波精神折磨 233

复杂 sql 本身就是业务设计时候应该避免的

可以试试让 AI 优化 SQL ，说不定有奇效

@z1829909 #32 哈哈哈 大家一起痛苦
@opengps 是这样的，但是因为没有审核 review 机制，真的很难推行，更何况是几年的老代码
@Atoony SQL 中包含了很多业务逻辑，AI 的效果也不好

都已经确定是数据库的问题了，那就从数据库优化着手。
1,买几个虚拟机，整多个只读实例，卡死一个，不影响全局
2,优化数据库服务器的性能，换 SSD ，32G 内存太小，建议加大内存，配置数据库 cache 大小
3,排查优化慢 sql ，增加相关索引
4,把旧的数据归档，很多 sql 每次几亿的全表扫描是很消耗资源的。

@seedhk 查询从 es 走，落库后组织数据写 es

@blackeeper #36 只能走阿里云的 DTS 做只读
@baibaibaibai 您的意思是，落库后的数据，根据复杂 SQL 查询出来后的结果再写入到 ES 吗？

@seedhk

1.这个需要你们去分析。可以将关联查询出来的数据结果集作为一个大宽表同步到 ES 的索引中，这个大宽表可能有很多字段；也可以在后端业务逻辑中将需要的条件提前准备好了直接传递给 ES （如果被 jion 的表查询很快的话）；还有一种是 ES 的索引间关联查询也可以。
2.有一个数据同步中间件 datax ，可以将 Mysql 的表数据同步到各种其他数据库。
4.我感觉是哪个工作量相对小就将哪一个迁出，目标就是避免影响到核心业务。
10.还有一种查询是各种聚合查询，针对于各种大数据量下的 count 语句，那 ClickHouse 特别合适，不过使用他是有条件的，只有写入和查询的话可以使用。
11.前端页面上点击查询一时半会返回不了就不要再发送相同请求了

整体上我感觉就是现在的 Mysql 满足不了复杂的查询业务，把整个服务拖垮了，并发量其实并不高。最要紧的是把 1 和 4 搞定，其他的 6,11 同步做。不过，这么一搞就把技术复杂度提上去了，新增了 ES 和消息。

@heiya #39 谢谢回复

1 、ES 关联查询不如数据库那么方便，如果将查询后的数据汇总到 ES ，又涉及到数据变动更新的问题，不管怎么做都很复杂
2. 我是 RDS SQLSERVER WEB 版，目前来看只支持 DTS ，其他都不支持。