首先如果我开始做一个消息队列，最开始的时候可能就是一台单机上的一个单一的log日志，不断地向这个日志中追加消息即可。
后来，可能由于一个log日志支撑不了太多的读写请求，于是就对这个log日志进行了拆分。于是就出现了一个topic有多个log日志的情况。
一条消息来了，可以保存到任意的log文件中，当然也可以自己指定算法来使得某个生产者产生的消息都保存到一个固定的log文件中。
这样好像性能上来了，但是这样每个log都是没有副本机制的，也就是说如果一个log日志如果坏掉的话，这个topic的一部分数据就全部都丢失了。
这种情况我觉得是不能忍受的，所以就想到了要把多个log都同时同步到多台其他的机器上去。这时候，原来的那台单机上分布的都是最主要的log日志，其他机器只是负责实时备份了一下这些log日志。这样有什么问题呢？问题就是你发现了，备份机器基本上没啥用，除非原来的那台机器上确实出现了log丢失的情况，其他的备份机器才能派上用场。就出现了最主要的那台机器忙死了，一直要负责写和读请求，这样从架构上考虑是不太均衡的。那么这时候能不能让读请求去副本机器上去读呢？当然可以。这样写的请求发送到最主要的那台机器，其他的读请求发送到备份机器，这样很好地缓解了原来的那台单机的读写压力。
这时候我如果作为开发者，我会想，这样好像还是能继续优化一下。因为如果那台最主要的机器一直负责写的话，磁盘不停被写容易坏。其他机器备份机器好像就只负责读，基本上磁盘不容易坏。能不能均摊这些读写压力。可以把一个topic下的多个分区的只写log均衡分布到多台备份机器上。这样比如我虽然写的都是某个topic，但是消息会均衡的写到不同机器上去。相当于打散了只写log和备份log到不同机器上。只写log所在的就是该分区的主管。其他的备份log就是该分区的小弟。这样就能做到每一台机器都是平等的。不再从机器上去区分只写机器和只读机器了。每台机器都是可读可写的，只不过只读的可能是分区A，只写的是分区B。相当于这台机器是分区B的老大，同时也是分区A的小弟。