互联网业务大部分都是 读多写少，为了提升数据库集群的吞吐性能，我们通常会采用 主从架构、读写分离
部署一个主库实例，客户端请求所有写操作全部写到主库，然后借助 MySQL 自带的 主从同步 功能，做一些简单配置，可以近乎实时的将主库的数据同步给 多个从库实例，主从延迟非常小，一般不超过 1 毫秒。
客户端请求的所有读操作全部打到 从库，借助多实例集群提升读请求的整体处理能力。
这个方案看似天衣无缝，但实际有个 副作用
主从同步虽然近乎实时，但还是有个 时间差 ，主库数据刚更新完，但数据还没来得及同步到从库，后续读请求直接访问了从库，看到的还是旧数据，影响用户体验。
任何事情都不是完美的，从主同步也是一样，没有完美的解决方案，我们要找到其中的平衡取舍点。
我们以电商为例，看看如何从 产品层面 来化解这个问题
示例如下：
在下单确认页面，点击购买按钮，进入了支付页面
输入支付宝支付密码，进入支付成功页面，页面有查看订单详情的入口。
点击 查看交易详情 ，才跳到真正的 订单详情页，可以查看订单的支付状态（订单数据取自从库）
看懂了吗？
我们在支付成功后，并没有立即跳到 订单详情页，而是增加了一个 无关紧要的 中间页（支付成功页），一是告诉你支付的结果是成功的，钱没丢，不要担心；另外也可以增加一些推荐商品，引流提升网站的GMV。最重要的，增加了一个缓冲期，为 订单的主从库数据同步 争取了更多的时间。
可谓一举多得，其他互联网业务也是类似道理。
是不是又学了一招 😊😊😊
还没有评论，来说两句吧...