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
