乍一看这不就是我现在接触的业务的存储现状么。。正好有碰到主从延迟引起的故障，这里针对读流量的处理多记录两句。
这样做虽然保证了一致性，但是留下了隐患。主从更新延迟过高时，主节点压力可能已经上升，此时再讲读流量打到主节点上对恢复服务不一定有帮助，甚至可能恶化局势。
对于一致性敏感的读流量，可以记录读时的主节点 binlog 位置，等到从节点追上后再进行读操作。保证一致性，但是会增加延时。
如果主从延迟飙升时，出现从节点一直难以在超时时间内追上主节点怎么办？ 答：可以记录一个请求 or 用户维度的 binlog 戳，后续读重试的时候以这个 binlog 戳为判断依据，而不是记录读请求发生时的主节点 binlog 位置。
后续可以参考这个做法，减少存储层读写分离对于业务的影响。上次业务上出了个故障就是读写分离切换过于粗暴，错误的读结果被带到了消息里，持久化到了别的存储里= =。
- 确保写入以及结果保证一致性的查询结果才能被缓存
- 缓存空值。类似的，Guava cache 中的缓存 K-V 中的 value 设为 optional 应该就是出于这个考虑。
- lease 使用这边，等 cache is the root of all evil 这篇理解完了再补充
这里遇到的问题是特定用户的请求可能造成负载过高，引发连锁反应。为了及时扼杀这种可能性，需要探测特定来源的负载。
- 在分布式的系统上再构建一个集中式的限流层不可取，容易变成新的瓶颈，并增加系统可能的失败点
- 于是决定采用分布式算法，在各个节点间传递负载信息，在有限轮次里达成大概率收敛。其基础是 Gossip-Based Computation of Aggregate Information，在此基础上讲时间流切分为时间段来计算离散化的流式负载。
这个就比较直白了，给写流量按业务需求分级，类似于线程按优先级调度。不展开记录了。
p.s. 分布式一致性真的是个巨坑，分布式一致性 + 高可用的东西可以多看起来了