投票应用数据复制方案咨询：微服务拆分及数据库同步疑问

1. 你的方案是否可行？ #

你的方案可行但存在局限性：

• 优势：通过主副库分离，确实能在一定程度上实现读写分离（如果Voting服务仅做读操作），避免两个服务直接依赖同一主库，降低主库压力。
• 潜在问题：
  • 若Voting服务需要写入操作（比如更新投票计数），副本库通常是只读的，这时候你无法直接在副本库写入，同步方向会出现矛盾——总不能让Voting服务的写入反向同步到主库吧？
  • 主副库同步本质上还是共享同一数据模型，没有完全实现微服务“服务独立拥有数据库”的核心原则，两个服务的耦合度依然较高（比如数据结构变更会同时影响两个服务）。

2. 是否有必要拆分Polls与Voting服务？ #

从学习微服务的角度，非常有必要拆分：

• 职责单一：Polls服务专注于投票的生命周期管理（创建、编辑、删除投票），Voting服务专注于投票操作的执行（投/取消投票、计数统计），符合单一职责原则。
• 独立扩容：投票环节通常是流量高峰期，拆分后可以单独对Voting服务进行水平扩容，而不影响Polls服务的资源占用。
• 技术选型灵活：Voting服务可以选用更适合高频读写的数据库（比如Redis），而Polls服务用MongoDB存储结构化的投票信息，各自选择最优技术栈。

如果是小型生产应用，单服务也能运行，但既然你是为了学习微服务架构，拆分是绝佳的实践场景。

3. 此场景下数据库同步的理想方式是什么？ #

分两种场景讨论：

场景A：Voting服务仅需读取Polls的基础数据（比如验证poll_id合法性） #

直接使用MongoDB副本集原生同步即可：

• 这是最稳定、低维护的方案，MongoDB内置的副本同步机制能保证数据最终一致性，无需自己开发change stream或消息队列逻辑。
• 配置Voting服务连接副本集的只读节点，专门处理读请求，主库仅处理Polls服务的写入请求，实现读写分离。

场景B：Voting服务需要独立存储投票数据（比如计数）并与Polls服务同步 #

放弃主副库同步，采用事件驱动+服务独立数据库的架构，这是微服务场景下的理想模式：

1. 每个服务拥有独立数据库：
   • Polls服务的MongoDB存储：poll_id(pk), name(str), voters(用户列表)
   • Voting服务的数据库（推荐Redis，适合高频计数）存储：poll_id, option_counts(哈希表 str:int)
2. 用消息队列（比如Kafka、RabbitMQ）实现数据同步：
   • Polls服务创建投票后，发送PollCreated事件到消息队列，携带poll_id、选项信息等。
   • Voting服务监听该事件，在自己的数据库中初始化对应投票的计数（每个选项初始为0）。
   • 用户投票时，Voting服务直接更新自己数据库中的计数，若需要同步投票用户列表到Polls服务，可发送VoteRecorded事件，Polls服务监听后更新voters列表。
3. 为什么比change stream好？
   • 解耦性更强：不依赖MongoDB特定功能，服务间通过通用的事件协议通信，后续替换数据库或服务技术栈更灵活。
   • 可扩展性更好：消息队列支持重试、幂等处理、死信队列等机制，能更好地应对异步同步中的错误和重复事件。

关键注意事项 #

• 幂等性：所有事件处理逻辑必须保证幂等（比如重复收到PollCreated事件时，不会重复创建投票计数）。
• 最终一致性：异步同步会存在短暂的数据延迟，若业务要求强一致性（比如投票后立即在Polls服务看到结果），可临时采用同步调用+异步事件补偿的方式。

内容的提问来源于stack exchange，提问作者Vedank Pande