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

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

你可能感兴趣的:(高并发,大数据量系统的数据结构优化思路)