kafka为什么不采用读写分离的架构实现

最近被问到一个问题，kafka既然也是一个分主从的集群架构，为什么不采用读写分离的实现，刚刚听到这个问题的时候我有点懵，读写分离，为什么要读写分离？

于是硬着头皮回答了一些，

1.读写分离的架构会让实现更加的复杂，可能引入未知问题和破坏结构的清晰

2.读写分离可能导致数据不一致的情况

后来看了一些别人的观点后觉得，这个回答虽然有点道理却并不算完整，虽然对一些其他的观点我也不完全认同。

在此我不会从原理和源码的角度发表长篇大论，只是单纯的从我自己的角度写一点思考。

关于这个问题，一些提到比较多的回答其实也包含了上面两点，另外还有成本和收益不匹配说

我觉得从这个角度来说是可以的，

从使用场景来说，kafka并不需要或者这样的需求很小，所以并没有选择读写分离。

首先我们需要知道为什么要读写分离，主要是为了缓解同一个节点的压力，我们知道一般情况下写是一个排他的行为，可能需要涉及加锁等比较重的操作，但是读一般来说都是可以共享的，可以同时发生的操作。

再说读写分离的应用场景，主要用于解决一次写入，多次读取的，读和写的比例相差比较大，为了提高系统的可用性和处理能力，会考虑使用读写分离架构。

说回kafka的使用场景，一般是作为消息中间件使用，写入kafka的消息不能被修改，所以只能一次写入，kafka消息会被不同的消费者读取，也可能被反复的读取，看起来符合多次读取的条件，不过一般对kafka消息的读取都是在刚刚写入完成之后，或者写完相对比较短的一段时间之后，因为消息有过期时间，一般不会，也不能读取很早之前的数据，所以kafka的使用不能算一次写入多次读取的场景。

有人说，读写分离是一种对于设计不合理的架构的一种补充，kafka因为架构设计非常优秀所以不用这种补充，这种说法是有点过于彩虹屁了。

另外一个角度是负载均衡，

读和写都是通过Leader，topic的partition是比较均匀分布在各节点的，对于个节点的负载相对比较均衡。不过需要注意的是，生产者和消费者都可以指定特定的分区读写，同时因为消息分区算法的原因，也可能导致分区内数据不均匀导致负载不均匀。

总结一下，从成本和收益的角度来考虑这个问题是合理的，所以原因可以是

1.引入读写分离会导致架构更复杂

2.可能会有数据不一致的问题

3.在kafka的设计场景下，并没有太多读写分离的需求

4.topic的partition划分是按leader均匀分配在各节点的，读写都走Leader的话，可以一定程度做到负载均衡