我们怎么决定,是采用读写分离的架构,还是采用sharding的架构?
总体来讲,DBA团队prefer sharding机制,而不是严重依赖于replication based read/write split;
对于现有的读写分离应用,要进行梳理;
新的读写分离的方案,要么经过架构评审委员会评审,要么经过开发总监和DBA总监确认;
读写分离的好处:
- 在相对简单的付出下(只需要做读写分离,相对于sharding 而言,开发简单很多),可以解决系统的scalability的问题;
- 对于写的高可用相对要求低,对读的高可用要求/读的qps 要求非常高(比如用户登陆,移动的配置类型信息)可以很容易的实现系统扩展新问题
- 很容易实现读库的99.999%的高可用
- 可以某种程度上,降低大查询/报表类应用,对在线系统的压力;(比如wms/tms之类,不过不鼓励这种做法)
读写分离的坏处:
- 应用开发需要清楚知道,什么时候读主库,什么时候读从库;如果主从延迟,导致异常单,应该作为bug处理;
- 对于应用开发,某种程度上,对开发的要求更高:不能写大job(从库一定delay),不能写大SQL(从库也很容易delay);
- 需要处理从库delay 的exception;何时回源主库;大部分是不能/不应该回源的;集中回源很容易压死主库;
- 容易让dev abuse系统;不做过多优化;
-
降低主库的写容量,当TPS超过6k,从库就会延迟逐步增加,而主库的TPS其实可以去到1.5w甚至2w
总体判断的guideline:
- 读写比率,必须在10:1 以上(建议20:1以上),才有可能考虑读写分离;不然原则上,不同意读写分离,不管如何还是要求避免延迟,比如:防止延迟的时候突发failover,那要么抛弃延迟的数据(如果硬件故障,大事务产生的大量binlog来不及传送,必然丢数据),要么等延迟过去拉长了故障恢复时间;
- 读写分离的数据库,必须在读库前面,有LVS,来虚拟化读库的IP;原则上,10:1的读写分离,读库的压力会大大于写库;也需要多个数据库服务器来支撑;也需要LVS来掩盖和解决后端数据库服务器的维护问题(基本上读库可以逻辑上always online)
- 读写分离的应用,程序要能够handle延迟的情况,必须能够容忍读库delay 3~5s; 如果不能容忍,请不要连接从库;
- 读写分离的主库,在系统设计支撑的容量,3年内,写库应该不需要sharding 拆分;不然,就是白白引入先读写分离,然后在主库sharding的复杂度;
- 读写分离的应用,不能因为读写分离了,就可以滥用系统;在主库的大事务,和在从库的大SQL,都会导致slave 的较大规模的delay;
- 读写分离的应用,对于一个transaction里面的或者有强一致性依赖的,不能一下子去从库,一下子去主库;一个transaction 里面的信息,必须都是consistent的;属于ms级别的;主从复制必然有这个delay的;
- 原则上,读写分离的数据库,尽量不要让主库过于大(2个TB);
- 读写分离,不应该作为报表的标准解决方案;报表类型的应用(后端系统,比如vis, tps, ods, tms, wms等较多)原则上,应该考虑通过hadoop 来解决;MySQL天然不适合报表类型的应用;在线系统和报表系统,天然应该分离;
-
读写分离应用: 对于cache侧有可能回源的应用, 可以考虑选择读写分离, 所有的读回源必须到 LVS vip
过去的例子,读写分离之后,由于应用设计的问题,带来的问题:
- 订单/Coupon的问题;一个交易里面,一会儿读从库,一会儿读主库;在部分有几秒或者十几秒delay的场景下,发生异常;
- 订单例子
业务场景:用户订单支付成功第三方支付平台回调流程中,pay域调用订单接口更新订单支付状态,主库更新成功从库同步存在延迟,pay域进一步调用审单接口进行审核(其中审核数据包含支付状态的判断),读取从库订单数据支付状态仍处于未支付状态,此时订单审单流程异常。- 原始订单数据<order_sn,pay_status> = <15032483118418,0> (pay_status 0:未支付,1:支付成功)
- 订单支付成功后,订单主库数据<15032483118418,1> 从库数据<15032483118418,0>
- 审单时读取从库订单数据<15032483118418,0>,判断订单支付状态时出现异常
- coupon例子
业务场景:coupon.api在大促前为了降低主库压力,在变更余额时判断余额金额的查询由主库迁到从库,并做了数据库主从一致性判断,当数据库主从不一致时,不能变更会员账户余额。但是订单退款其他操作是没有判断数据库主从一致性的,所以导致当退款操作时,数据库主从不同步时其他金额退款成功,礼品卡唯品卡账户退款是失败的。这段时间数据库主从一致性不稳定,导致出现异常单。解决方案:
在订单退款的时候,礼品卡唯品卡账户从主库来获取。
- 订单例子
常见的slave delay的原因:
- 大job,一个update 几万条几十万条记录的;
- 一个update好多条记录(100+),而且是全表扫描类型的,没有合适的where 条件可以走索引的;因为我们是基于row的复制,每一条都要跑一边这个全表扫描/低效的索引扫描;这个问题在slave会放大;
- 表没有主键,导致从库复制每一条记录的DML都会做全表扫描
- slave 大SQL,比如频繁的大量的复杂join,耗尽磁盘的io能力或者耗光CPU资源;slave delay;
- DBA维护操作,比如大表的online DDL,或者dba 晚上的归档的job; --应该禁止;我们online ddl要求控制速度;归档也要控制速度和并发;麻烦的是两个同时kick off的时候;
- 网络或者系统问题;比如跨机房网络,同机房网络不稳定,系统不稳定(机器故障);
- MySQL bug;
- 频繁对Text字段的表的读写,会把IO资源耗光,哪怕是flash卡
- 一些框架,查询也会发起事务,如set autocommit=0,又不关闭连接,到发布需要做ddl变更时,就会导致表锁延迟
相关推荐
"数据库读写分离解决方案--DG实施方案" 本文将详细介绍 Oracle Data Guard 实施方案,旨在实现数据库读写分离解决方案。该方案通过 DG 实现主库与备库同步,主库作为业务应用库,备库作为查询库,应用根据不同需求...
### MySQL读写分离及主从同步延时解决方案 ...通过采用读写分离策略,并结合有效的延时解决方案,可以在保障数据一致性的同时,显著提升数据库服务的整体性能。希望本文能为正在准备相关面试的读者提供有价值的参考。
### Spring 解决读写分离方案详解 #### 一、背景介绍 在现代应用程序开发中,尤其是在高并发场景下,数据库的读写操作往往是系统瓶颈之一。对于大多数应用场景来说,“读多写少”的特点非常显著,这意味着数据库的...
在这种背景下,采用读写分离等技术手段成为优化数据库性能的有效途径之一。本方案旨在通过MyCAT这一中间件实现读写分离,以达到提高数据库响应速度、提升用户体验的目的。 #### 二、MyCAT 读写分离模式介绍 MyCAT...
- 运维人员:学习如何维护和监控采用读写分离架构的系统,确保其正常运行。 #### 二、MySQL引擎浅谈 在深入讨论MyCAT读写分离之前,有必要简要介绍MySQL的两种主流存储引擎——InnoDB和MyISAM。这两种引擎各有优...
例如,Shareplex等工具就广泛应用于Oracle的读写分离方案中,它们能够提供更强大的复制功能,满足企业级应用的需求。 - 优点:提供了更高级的功能和服务支持。 - 缺点:成本较高,可能需要额外的技术培训和支持。 ...
此外,对于事务一致性有严格要求的场景,可能需要避免使用读写分离,或者采用其他方案如两阶段提交来保证数据的一致性。 通过这个demo,开发者可以快速了解和实践Sharding-JDBC的读写分离功能,为自己的项目带来更...
为了应对这一挑战,一种常见的解决方案是采用MySQL读写分离技术。通过将数据的读取与写入操作分布在不同的服务器上执行,可以显著提高数据库系统的整体性能,并增强其稳定性。 本文将详细介绍如何通过配置两台MySQL...
对于读多写少的应用场景,采用数据库集群的方式进行读写分离是一种常见的优化手段。本篇文档将详细探讨如何利用Spring框架实现数据库的读写分离,并结合MySQL的主从复制机制,确保系统的稳定运行和高效响应。 ### ...
SpringMVC、德鲁伊(Druid)、MyBatis 和 MySQL 是四个在Java Web开发中常用的组件,它们各自承担着不同的职责,而将它们结合在一起则可以构建出一个高效、可扩展的数据库读写分离解决方案。 SpringMVC是Spring框架...
Mycat是一款开源的数据库中间件,它的主要作用是提供数据库的分库分表功能以及读写分离机制。Mycat的读写分离机制可以帮助我们提高数据库的读写性能,解决单点数据库的压力问题。Mycat支持MySQL的主从复制状态进行...
在IT行业中,数据库主从复制和读写分离是优化系统性能和提高数据可用性的重要策略。下面我们将详细探讨这些概念,以及如何在SpringBoot+MyBatis框架下实现它们。 首先,**数据库主从复制**是一种数据库高可用性的...
因此,采用读写分离技术来提高数据库的处理能力成为了许多企业和开发者的选择。本文将详细介绍如何利用MyCat构建MySQL的高可用读写分离集群,并探讨其实现原理及应用场景。 #### 二、MyCat简介 MyCat是一款开源的...
### 基于MyCat的MySQL高可用读写分离集群实战知识点详解 #### 一、MyCat简介 MyCat作为一款开源的数据库中间件,它能够实现对后端多个MySQL数据库进行分片处理,为前端应用提供统一的访问接口。在实际应用中,...
为了提高数据库系统的性能和可用性,一种常用的方法就是采用“读写分离”的策略。读写分离能够有效地分散数据库的负载,提升系统的整体响应速度。本文将详细介绍MySQL读写分离的概念、实现方式以及基于Amoeba的配置...
- **主服务器故障**:模拟主服务器故障情况,停止主服务器的MySQL服务,验证读写分离功能是否正常工作。 ##### 3.2 方案二:自动主从切换 - **配置**:与方案一相似,但两个节点都配置为`writeHost`。 - `...
### MyCAT读写分离模式智能优化方案 #### 一、概述 随着业务量的增长和技术的发展,数据处理的需求日益增加,特别是在高并发环境下,单一数据库往往难以满足读写需求。为了解决这一问题,MyCAT引入了一种智能优化...
为了解决MySQL数据库的压力,企业通常会采用读写分离的技术。读写分离的核心思想是将数据库的读操作和写操作分开,主数据库(Master)负责处理所有的写操作,如CREATE、INSERT、UPDATE和DELETE,而从数据库(Slave)...
在本次实战中,应用程序client基于c3p0连接后端的database proxy。database proxy负责管理client实际访问database的路由策略,采用开源框架amoeba。database集群采用mysql的master-slave的replication方案。