高性能MySQL笔记(第十章 复制)02
p469 ~ p534. 分为2部分, p469 ~ p501(10.1 ~ 10.4), p501 ~ p534.
一些命令
- 查看binlog,
show binlog events in 'mysql-bin.000001' from 4. 可以查看执行的每条语句
复制和容量规划
假设工作负载为20%的写以及80%的读. 为了计算简单, 假设有以下前提:
- 读和写包含同样的工作量
- 所有的服务器是等同的, 每秒能进行1000次查询
- 备库和主库有同样的性能特征
- 可以把所有的读操作转移到备库
问题1: 每秒2000次查询, 需要增加多少备库才能处理.
由于写占20%, 则400次写, 1600次读. 对于每个备库, 也有400次写, 所以最多支持600的读, 因而需要1600/600 =2.7, 即3台备库.
问题2: 每秒4000次查询, 需要增加多少备库.
800次写, 3200次读. 每个备库最多支持200的读, 因而需要16台备库. 这里写操作成了瓶颈, 导致写操作浪费了太多资源, 增加备库收益很低.
有2个维度的优化:
- 降低写操作的负载, 提高写操作的效率. 比如降低到10%. 这样只要7台备库就可支持.
具体方式如递增主键比随机主键要快, 日志写入就比随机写入效率高等. - 降低单库写入次数. 如分库分表, 将数据按维度平均划分为2个维度. 这样每个维度都是相对独立的, 每个维度的量都是每秒2000次查询, 这样就不需要太多的备库.
将上面优化方式不断进化, 就有了读写分离, Event Sourcing 和 CQRS.
传统的数据库是CRUD, 可以新增, 更新, 删除数据. 更新之后原值就丢失了, 没有相应的历史记录. 而且更新是随机写入, 效率较低. Event Sourcing的思路是将新增, 更新, 删除等动作都视为Event, 以日志插入的方式, 插入到最后, 这样写的效率很高, 而且不容易出现脏数据. 读的话, 采用实时计算的方式, 将相关的Event重放一次, 就得到最新的状态.
- 优点
记录了所有历史. 读写分离, 读和写的效率很高, 可扩展性强. 不容易出现脏数据. - 缺点
复杂性高.
参考
-Introduction to CQRS. https://www.cnblogs.com/yangecnu/p/Introduction-CQRS.html
-EventSourcing. https://martinfowler.com/eaaDev/EventSourcing.html
-CQRS. https://martinfowler.com/bliki/CQRS.html
