kyhoon

再让用户手动的跳转订单页，就是为了防止主从同步延迟导致的可能不一致的问题。* ①下单成功，不立刻返回订单页，而是先展示 一个"无意义"的下单成功，* 数据量大，查询慢 才 分表， 并发大才 分库。读写分离， 一主多从, 如何解决同步延迟问题?* 这属于业务侧 迁就 技术侧 解决方案.* ③硬编码 主库读取。* ②同个事务中操作。

①先删缓存，再更新数据库. 这里存在的问题就是当请求A进来删除缓存后，还没来得及更新数据库， 请求B此时进来发现没有缓存，就去数据库读取了还未更新的数据更新进缓存，* ②先更新数据库，再删缓存. 这里也存在一个问题场景，就是请求A进来，发现缓存没有，去读取了数据库，还买来得及更新缓存，请求B更新数据库，并删除了缓存，* ①先更新缓存，再更新数据库. 如果先更新缓存成功了，但是更新数据库失败了，那么数据库将出现脏数据，否掉。*此时请求A再将之前读的旧数据更新给缓存，此时缓存里面依旧是旧数据.

大白话解释，应该是正常情况下，对同个请求只会发一次，但是如果不小心同个请求发了两次甚至多次，不会影响正常业务，比如下订单，点确认订单的时候， 不小心重复点击，导致重复提交订单，但是此时应该只会生成一个订单，如果因为不小心发送多次导致重复下了订单就叫这个接口不幂等。官方解释是，请求一次和请求多次效果相同。* 如果保证接口幂等，