开源数据库架构设计原则01.技术选择选择成熟的平台和技术，同时做到最熟悉，能做到极致，好与坏，使用熟而不生。目前业界主流的MySQL版本有Oracle官方版MySQL、PerconaServer、MariaDB。02.高可用性选择高可用性解决方案本质上是一种低停机时间的解决方案。可以这样理解，高可用的反面就是不可用。大多数情况下，只有当数据库宕机时，数据库才会不可用。随着技术的发展，开源数据库中有很多高可用组件（主从复制、半同步、MGR、MHA、GaleraCluster），只有适合相应场景的，没有通用的一。有必要了解每种高可用性的优点和缺点。03.表设计目前在表设计中一贯坚持和提倡的原则：所有表都需要对单表数据量添加注释，建议将单表数据量控制在3000万以内.数据表使用规范拆分大字段和访问频率低的字段，冷热数据分离。单表字段数控制在20以内索引规范1.单表索引数不超过5个2.单个索引字段数不超过5个3.INNODB主键推荐使用自增列。不能修改主键，不能使用字符串作为主键。如果没有指定主键，INNODB将使用唯一的非空值索引。4.如果是复合索引，区分最大的把字段放在索引前面5.避免冗余或重复索引：合理创建联合索引（避免冗余）6.不要在低基数的列上建索引，比如'gender'7.不对索引列字符集utf8mb4（部分字符、表情符号）进行数学运算和函数运算04.优化原则05.复制方式MySQL复制方式提供异步方式、半同步方式、全局事务强一致性、和binglog同步。不同业务系统之间或两个数据库之间需要同步。异步方式可以防止故障和效率问题的蔓延和扩大；但是强一致性会比较复杂，并且有并发量和事务大小的限制。06、分离原则区分核心业务、重要业务、渠道、内部业务业务系统，对不同的系统设置不同的架构。对于核心业务，最好设置分库，多活专用高速，其他业务可以读写分离，缓存。07.可扩展性对系统来说很重要，尽量做到横向扩展。避免过度依赖纵向扩展，具备纵向和横向扩展的能力。例如，无状态应用应该部署多套负载均衡多活、数据库分库的架构。08.读写分离读多写少的场景（10%写，90%读）复制有延迟，业务对延迟不敏感：1.通过应用代码配置读写分离，2.通过中间代理路由只读数据库&3.业务和数据库是一个单元09.分库分表当表的数据记录数超过3000万条时，再好的索引也是不能再提高数据查询的速度。这时候就需要将表拆分成更多的小表来提高性能，增加灵活性，避免数据库崩溃进行操作。中间价的引入要考虑性能成本和聚合需求。分库的原则是尽量分库在app的上层，也就是流量。多少分合适：可用性和性能满足TPS。路由：写配置文件或者插入表或者zookeeper。10.归档原则历史数据定期归档或迁移至其他大数据平台。允许轻量级数据库缓存更多有用的数据。在MySQL分区表中，注意避免分区锁和只写只读的场景。11、连接池要求长链接，自动重链接，延迟异常记录，灵活链接，全检测，异常告警。进阶需求是记录所有的访问情况，可以扩展很多能力。应用程序和数据库连接池设置，数据库允许连接数设置，常见问题。a)应用的数据库连接池设置太小，一旦数据库响应慢（新上线应用，缺少索引等）。严重排队，甚至出现雪崩，可惜数据库容量还远远没有用完。B)没有及时发现故障并重新链接数据库的能力。c)隔离级别设置：RR和RC下的不同性能。12、应用程序解耦数据库通过应用程序访问，而不是直接访问。重要的服务不能依赖低保障级别的系统。应用层重要服务与普通服务解耦，关键服务必须独立。13、组件故障免疫单应用、单硬件，甚至单基础设施、单站点容灾、业务影响、故障恢复能力，必须按季度演练。14.关键字组件减负，尤其是数据库访问，数据库成本最高，扩展性最难，可用性保证最难，恢复最困难耗时。减轻负担：能用就用，用最简单成本最低的语句，避免大事务，慎用两阶段事务。15.灰度数据库减少了发布时整体更改数据库的影响。仅有应用的灰度是不够的，还需要专门的灰度数据库。在分库和读写分离的架构下，一个包含数据库的完整应用架构自然而然。所谓灰度环境就是生产环境，生产数据也会影响生产环境，只是范围比测试环境更广更真实。其实就是一个小规模的生产环境。类似于游戏测试版。16、高仿真架构系统建立高仿真架构系统数据库，升级操作系统：应用是否合适，性能会更好，反之会更差。应用上线，系统变更（如更换平台），提前判断业务影响和性能瓶颈。对于突如其来的交易量，比如双十一，性能的限制和瓶颈在哪里？17、容灾保障高可用是运维的核心诉求，容灾是最后一道屏障。比如active-active优于single-active，MGR优于replication架构。重要系统必须具备高可用性和灾难恢复能力。18、冗余是多中心建设的基础。多中心建设是为了提高容灾和扩展能力，保证业务。19、应用和数据库是一个整体。应用和运维人员共同解决应用解耦、数据库解耦、账号恢复、业务监控、应用路由、故障转移等问题，可用性、效率、故障恢复等都需要一起参与。20.性能提升开源数据库的使用应与周边其他类型的数据库合理有效地结合，以达到性能最大化。例如：Redis、MongoDB、ES、ClickHouse等。总结1、最适合的架构是结合软件特性和业务场景，做到成本效益的平衡；2、大数据的情况下，可以使用读写分离，分库分表，但一定要选对；3.不适合分库要考虑尽量把核心库做小，再通过纵向扩容扩容；4、采用各种技术、高可用和容灾的方法保证其可用性。
