CAP理论指出，在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三者不可兼得
CAP理论指出在分布式系统中一致性Consistency、可用性Availability和分区容错性Partition tolerance三者不可兼得最多只能同时满足其中两项。由于网络分区P在分布式系统中不可避免实际选型聚焦于CP放弃A与AP放弃C的权衡。✅CP系统特点网络分区发生时优先保证数据强一致如线性一致性可能拒绝部分请求牺牲可用性适用于金融交易、库存扣减、账务系统等对数据准确性要求极高的场景典型代表ZooKeeper、etcd、HBase默认配置、SpannerTrueTime同步复制实现近似CP。✅AP系统特点分区时仍持续响应请求高可用但允许副本暂时不一致最终一致性适用于社交动态、推荐列表、用户评论、日志采集等容忍短暂不一致的场景典型代表Cassandra、DynamoDB默认配置、Riak、Eureka服务发现。选型判断四步法确认分区容错是否必须→ 是所有现代分布式系统都必须满足P评估业务能否容忍“读到旧数据”或“写入失败”→ 若写入失败导致严重后果如重复下单、超卖倾向CP→ 若短暂不一致可接受如点赞数延迟更新倾向AP考察一致性模型需求是否需要事务、跨行/跨表强一致→ CP更易支持结合运维与生态CP系统通常需更多节点协调如Raft多数派投票延迟略高AP系统扩展性好、延迟低但需应用层处理冲突如向量时钟、CRDT。 实际中常采用混合策略核心链路CP如订单创建支付非核心链路AP如浏览记录、行为埋点或通过TCC/SAGA等柔性事务在AP底座上模拟最终一致性保障。# 示例电商系统中库存服务的CP/AP决策逻辑伪代码defchoose_consistency_model(order_type:str,region:str)-str:iforder_typein[flash_sale,financial_settlement]:returnCP# 强一致防超卖/资金错误elifregionglobalandlatency_sensitive:returnAP# 跨洲部署优先响应用版本号后台对账修复else:returnCP_with_read_replica# 主库CP写从库AP读最终一致在微服务架构中用户中心服务涵盖用户注册/登录、会话管理、Token签发、角色权限RBAC/ABAC、密码重置、多端登出等是系统身份认证与访问控制的核心其CAP选型需兼顾安全性、用户体验、合规性与可用性不能简单归为纯CP或纯AP而应采用分层分级策略 场景化权衡。✅关键判断逻辑与具体指标维度CP倾向场景强一致优先AP倾向场景高可用优先决策依据量化/业务指标登录态写入如生成JWT/Session/Redis Token✅ 首次登录、密码修改、敏感操作如绑定手机后强制刷新所有端Token❌ 不适用写不一致将导致越权或登出失效一致性要求等级是否涉及“一次写多端生效”若支持“一处登出全端失效”则必须CP如Redis Cluster主从同步WAIT指令或使用RedLock过期时间强约束登录态读取如校验AccessToken有效性、获取用户权限⚠️ 可接受短暂最终一致如从只读副本读取但需容忍≤100ms延迟不一致✅ 全局只读流量大、地域分散如海外用户访问亚太Token校验服务可用性SLA要求若99.99%可用性目标不可降级如ToC App启动必须鉴权成功且允许“刚登出后1秒内仍可访问”则可AP读配合本地缓存短TTL主动失效通知权限数据变更如管理员修改某用户角色✅ 必须CP权限变更需毫秒级全局生效否则存在越权风险如撤销管理员权限后仍能访问后台❌ 禁止AP权限不一致安全漏洞RTO/RPO指标权限更新RPO0零数据丢失RTO500ms违反即触发审计告警用户基础信息读如昵称、头像✅ 可AP允许秒级延迟CDN缓存、本地缓存异步刷新—读写比 一致性敏感度读写比100:1且业务容忍“改名后旧昵称显示1~3秒”分布式会话存储选型参考• Redis单节点/哨兵→ CP倾向主从同步完成前拒绝读• Redis Cluster默认配置→AP分区时从节点可能提供过期数据→ 需开启cluster-require-full-coverage no 客户端重试版本号校验• etcd/ZooKeeper → CP强一致但写吞吐低适合权限元数据• CassandraQUORUM读写→ 可调为CP但默认ONE级别为AP• 自研DBGossip协议 → 常AP需应用层冲突解决P99延迟要求20ms → 排除ZK分区发生概率如跨云部署→ 高则倾向AP容错设计推荐实践方案混合CAP写路径Login / Logout / GrantRole / RevokeRole→ CP保障使用etcd或强一致Redis主节点直写 WAIT 1 1000等待至少1个从节点确认 分布式锁如Redisson防并发冲突。读路径Token校验 / 用户信息查询→ AP优化引入「本地缓存Caffeine 分布式事件驱动刷新」权限变更后通过消息队列如RocketMQ广播PermissionUpdatedEvent各服务消费后清除本地缓存实现秒级最终一致同时保障99.99%读可用。灾备与降级当CP存储不可用时自动降级为「只读AP模式」返回缓存中最近有效Token和权限快照并记录审计日志禁止任何写操作——满足GDPR/等保三级对“故障期间不扩大风险”的要求。一句话决策口诀“写安全必CP读体验可AP权限改零延迟登出全强同步缓存稳靠事件。”
