高性能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个维度的优化:

1. 降低写操作的负载, 提高写操作的效率. 比如降低到10%. 这样只要7台备库就可支持.
   具体方式如递增主键比随机主键要快, 日志写入就比随机写入效率高等.
2. 降低单库写入次数. 如分库分表, 将数据按维度平均划分为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