作者回复: 有兴趣可以看pmq源码： https://github.com/ppdaicorp/pmq 是一个经典的分库分表案例。

作者回复: DB对比文件的优势： 1. 数据库成熟，并且已经有成熟的HA方案，比文件更可靠 2. 可以方便查消息 3. Broker和存储分离，Broker无状态，可以简单扩展 性能比较：DB和文件应该在同一量级，写入和读取基本都是顺序操作，没有哪个有明显的性能问题。 DB的劣势：需要单独的DB数据库，成本稍高，不像Kafka只要Broker上的文件存储就好了。

作者回复: 嗯，从理论上讲，生产者/消费者直接访问数据库，也可以实现PMQ的功能。但是这样生产者/消费者就和数据库直接耦合了，而且生产者/消费者的逻辑会变得非常复杂，难以维护和升级，比方说数据库扩容的话，生产/消费者的连接字符串都需要调整。 增加一层Broker作为间接，生产/消费者和DB就不耦合，通过Broker可以屏蔽DB的扩容升级等变化，而且生产/消费逻辑简单，易于升级维护。

作者回复: 你的理解是正确的，一个queue里头的数据是状态，如果一个consumerGroup中的两个consumer同时消费的话，必然存在状态竞争问题，加锁对性能的影响非常大，而且两个consumer之间还需要同步消费指针，开销更大，所以一个consumerGroup中的两个consumer不能同时消费一个queue。

作者回复: 同一个topic的所有partition存储的消息都是属于这个topic的，比方说和order订单更新消息相关联的topic叫order_update_msg，那么所有和订单更新相关的消息，都会分布在这个order_update_msg的不同partition中。

作者回复: 你好，我并没有说文件系统一定没有数据库可靠，毕竟数据库底层也是基于文件系统的。 只不过MySQL之类的数据库已经比较成熟，大量可靠性技术已经沉淀在里头，换句话说，坑已经基本上被踩平了。 基于文件在不同节点上存副本，当然可以做到高可靠，不过我觉得有点复杂了，远没有MySQL主从来得简单成熟让人放心(波波个人观点)。

作者回复: PMQ(包括kafka)都是采用消费者拉模式的，不是推模式。也就是说消息是消费者主动来拉的，不是Broker主动推的。这个一定要先理解。 消息在PMQ的DB中(或者Kafka的broker上)，只需要存一份。但是消费者可以组成不同的消费者组(consumer group)，然后都可以来拉同一个分区中的消息，只要各自维护自己的消费者指针就可以了。 这一节课你可以多消化下，把数组和指针的那个ppt看明白。

作者回复: 1，自增主键可能出现不连续，生产端没有关系，消费端client会自动处理。 2，mysql数据库的HA主要采用MySQL MHA机制实现，解决多库事务问题成本很高，发生问题概率很低，综合评估下来暂没有实现，如果确实发生，目前依赖人工解决。