28 | 读写分离有哪些坑

读写分离

上图中是客户端主动做负载均衡，这种模式下一般会把数据库的链接信息放在客户端的连接层。也就是说，由客户端来选择后端数据库进行查询。

还有一种结构是，在MySQL和客户端之间有一个中间代理层proxy，客户端只连接proxy，由proxy根据请求类型和上下文决定请求的分发路由。

两种方式各自的特点：

1. 客户端直连，因为少了一层proxy，查询性能稍微好一点，并且整体架构简单，排查问题更方便。但是这种方案由于要了解后端部署细节，所以出现主备切换、库迁移等操作的时候，客户端都会感知到，并且需要调整数据库连接信息。一般采用这样的架构，一定会伴随一个负责管理后端的组件，比如Zookeeper，尽量让业务端只专注于业务逻辑开发。
2. 带proxy的架构，对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由proxy完成的。但这样的话，对后端维护团队的要求会更高。而且，proxy也需要高可用架构。因此，带proxy架构的整体就相对比较复杂。

目前看，趋势是往带proxy的结构方向发展。

但是，不论哪种架构，都会遇到主从延迟问题。

这种“在从库上会读到系统的一个过期状态”的现象，在这篇文章里面，称之为“过期读”。

解决方案：

• 强制都主库方案；
• sleep方案；
• 判断主备无延迟方案；
• 配合semi-sync方案；
• 等主库位点方案；
• 等GTID方案。

 

上一篇：27 | 主库出问题了，从库怎么办？

下一篇：29 | 如何判断一个数据库是不是出问题了？