在 进入mq之前，就进行限流，采用令牌桶方法，这样的话后续流量到达mq就会显著减少
分库分表：分库字段以用户字段或者订单号，用户的话可能会出现数据倾斜问题，有些用户订单很多，出现超大订单问题按订单号分的话可能导致不同的订单分散在各个库里，这样的话通过订单号做唯一索引进行防重就有问题了
分布式数据存储问题可以分为：数据分片、数据复制、数据一致性binlog
1、statement 是记录sql语句到blinlog sql复杂度高时，解析需要大量精力，那么bug也就可能更多
2、row 存放实体的变更前后的状态 不需要解析sql
3、mixed，动态选择statement还是row模式写入binlog时，binlog会使用ack机制进行穿行消费，每消费一条，确认一条（那么使用串行的话，消费效率就低，单线程无法水平扩展，架构有缺陷）采用并行的方式。借用MQ进行拆分，在binlog处仍然串行消费，但是至少ack数据，ack数据后发送到MQ里面的某个Topic即可，因为制作ack并转发至MQ，不涉及业务逻辑，所以性能消费非常小，大概只有几毫秒或者纳秒 发后仍需要串行消费，比如上面提到的同一条微博的多次修改就需要串行消费，而多条微博间的修改则可以并行消费，它不存在并发问题。
判断需要串行消费的数据，比如同一条微博数据，都会发送到 MQ 中间件的串行通道内。在同步模块进行同步时，MQ 中间件里的串行通道的数据均会串行执行，而多个串行通道间则可以并发执行。借助 MQ 中间件的此特性，既解决了乱序问题又保证了吞吐量。很多开源的 MQ 实现都具备此小节介绍的功能，如 Kafka 提供的 Partition 功能
多张表中使用分布式锁，比如订单和商品表均存储了订单号，当订单信息或者商品信息发生变更时候，因为对订单号进行加锁没在数据同步时候两张表归属同一订单号的数据实际为串行执行。此方式所以可以解决redis和数据库不一致问题，但是多张表加锁又降低了吞吐量
采用反查的方法进行全量覆盖，尽量反查binlog的从库，保证主库的性能
采用redis的hash结构进行局部更新key为 设计为订单号+子表标识，如 Key 为 OrderId_BaseInfo，表示某一个订单的基本信息，或者 Key 为 OrderId_SkuId，表示某一个订单下的某个商品基本信息。在上述订单案例的多张表变更时，同步程序无须对多张表间进行分布式加锁协调，哪张表变更就去更新缓存中对应的局部信息即可。不管是同步性能还是实现难度均较好。
开发数据对比模块，虽然binlog很多升级改造，但是也有可能导致数据不一致的情况，那么我们为了保证数据的一致性，可以采用数据对比定期轮休比对数据库和缓存，增加延迟重试，如果多次比对不一致的话，增肌报警，并保存当时的数据，之后以数据库中的数据为准刷新缓存延迟重试是为了防止因同步时差，出现短暂的数据不一致但数据最终一致性的情况，其次，保留出错现场是为了排查定位问题
热点问题查询虽然单机的机器配置和程序是有上线的，但是可以进行节点间的主从复制，这样不仅可以应对查询，而且可以做到高可用，以及开发进程应用前置缓存，如何发现热点数据呢，可以采用计数器，瞬时的流量只允许一个跑到后端，其他的直接返回，跑的那个负责拉取数据刷新到应用内存内最后进行降级熔断兜底，设置QPS为压测的一半
如何保证写入的时候无差错，比如网络中断、CPU爆满等等写入的时候随机写入，并且按照权重值进行写入，比如新加的数据库一般容量大，优先写入新加入的数据库。我们在写入的时候可以维护一个可以用的列表，这样在写入的时候，如果发现数据库故障，那么就把他从当前可用的数据库列表中移除，如果大面积的数据库都不可用，那么我们需要进行扩容，那么又如何维护可用的列表呢？可以通过人工感知的方式，写服务的时候如果超过一半的认为挂了，那么就可以进行下线，下线的时候我们可以增加一个告警，因为下线的话是一个耗成本的事情，所以下线的时候可以设置一个告警，然后人工确认后再进行下线。
增加数据同步，当写入成功后同步其他数据模块，如立即刷新缓存
利用缓存+数据库构建高可用的扣减方案利用insert代替update，insert的库称为任务库，存储每次扣减的原始数据，不做真实扣减，也即是不做uptate
数据校验>开启事务>扣减明细插入数据库>进行缓存扣减>事务提交主要利用了数据库顺序写入要比更新性能快的这一特性
任务执行可以参考一致性hash，交由到具体的worker进行执行
扣减返还1、扣减完成后才能返还，必须携带扣减号，因为没有扣减号，无法找到当前的扣减明细2、一次扣减可以多次返还
3、返还的数量要小于等于原始扣减的数量，需要多扣减ID进行加锁，保证串行化执行，因为返还的流量小所以可以使用加锁的方法，来规避超卖的发生
4、保证接口的幂等性，可以通过数据库设置唯一索引来防重，进而实现幂等性