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组件，对外部系统的实时调用添加熔断保护，防止某个系统故障的影响扩大到整个分布式系统中。
监控和告警
通过配置日志平台的错误日志报警、调用链的服务分析告警，再加上公司各中间件和基础组件的监控告警功能，让我们能够能够第一时间发现系统异常
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
