【高并发】——设计系统（2）

前面已经说了关于MQ消息的一些问题，接下来，如果需要你来设计一个MQ框架，你会怎么去考虑？

1. MQ需要支持伸缩性，也就是不要的时候快速扩容，那就参考kafka的设计理念broker -> topic -> partition，每个 partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给 topic 增加 partition，然后做数据迁移，增加机器
2. MQ的数据需不需要落数据库，其实就是为了防止数据丢失，kafka的思路就是顺序写，这样性能会更好（不需要寻址开销）
3. MQ的可用性，这个就是前面说到的说到的多副本的情况，这样的才能保证我们的机器宕机之后能够完美的切换到另外一台上面去，并且数据不会丢失
4. 需要支持数据0丢失，这个之前的方案中有说到过

如何解决消息队列的延时以及过期失效问题

我们的一个真实的场景就是，因为我们的消费机器是单台的（现在改成两台了），所以每次在发版的时候都会导致一部分的MQ消息的积压，当然因为我们目前的数据量没有这么大，所以消费者一旦正常消费，基本上十几分中内就能够消费完成，但是现在的情况是加入我们的是Mysql挂了，整个机器hang那儿了，导致了大量的数据积压在MQ消息队列中，可能达到几百万或者几千万条，那该怎么办？

• 针对大数据量的积压问题，我们需要临时扩容，然后快速消费掉，消费完之后恢复正常
• 针对MQ中的消息过期了，RabbitMQ是可以设置失效时间的，这样我们的一部分消息就会丢失，正常的我们需要手动补数据了
• 针对MQ快写满了怎么办？其实这个就是需要结合上面的两种方法，先临时扩容，然后补推消息

Mysql的读写分离？怎么实现读写分离？

简单来说就是一主多从，一个主库，然后加上n个从库，主库只负责写数据，从库负责查询数据，一般的业务场景都是写少读多，所以这样的情况下读写分离就比较合适，原理是：主库变更写入binlog日志，然后从库连接主库，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，然后执行 binlog 日志中的内容，也就是重新执行一遍主库的sql，这样就能够保证从库的数据与主库的数据是一致的了，但是问题是主库在执行sql的时候是并行的，但是从库是串行的，这样就会导致从库的数据更新会比主库慢，可能会有一定时间的延迟，另外一种情况就是当数据还没有同步到从库的时候，主库突然宕机，就会造成从库的数据丢失。

• 数据丢失：半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了
• 同步延迟：并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。

但是同步延迟的问题在现实中还是依然存在的，正常我们生产中如果出现了同步延迟较为严重的情况，我们需要从以下几个方面入手：

• 分库，将一个主库拆分成几个主库，每个主库的并发就会减少好几倍，此时主从延迟就会减低，基本可以忽略不计
• 并行复制，当单个库的并发达到2000左右的时候，并行复制就显的没有意义了
• 从代码层面来避免，对于刚插入就立马查的业务需要考虑必要性，对于要求立马就能个查询到的需求，我们需要查询主库，但是这样就违背了我们读写分离的初衷