高并发，大数据量系统的数据结构优化思路

1.互联网浪潮面临的问题

大数据量

设计及测试阶段，由于数据量小，很难发现薄弱之处。

高并发

系统投产初期，由于负荷低，可以满足常规的使用要求，不易发现问题。

随着业务量逐渐增大，各种营销活动的开展。数据性能问题成为系统运行的主要瓶颈。

2.常规的解决手段

2.1数据库连接池

• 选择高性能的数据库连接池组件，如druid，hikari

2.2读写分离

• 考虑主库与只读库同步的问题。

2.3数据库设计

2.3.1分库分表

• 单库单表与分库分表存在性能差异。
• 分区与分库分表存在性能差异，且分区灵活性不够。

水平拆分

拆分原则：3年内，oracle单表达2000w，mysql单表达500万

• 常见方案：按照uid拼接的一定规则进行拆分，查询时确保单库单表。
• 基础数据同步问题：定时从主库拉取刷新+消息通知。
• 服务端框架Mycat，sharding-proxy
• 客户端框架sharding-jdbc
• 热点账户问题：账户切分

垂直拆分

拆分原则：按业务

• 目的：减少单表字段数。
• 按业务拆分：如订单数据，按照商户，用户，支付通道进行拆分。
• 各库保存全局（流程）的唯一流水号，以方便追溯。

2.3.2适度的反范式设计

• 在保证数据完整性，唯一性的前提下，可适度的增加冗余字段，避免联表查询。一般情况下，如果join的表数据超过1万条，就会出现性能问题。

2.3.3尽量不用sequence做主键

• 不便于系统的迁移和数据恢复
• 多一次与数据库的交互

2.4优化查询

• 尽量减少对数据库的访问次数

第1级：订单数据和支付流水数据；这两块数据对实时性和精确性要求很高，所以不添加任何缓存，读写操作将直接操作数据库。

第2级：用户相关数据；这些数据和用户相关，具有读多写少的特征，所以可使用redis进行缓存。

第3级：支付配置信息；这些数据和用户无关，具有数据量小，频繁读，几乎不修改的特征，所以我们使用本地内存进行缓存。

• 尽量减少对表的访问行数
• 尽量最小化结果集
• 查询业务数据必须使用索引
• 关键SQL，需分析执行计划

3.微服务面临的问题

3.1数据一致性问题

• 2PC
• 3PC
• TCC
• 消息确保
• saga

推荐消息确保和saga

3.2连接数过多问题

• 在交易量较小，应用拆分颗粒度较粗的阶段，可通过制度手段管理应用配置数据库连接数过大的问题。
• 微服务及容器化后，子系统拆分的越来越多，数据库连接数会成为珍贵资源，可采用中心化的数据库服务中间件（如Mycat）做为解决方案。

4.附录

数据类型对比

Mysql	Oracle	Java	说明
BIGINT	NUMBER	java.lang.Long
CHAR	CHAR	java.lang.String	定长
DECIMAL	NUMBER	java.math.BigDecimal	金额（分）
VARCHAR	VARCHAR2	java.lang.String
FLOAT	FLOAT	java.lang.Float
INT	NUMBER	java.lang.Integer
TIMESTAMP	TIMESTAMP	java.sql.Timestamp

参考资料：https://blog.csdn.net/chenpeng19910926/article/details/51789934