关系型数据库层面的高并发优化

 云原生常用技术：https://landscape.cncf.io/?fullscreen=yes

mysql性能问题的原因

• 数据库表设计不合理
• 表数据量过大
• sql查询太复杂
• sql查询字段没有加索引
• 数据库服务器性能过低

表数据过大的解决方案

怎么算表数据过大？

阿里开发手册：单表数据行数超过500W，或单表数据容量超过2G

数据库表拆分

分库分表：垂直分库分表、水平分库分表

冷热数据分离：根据数据访问频次分开存储，一般按照时间来划分冷热数据，比如微信朋友圈，电商网站订单信息，交易信息

数据库分库分表

水平拆分

水平分库：根据年进行数据分库

水平分表：根据编号或者月份对同一个表的数据进行分表存储

垂直拆分

垂直分库：电商库分为商品库，订单库，用户库，交易库

垂直分表：订单表，订单明细表

分库分表策略

取模算法

缺点：如果新添加一张表，需要对所有数据重新计算，进行数据迁移

一致性hash算法

如果新增表或删除表，可以缩小数据迁移的范围

范围分片

根据编号范围进行分表，比如0<id<100W，100W<id<200W...

区域分片

不同区域分片存储，比如最近的健康码数据分省份存储

全局唯一ID

1. 创建全局唯一表，保存全局唯一ID
2. 通过UUID生成ID：缺点是ID不连续，字符串类型，占用存储空间较大
3. Redis的原生递增
4. Twitter-Snowflake雪花算法：64位长度的Long类型的数字ID

分库分表中间件

客户端：Application集成分库分表组件

服务端：访问Mycat独立中间件去操作数据库，中间件实现了数据库的协议，类似于直接操作数据库

分库分表实践

实际分库分表考虑

1、功能：注册、登录、查询、修改等

2、使用范围

• 用户端

        如果根据用户id查询用户信息占比大，则可根据用户id进行分片

• 运营端

        可以使用搜索引擎-es

        建立映射表，分片键与非分片键之间建立映射关系

分库分表可能的问题

• 数据迁移
• 模型改造

模型改造三阶段：

• 新老库双写（以老库为准）

        定时任务来数据校对，补平差异

        定时任务去迁移老库数据到新库

• 历史库已经导完，数据校验也没问题

        保持双写，事务以新库为准

        定时校验数据

• 新模型已稳定运行，取消双写，所有数据只需要保存到新的模型，老模型不需要再写数据

跨库查询

• 字段冗余：不同库有关联关系的数据字段
• 绑定表：有关联的表放在同一库中
• 业务系统层面组装
• 全局表

分页、排序

业务端做聚合，存储在nosql中

分库分表解决方案

• MyCat：服务端代理
• Sharding-Sphere(5.x)：Sharding-JDBC --> 客户端，        Sharding-Proxy --> 服务端