04stone37

文章目录一、方案背景1.1 考虑因素1.2 数据特点二、方案演进三、MySQL架构3.1 单库单表3.2 读写分离3.3 垂直拆分3.4 数据归档/冷热分离3.5 分库分表方案1：路由表方案2：哈希四、MySQL + NoSQL架构4.1 MySQL + ES4.2 MySQL + ES + HBase五、未来预期: NewSQL一、方案背景  订单系统是存在于各行各业的一个很基础、核心的业务系统。随着互联网的发展，订单系统的管理方案也在不断变化，订单数据规模的膨胀、用户对数据的重视，以及新的技术等都会

文章目录一、方案背景1.1考虑因素1.2 数据特点二、增量同步方案2.1 并发消费2.2 顺序消费2.3 1:N关联数据三、存量同步方案3.1 并发同步3.2 基于视图同步四、监控与补偿机制4.1 延迟监控4.2 补偿机制一、方案背景  当订单数据量规模足够大或查询统计足够复杂时，通常会采用MySQL + NoSQL的架构方案，这种方案需要将MySQL中数据同步到其它介质，比如HBase、ES，或者阿里云的TableStore等。订单数据的同步面临着诸多挑战，尤其是异构介质，下面会从”数据同步面临的挑战

文章目录一、方案背景二、技术方案2.1 全异步方案方式一：事务消息方式二：Binlog消息2.2 全同步方案方式一：AT模式方式二：TCC模式2.3 混合方案一、方案背景  订单系统是每个公司最核心的业务系统，订单逻辑执行过程中会和多个业务系统交互，如何保障订单系统和其它业务系统数据的一致性是订单系统的核心问题，数据的不一致性可能导致业务无法正常流转，甚至产生资损。二、技术方案2.1 全异步方案  适用场景： 资源充足、不需要实时得到反馈的场景；方式一：事务消息方式二：Binlog消息2

文章目录一、产品设计1.1 分页设计1.1 深度随机跳页1.2 小范围跳页1.3 滚动分页二、技术方案三、 DB规范一、产品设计1.1 分页设计1.1 深度随机跳页  产品设计不合理是导致深度分页查询的一个重要原因，比如下图所示的深度随机跳页设计方案，如果没有特殊原因，正常情况下应避免使用。一方面，随机跳页实际意义有多大有待考究；另一方面，随机性会加大后端的难度，如果随机跳页的页码很大，有可能导致查询超时，甚至异常，反而影响产品的稳定性以及用户体验。1.2 小范围跳页  小范围跳页涉及方案允许

订单号特性唯一性：每个订单号全局唯一代表一个订单；安全性：订单号不能透露订单量、运营规模等业务信息（数据安全性）；高性能：订单号的创建成本越低越好；扩展性：能够较好的支撑后续业务发展变大带来的分库分表、订单长度扩展等场景；业界一些方案方案1：数据库自增ID（不推荐）  基于数据库主键ID自增的特性生成订单号，不推荐此方案的原因有如下几点：不安全：订单号能够反映出系统的订单量，存在业务数据外露的风险；性能问题：需要数据库插入一条记录获取主键ID，性能受限于数据库，且存在单点；扩展性：

设计感悟架构是演化出来的，不是设计出来的。架构设计就是一个持续迭代改进的过程。没有完美的架构，只有平衡的架构。架构设计过程中，不要过于追求单点的完美，而是追求多点的平衡。...

ABA更新问题  ABA更新问题就是旧值覆盖新值问题，具体是指先后有两个不同的请求来更新同一个订单，请求1要将订单值更新为A，请求2要将订单值更新为B，由于网络超时等原因，最终请求2的更新结果被请求1覆盖/最新值被旧值覆盖的情况，如下图所示：原因分析  订单系统是电商系统中最重要的一个子系统，很多系统都需要更新订单的信息，比如支付系统、物流系统等。在高并发的情况下，在短时间内可能存在多个不同的请求同时更新同一个订单的情况，如果网络不稳定或者某时刻负载过高等情况，就可能导致订单的最新值被旧值覆盖的情况