分布式系统中可横向扩展是一个相当重要的特性，加机器能解决的问题都不是问题。那么如何实现一个能够实现横向扩展的消息队列呢?
我们知道数据库的QPS是一定的，而上层应用一般可以横向扩容，这个时候如果到了双11这种请求突然的场景，数据库会吃不消，那么我们就可以引入消息队列，将每个队数据库的操作写到日志中，由另外一个应用专门负责消费这些日志记录并应用到数据库中，而且就算数据库挂了，当恢复的时候也可以从上次消息的位置继续处理(RocketMQ和Kafka都支持Exactly Once语义)，这里即使生产者的速度异于消费者的速度也不会有影响，日志在这里起到了缓冲的作用，它可以将所有的记录存储到日志中，并定时同步到slave节点，这样消息的积压能力能够得到很好的提升，因为写日志都是有master节点处理，读请求这里分为两种，一种是tail-read，就是说消费速度能够跟得上写入速度的，这种读可以直接走缓存，而另一种也就是落后于写入请求的消费者，这种可以从slave节点读取，这样通过IO隔离以及操作系统自带的一些文件策略，例如pagecache、缓存预读等，性能可以得到很大的提升。
加入有一个单机的消息队列，随着topic数目的上升，IO、CPU、带宽等都会逐渐成为瓶颈，性能会慢慢下降，那么这里如何进行性能优化呢?
1. topic/日志分片，本质上topic写入的消息就是日志的记录，那么随着写入的数量越多，单机会慢慢的成为瓶颈，这个时候我们可以将单个topic分为多个子topic，并将每个topic分配到不同的机器上，通过这种方式，对于那些消息量极大的topic就可以通过加机器解决，而对于一些消息量较少的可以分到到同一台机器或不进行分区。
- group commit，例如Kafka的producer客户端，写入消息的时候，是先写入一个本地内存队列，然后将消息按照每个分区、节点汇总，进行批量提交，对于服务器端或者broker端，也可以利用这种方式，先写入pagecache，再定时刷盘，刷盘的方式可以根据业务决定，例如金融业务可能会采取同步刷盘的方式。
- 规避无用的数据拷贝
- IO隔离
节点间数据同步、并发更新数据顺序问题(一致性问题)、持久性(系统crash时能够通过其他节点继续提供服务)、分布式锁服务