sharding-jdbc 分库分表
SpringBoot+Mybatis-Plus整合Sharding-JDBC5.1.1实现分库分表
mybatis plus整合sharding-jdbc在基于spring boot的项目中的单库分表应用
springboot+mybatisplus,再加入shardingjdbc分表玩法
Sharding-Jdbc集成mybatis-plus实现分库分表解决方案
Sharding-JDBC教程:Spring Boot整合Sharding-JDBC实现读写分离
Spring Boot 中分库分表 sharding-jdbc
分库分表方案
分表方案
MySQL分表篇:该如何将月增上亿条数据的单表处理方案优雅落地
分库分表路由策略
结合业务特性,选取用户标识作为分片键,通过计算用户标识的哈希值再取模来得到用户订单数据的库表编号.
假设共有n个库,每个库有m张表,
则库表编号的计算方式为:
- 库序号:Hash(userId) / m % n
- 表序号:Hash(userId) % m
分库分表后怎么做 MySQL 到 ES 的数据同步
上面说到为了便于管理后台的查询,我们将订单数据冗余存储在Elasticsearch中,那么,如何在MySQL的订单数据变更后,同步到ES中呢?
这里要考虑的是数据同步的时效性和一致性、对业务代码侵入小、不影响服务本身的性能等。
MQ方案
ES更新服务作为消费者,接收订单变更MQ消息后对ES进行更新
Binlog方案
ES更新服务借助canal等开源项目,把自己伪装成MySQL的从节点,接收Binlog并解析得到实时的数据变更信息,然后根据这个变更信息去更新ES。
其中BinLog方案比较通用,但实现起来也较为复杂,我们最终选用的是MQ方案。
因为ES数据只在管理后台使用,对数据可靠性和同步实时性的要求不是特别高。
考虑到宕机和消息丢失等极端情况,在后台增加了按某些条件手动同步ES数据的功能来进行补偿。
分布式事务问题
电商的交易流程中,分布式事务是一个经典问题,比如:
用户支付成功后,需要通知发货系统给用户发货。
用户确认收货后,需要通知积分系统给用户发放购物奖励的积分。
我们是如何保证微服务架构下数据的一致性呢?
不同业务场景对数据一致性的要求不同,业界的主流方案中,用于解决强一致性的有两阶段提交(2PC)、三阶段提交(3PC),解决最终一致性的有TCC、本地消息、事务消息和最大努力通知等。
这里不对上述方案进行详细的描述,介绍一下我们正在使用的本地消息表方案:在本地事务中将要执行的异步操作记录在消息表中,如果执行失败,可以通过定时任务来补偿。
下图以订单完成后通知积分系统赠送积分为例。
系统安全和稳定性
网络隔离
只有极少数第三方接口可通过外网访问,且都会验证签名,内部系统交互使用内网域名和RPC接口。
并发锁
任何订单更新操作之前,会通过数据库行级锁加以限制,防止出现并发更新。
幂等性
所有接口均具备幂等性,不用担心对方网络超时重试所造成的影响。
熔断
使用Hystrix组件,对外部系统的实时调用添加熔断保护,防止某个系统故障的影响扩大到整个分布式系统中。
监控和告警
通过配置日志平台的错误日志报警、调用链的服务分析告警,再加上公司各中间件和基础组件的监控告警功能,让我们能够能够第一时间发现系统异常