数据库【读写分离】
一、业务场景
一般在业务读多写少的场景,我们为了解决数据库IO瓶颈,可以考虑采用数据库读写分离,将写请求和读请求进行分开数据处理。
注意:主从不是主备。主从中的从服务器是要承担业务的,主备中备用服务器一般只做备份存在。
二、架构
一主多从的结构如下:
其中有个关键技术:主从复制。每次写入数据的时候,需要将主服务其数据复制到从服务器中,用以确保数据一致性。接下来以MySql为例:
- slaver连接上master,启动复制,则会自身创建一个IO线程去向master拉取binlog的更新信息。
- 把拉取的binlog信息写到自己服务器的一个relay log日志文件中。
- 从数据库服务器创建一个SQL线程,是为了将relay log的所有日志信息,进行SQL回写到自己的数据库中,这样就和主库的数据同步了。
- 当master有数据更新的时候,比如新插入一条update数据,master会将这些数据更新到binlog二进制文件中,同时,master会创建一个binlog dump线程,这个线程将更新了binlog信息发送到slaver的IO线程。需注意,该过程是异步,如果等slaver接受完成,很慢,会影响性能。
小结:用主从后,slaver还可以作为备份数据库来使用,如果master突然故障了,可以防止数据丢失。但是不能一味的加slaver,过多的slaver会导致过多的IO线程,从而导致master承压,从而导致master写入数据慢,可能会卡死。一般生产环境一主三从就行了,最多不超过5个slaver。如果还不满足条件,可以采用其他方案,比如多级缓存。
三、主从延时
主从同步是有延迟的,一般都在ms级别,如果到了s级,可能影响业务,看是否能接受。如在支付系统创建订单后,风控系统会进入查询做出相应的风空操作,如果查不到就可能终止本次交易。
【优化】
- 可以在这些立马需要查的业务,直接查询主数据库。让它直接查主数据库,但该方案不推荐,因为量大怕会拖垮主数据。
- 当slaver读取不到数据,我们回去再读主数据,这样就可以读取到了。但是有风险,量大也会拖垮主库。
- 可以分重要性业务和非重要业务,将很核心的几个业务读写主数据库,其他非核心,读写分离。
- 使用缓存,将新增的数据同事添加一份缓存,然后查缓存数据,这种建议新增的数据使用缓存较好。
- 使用消息队列中间件进行消息冗余,将新的主数据库内容,通过消息中间件MQ冗余一份当前数据,然后发到需要查询的系统。
小结:在消息体不大的情况下,推荐使用第5种优化方案,需要消息中间件。其次考虑使用缓存,因为更新操作,需要更新缓存,也需要解决一致性问题,故新增数据,就首选缓存优化方案。最后,推荐重要性和非重要性隔离方案。最好不要使用都查主库操作。
四、优雅的使用读写分离
4.1、程序代码嵌入
代码嵌入,指通过我们在代码中开发出数据库访问中间层,由这个数据库访问中间层去访问不同的数据源,以实现读写分离和数据源的管理。参考淘宝开源TDDL(Taobao Distributed Data Layer),直接集成到代码,它自己管理读写分离和数据库配置。
特点:1、实现简单,可根据业务进行定制化开发。
2、语言不同,就得开发不同语言版本的数据库访问层。
4.2、部署独立代理层
部署代理层是指,在我们的业务服务器和数据库直接引入数据访问代理层,并不用自己写代码。现在为代表的开源中间件有阿里的MyCat、360的Atlas、美团的DBProxy等。这些都是使用标准的MySql通信协议。
特点:1、不用自己编写多余代码,使用方便。
2、sql语句会跨两层网络,性能稍微低一点。
4.3、小结
在自己公司没有比较成熟的中间件团队的话就用代码封装的方案,虽然写代码麻烦点,但是可以把控;要是公司有成熟的中间件团队,就可以考虑代理层部署的方案,因为需要有个团队要研究和长期维护这个代理层,才能确保业务正常发展,现在我们公司大部分都用的代理层方案,是有个专业团队来维护。