微服务架构＜2＞

在电商项目中，我们针对一些核心业务，比较复杂的业务需要做一些设计以及优化的过程

首先我们针对于订单的模块拆分了2个子模块

1.order-curr实时下单业务 
2.order-his 做一些历史的订单归档

我们的订单业务 
>商品添加至购物车
>购物车结算--> 订单确认页
>填写信息 提交订单--》订单支付页

购物车结算页

填写信息  提交订单

支付  这就是我们整个订单的详情，这种业务在高并发情况下该怎么做优化呢
1.>  我们在做设计的时候，针对于订单表做分表处理 我们可以考虑数据量做分表操作
在整个下单业务会出现什么过程呢
1> 重复下单 基于一个商品下2个单， 这种就会容易产生重复下单的问题  基于这种问题，会加一些Js的控制
比如说 点击一次结算，将按钮置灰

但是，在前端控制的时候他安全性不高，比如说黑客可以直接跳过前端发送请求到后端，这种情况下前端控制的就会安全性不高
怎么防止重复下单

用户F5刷新进入页面的时候  先生成这个id 保存在页面中， 当提交订单的时候，订单号随着业务数据一起传输到后端进行传输
这样的话 即便点击多次提交订单，每一次提交的订单号都是一样的 我在后端根据这个订单号就可以判断有没有下单

也就是我后端提供这2个接口就可以了 
前端传了这个订单id 我们怎么来判断这个id 有没有下过单  insert的时候就会报错
或者我拿这个订单我去db 中去查询一下
=================>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
不查数据库有什么方法来判断这个订单是否重复  布隆过滤器，我可以基于布隆过滤器来判断这个orderId有没有下过单
布隆过滤器可以借助于redis分布式缓存来做

还有下单的时候会查询库存，如果超卖的时候该怎么办 ABA 问题
我们可以增加个版本号来控制
我们可以增加一个版本号来判断  我们增加一个vision 字段  来做版本控制

对于分库分表的处理 能不分就不分，因为随着数据库的分库分表，会有很多问题的要考虑
我们此时要考虑分库分表
1> 提高我的数据存储性能，我数据量过大 我单表存不下
2> 也要考虑我服务器查询承载的情况 ，比如说数据在一个库中的化，查询慢，很多查询集中在一个库中此时压力会变大
--------------------------->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
分库分表的一方面是提高数据的承载量
另一方面是提高他的查询性能 这也是我们要设计分库分表要考虑的东西'=

提高查询性能 我们可以考虑读写分离的方案

读写分离,原本我的数据部署在一个库中 
我做读写分离 首先需要 针对于每一个数据库搭建一个从数据库,从数据库基于mysql的binlog 的主从同步机制去做数据的同步

服务器将select的请求路由到slave上,将insert请求路由到master上， 这样就形成了一个读写分离的方案
我原本数据库要承载很多数据的请求，包括 write和read
现在做了读写分离，主库只负责写入，这部分占比是比较低的
对于读多写少的场景，读写分离式很合适的，另外读请求分配到从库中， 从库也可以做水平扩展
有更多的从库就可以进一步分读数据的请求了

在高并发场景下 我们主库都会搭建一个从库 目的就是为了体现读写分离的 思想

读写分离可以解决数据读取压力大的问题 ，但是他不能解决单表数据量大的问题
我们还需要进行分库分表处理  我们该怎么落库一个分库分表的项目
1> 我需要对我的数据进行一个预估,预估我数据量有多大，也就是说我要拆分多少个表，根据业务量来预估我们要拆分多少个表   我们要对数据的预估，以及数据的增量进行一个预估
我们根据当前实际情况预估32个表

确定好规模之后 我们的指定一个策略， 我们到底怎么分库分表
有很多方案去选择，既要考虑数据分布的均匀 也要考虑很多场景
最简单的方式 就是基于orderId进行取模  比如说1放在第一个表中，这就是最简单的分片操作
--------------------------------->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
分片键该怎么去选择，选择区分度比较高的数据orderId(唯一独立)  如果分片键仅仅是orderId这个字段的化，
呢么此时根据memberId是没有办法确定那个分片的
我们基于memberId来查询的时候 就只能全路由分片

所以我们要考虑分片键的化，还得依托于我们的需求
如果未来有memberId的化， 在生成分片键的时候，我们可以将用户id和orderId综合来考虑

这样不管是用orderId 还是memberId 都可以查到那在那个表中了
我再进行取模的时候  orderId的后2位置就是memberid 的后2位
这样就可以兼容 基于订单id和用户Id来查我也能确定用户再那个分片

主键生成策略 弊端就是只能支持2个字段，未来如果加上其他字段 比如说商户 就不能够支持了

orderId +memberId 这种只能够兼容2个字段 这种方式  如果有多个字段 我们这种方案就不适合了
我们选择了 订单id+userid这种分片键之后  接下来我们要实现分片算法
我们为了兼容订单Id 和用户id 2中方式
我的数据插入数据库是怎么插入到每个表的， 我查询的时候就该怎么去查询