11. 连接池的要求
长链接,自动重链,延时和异常记录, 弹性链接,检测满,异常告警,进阶要求
是记录所有访问情况,可以扩展出很多能力。
应用和数据库连接池设置,数据库允许的连接数设置,常见问题。
A )应用的数据库连接池设置偏小,一旦数据库相应慢(新上线应用,缺少索引 等)则应。
用排队严重,甚至雪崩,而遗憾的是数据库能力还远为用尽。
B )不具备失效及时发现和重新链接数据库能力。
C )隔离级别设置:RR 和 RC下不同的表现。
12. 应用解耦
通过应用访问数据库而不是直接访问,重要业务不能依赖低保障级别的系统,应用层重要业务和普通业务解耦,关键业务要独立。
13. 组件失效免疫能力
单一应用,单一硬件,甚至单一基础设施,单一站点容灾,业务影响,故障恢复能力,要季度级别进行演练。
14. 关键词组件减负
特别是数据库访问,数据库成本最高,扩展性最难,可用性保障最难,恢复难度和时间最大。
减负:能不用就不用,使用最简单,成本最低的语句,避免大事务,慎用两阶段事务。
15. 灰度数据库
减少发布时变更数据库对全局的影响,只有应用程序灰度是不够的,还要有专门的灰度数据库。在分库、读写分离架构下,一套含数据库的完整应用架构,变的很自然。
所为灰度环境就是生产环境,生产数据,所影响的也是生产环境,只是范围比测试环境更广,更真实。其实就是小范围的生产环境。类似于游戏内测。
16. 高仿真架构体系
建立高仿真架构体系
- 数据库,操作系统升级:应用是否适应,性能会变好, 还是变坏
- 应用上线发布,系统变更(列如换平台),提前判断业务影响和性能瓶颈
- 应对突发交易量,例如双十一,性能极限在哪里,瓶颈在哪里。
17. 容灾保障
高可用是运维核心要求,容灾是最后屏障
例如 双活比单活好,MGR比复制架构好,重要系统要做好高可用,容灾建设。
18. 多中心建设
冗余是基础,多中心建设是为了提升容灾能力和扩展能力,并保障业务。
19. 应用和数据库是一个整体
应用和运维人员一起,解决应用解耦,数据库解耦,追账补数,业务监控,应用路由,故障切换等。可用性,效率,故障恢复等方面都要一起参与。
20. 性能提升
开源数据库使用应该合理且有效的结合周边的其他类型数据库,做到性能最大化。比如:Redis、MongoDB、ES、ClickHouse等。
总结
1. 最适合的架构是结合软件特性和业务场景,又能取得成本收益平衡;
2. 大数据情况下可以是利用读写分离、分库分表,但要选择合适的;
3. 不适合分库的应该考虑竭尽所能把核心库做小,然后通过垂直扩展来扩容;
4. 用尽各种技术, 高可用 和 容灾手段保证其可用。
以上就是MySQL20个高性能架构设计原则(值得收藏)的详细内容,更多关于MySQL 架构设计的资料请关注其它相关文章!
更多Mysql内容来自木庄网络博客
标签:Mysql
相关阅读 >>
关于mysql explain中key_len的计算方法讲解
更多相关阅读请进入《mysql》频道 >>

数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。