墨墨导读:MySQL如何实现高性能?以下内容是结合其他技术同仁的总结和自我实践整理的20个开源数据库设计原则,分享至此,希望对大家有帮助。
开源数据库架构设计原则
01
技术选型
选择成熟的平台和技术,同时是最熟悉的,能做到极致的,用好不用坏,用熟不用生。目前业界的MySQL主流分支版本有Oracle官方版本的MySQL、Percona Server、MariaDB。
02
高可用选择
高可用解决方案探讨的本质上是低宕机时间解决方案,可以理解成高可用的反面是不可用,绝大部分情况下数据库宕机才会导致数据库不可用。随着技术发展,开源数据库方面很多高可用组件(主从复制、半同步、MGR、MHA、Galera Cluster),对应场景,只有适合的,没有万能的,需要理解每个高可用优缺点。
03
表设计
表设计方面目前一致坚持和提倡的原则:
04
优化原则
05
复制方式
MySQL复制方式提供异步方式、半同步方式、全局事务强一致性、binglog同步。需要不同业务系统间 或 两个数据库间进行同步。异步方式可以防止故障和效率问题的蔓延,扩大化;但强一致性会更复杂,并发、事务大小都有求限制。
06
分离原则
区分核心的业务,重要业务,渠道,内部业务的业务系统,对不同的系统设置不同的架构。为核心业务设置 最佳为分库,多活 专用高速公路,其他业务可以做读写分离,缓存。
07
扩展性
对于系统来说扩展性很重要,尽量做到水平扩展。避免过度依赖纵向扩展,同时具备纵向,横向扩展的能力,例如无状态应用应该多套负载均衡多活部署,数据库分库架构。
08
读写分离
09
分库分表
10
归档原则
历史数据定期进行归档 或则 移到其他大数据平台。能让轻量级数据库更多缓存有用的数据。 在MySQL分区表里 注意要避免分区锁,只能写读的场景。
11
连接池的要求
长链接,自动重链,延时和异常记录, 弹性链接,检测满,异常告警,进阶要求 是记录所有访问情况,可以扩展出很多能力。 应用和数据库连接池设置,数据库允许的连接数设置,常见问题。 A )应用的数据库连接池设置偏小,一旦数据库相应慢(新上线应用,缺少索引 等)则应。 用排队严重,甚至雪崩,而遗憾的是数据库能力还远为用尽。 B )不具备失效及时发现和重新链接数据库能力。 C )隔离级别设置:RR 和 RC下不同的表现。
12
应用解耦
通过应用访问数据库而不是直接访问,重要业务不能依赖低保障级别的系统,应用层重要业务和普通业务解耦,关键业务要独立。
13
组件失效免疫能力
单一应用,单一硬件,甚至单一基础设施,单一站点容灾,业务影响,故障恢复能力,要季度级别进行演练。
14
关键词组件减负
特别是数据库访问,数据库成本最高,扩展性最难,可用性保障最难,恢复难度和时间最大。 减负:能不用就不用,使用最简单,成本最低的语句,避免大事务,慎用两阶段事务。
15
灰度数据库
减少发布时变更数据库对全局的影响,只有应用程序灰度是不够的,还要有专门的灰度数据库。在分库、读写分离架构下,一套含数据库的完整应用架构,变的很自然。 所为灰度环境就是生产环境,生产数据,所影响的也是生产环境,只是范围比测试环境更广,更真实。其实就是小范围的生产环境。类似于游戏内测。
16
高仿真架构体系
建立高仿真架构体系
17
容灾保障
高可用是运维核心要求,容灾是最后屏障 例如 双活比单活好,MGR比复制架构好,重要系统要做好高可用,容灾建设。
18
多中心建设
冗余是基础,多中心建设是为了提升容灾能力和扩展能力,并保障业务。
19
应用和数据库是一个整体
应用和运维人员一起,解决应用解耦,数据库解耦,追账补数,业务监控,应用路由,故障切换等。可用性,效率,故障恢复等方面都要一起参与。
20
性能提升
开源数据库使用应该合理且有效的结合周边的其他类型数据库,做到性能最大化。比如:Redis、MongoDB、ES、ClickHouse等。
总结 1. 最适合的架构是结合软件特性和业务场景,又能取得成本收益平衡; 2. 大数据情况下可以是利用读写分离、分库分表,但要选择合适的; 3. 不适合分库的应该考虑竭尽所能把核心库做小,然后通过垂直扩展来扩容; 4. 用尽各种技术, 高可用 和 容灾手段保证其可用。 墨天轮原文链接:https://www.modb.pro/db/25251