微服务架构下如何避免数据重复？以Twitter克隆项目为例

你的选择方向是对的 #

首先明确：在Twitter这种读密集、对响应延迟要求极高的场景下，你倾向的「Timeline服务维护本地内存数据」的方案，完全是符合微服务设计逻辑的合理选择——这不是所谓的“数据重复反模式”，而是业务驱动的必要设计。

两种方案的核心优劣对比 #

方案2（跨服务调用）的硬伤 #

• 服务耦合严重：Timeline依赖Post和Follow两个服务，只要其中一个挂了，Timeline就无法正常返回数据，直接违背了微服务“自治、高可用”的核心原则
• 性能瓶颈明显：每次请求都要先调Follow服务拿关注列表，再批量调Post服务拿动态，跨服务调用的网络延迟+服务处理延迟叠加，并发量上来后根本扛不住
• 复杂度飙升：要处理分布式调用的超时、重试、熔断等一堆问题，开发和运维成本直接翻倍

方案1（本地内存数据库）的核心优势 #

• 极致低延迟：内存读取的速度比跨服务调用快几个数量级，能保证时间线毫秒级响应，完全符合社交产品的用户体验预期
• 服务高度自治：就算Post或Follow服务故障，Timeline依然能返回已缓存的历史动态，可用性拉满
• 扩展性更强：可以独立对Timeline服务做水平扩容，专门应对读请求的峰值，不用牵扯其他服务

AWS环境下方案1的落地细节 #

数据同步要靠事件驱动 #

别自己写定时任务去拉数据，用AWS的事件生态搞定：

• Post Service发布新动态时，通过SNS发送PostCreated事件，把动态内容、作者ID、时间戳带上
• Timeline Service订阅这个事件，找到所有关注该作者的用户，把新动态加到他们的时间线内存数据里
• Follow Service处理关注/取消关注操作时，发送FollowUpdated事件，Timeline Service收到后更新对应的用户关注列表，后续只同步这些作者的动态

内存数据库选Redis就够 #

用AWS ElastiCache Redis：

• 用Sorted Set存储用户时间线，把时间戳作为score，这样可以快速通过ZREVRANGE命令取最新100条动态
• 开启RDB或AOF持久化，避免服务重启后数据全丢
• 可以给Redis集群做分片，应对大量用户的时间线存储需求

一致性与容错要做兜底 #

• 接受最终一致性：用户刚发的动态可能延迟几秒出现在关注者的时间线，这在社交产品里用户完全能接受
• 加个数据补全机制：每天凌晨或者监测到事件同步失败时，让Timeline Service主动调用Post和Follow服务做一次全量同步，把遗漏的数据补回来
• 清理过期数据：只保留用户最近100条动态，超出的直接删除；长期不活跃用户的时间线设置过期时间，定期清理节省内存

总结 #

总的来说，在你的Twitter克隆项目里，Timeline服务维护本地内存数据是最优解。核心是用事件驱动保证数据最终一致，同时兼顾服务的自治性和性能，完全贴合微服务的设计理念。

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