一. dbproxy(BMI)的主要功能
app -> bns/bgw -> dbproxy(bmi) -> mysql db
app一个请求到mysql db端,大致是这样一个流程,都会经过我们的中间层dbproxy(也叫BMI)
我们的中间层有3个**主要的功能: **
1. SQL转发,读写分离
2. 自带到DB的连接池,从而极大的提升了php这种短连接应用的性能.
3. 后端MYSQL DB对应用是透明的,这样我们增减从库,主从切换,都不需要RD的任何改动
读写分离策略:
1. 事务内读写(包括纯读取)都走主库,事务外写入也走主库.
2. 同一个客户端会话发出的写操作结束后,在特定的时间间隔(默认200ms)内发出的事务外读取也走主库.(就是为了优化解决有些业务写后要求立刻读取到的情况,但必须是同一个客户端会话的请求才可以)
3. 其他事务外读取,一般走从库,而且就近读取,读取同地域的从库
4. 可以设置某个用户只走主库或者只走从库,注意:如果用户设置的为只走从库,业务要保证所有SQL都为读取操作,如果有写入,也会发送到从库端,导致read_only报错.
但是一些语言,框架自带的特性,或者默认行为会导致我们的中间层的这些功能不能正常工作,这里汇总一下,业务方需要引起注意.
二. PHP使用HHVM的注意事项
如果使用HHVM的话,请注释掉默认配置中的:WaitTimeout = 10000
mysql1.png
WaitTimeout = 10000 (单位ms)的默认配置,会导致应用端执行如下的动作:
set session wait_timeout=10;
因为这个动作,会导致数据库中间层到DB端的连接不能复用,只能不断的重建到DB端的连接,这样不仅增加了应用响应时间(增加了连接耗时,增加了连接超时的风险),而且在应用端流量突增的情况下,存在连接打满,连接被拒的风险。
因为数据库中间层和DB端都是有空闲超时设置的,所以APP端不需要进行这样的设置,也只有这样才能保证数据库中间层重用到DB端的连接,避免这里的情况出现.
所以建议应用端去除这样的动作,去掉默认配置中的:WaitTimeout = 10000.
很多产品线去掉这个默认配置后,因为中间层可以复用到DB端的连接,都解决了连接打满的报错,也不同程度的提升了应用的响应速度.
三. Python+MySQLdb的注意事项(重要)
MySQLdb模块的connections.py中自动执行了一个:
self.autocommit(False)
这样连接时就执行了一个:
set session autocommit=0;
也就是说默认会开启事务.如果没有意识到这一点,就会带来一些问题:
1.业务持续不断的写入,但没有显式提交事务,因为行锁,会阻塞其它会话对这些数据行的写入;
最后业务正常退出,没有显式提交事务,mysql默认会rollback这些事务,业务会很诧异,日志显式写成功了呀,但最终写却丢失了.
2.上面提到了: 经过我们的中间层后,事务内读写(包括纯读取)都走主库,这样读取也会走主库,如果业务是以python为主要开发语言的,会导致所有的读取都走主库,这无疑加大了主库的负载,也导致不能通过添加从库的方式来负载更多的读取。
！！！！ 线上不少的python脚本，纯读取操作,对延迟不敏感,可以走从库,但因为这个特性,走了主库,而且业务没有意识到开启了事务,在连接断开前,也不会提交事务,*经常导致DB端的长事务报警。Warn:****之前小站备用播放服务端报出过这种问题，DBA发出报警, RD排查是python MySQLdb库的问题
所以,建议使用Python+MySQLdb连接时,在connect语句后加上一句conn.autocommit(True),恢复自动提交特性,需要事务的地方显式的开启事务就可以了。
不然就需要 ：
cursor.execute(sql) 之后：
conn.commit()
四. go语言连接mysql的注意事项
mysql2.png
go语言中连接mysql时,会检查发送的sql语句的长度是否超过了DB端的max_allowed_packet设置.需要检查DB端这个设置是什么,它会不断的发送select @@max_allowed_packet请求,给DB端带来了一定的负担.
因为我们DB端这个设置都是统一的,也不会改变的,所以不必高频重复的执行select @@max_allowed_packet这个SQL.
建议不再执行127行的调用,直接将maxap设置为DB层的设置(我们都是设置67108864 就是64MB),就可以了(或者可以联系接口DBA确认业务使用的数据库集群的这个设置是什么).
3961
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
