首页
学习
活动
专区
圈层
工具
发布
首页标签上海同盟

#上海同盟

核心交易链路,单库垂直拆 vs 分布式,什么体量才真该上分布式?

技术方舟

科大讯飞 | 资深架构师 (已认证)

江湖人称“山哥”,在数字化、人工智能、电商和金融等领域积累了丰富的平台架构设计经验
核心交易链路是否升级分布式,关键不在用户量或数据规模,而在单库是否已无法通过优化、拆分和治理满足性能、容量与可用性目标。多数业务应优先采用模块化单体、按订单、支付、库存等领域垂直分库,并结合读写分离、缓存、异步化、归档和分库分表预案。该模式本地事务清晰、一致性强,排障、对账和运维成本较低,尤其适用于支付扣款、库存扣减等强一致场景。 分布式架构可横向扩展存储与写入能力,支持热点隔离、独立扩容和跨地域部署,但会引入跨库事务、幂等重试、消息重复或乱序、补偿对账、全局 ID、跨分片查询及数据迁移等复杂问题。因此,不宜因“技术先进”而过早采用。 一般而言,当核心写入持续达到数万 TPS、热点表增长至超亿级且维护困难、单业务域长期达到多 TB 至数十 TB、必须跨地域多活,或大商家和热点活动需要独立隔离时,应认真评估分布式。但具体还取决于数据是否均匀、是否存在热点账户或库存。 升级前应完成领域拆分、缓存限流、异步削峰、冷热归档、热点治理、幂等与补偿机制,并以压测和故障演练验证单库确实无法达标。最终标准是:在峰值和故障下,仍能保证不重复扣款、不超卖、不丢单、账实一致。... 展开详请

RAG 接上知识库后,谁来负责持续更新?

分布式数据库锁冲突如何优雅降级?

Jack20Never give up,than you will be successful

idle-in-transaction 主要是事务开启后,拿到热点行锁,业务逻辑卡住、网络超时、下游调用慢,事务一直不提交 / 回滚,行锁长期持有,后面大量请求排队形成锁等待阻塞链,最后雪崩。

分布式库做 HTAP,平凯/TiDB/OceanBase 各自踩坑点在哪?

领券