weixin_46084191的博客

布隆过滤器通过多个哈希函数将元素映射到位数组中，置位对应位置。查询时若所有哈希位均为1则可能存在，否则必定不存在。其优点是空间效率高，但存在一定误判率且无法删除元素，适用于允许误差的快速存在性检测场景。

消息队列通过生产者按顺序发送至同一分区/队列，消费者单线程顺序处理实现。需确保同一业务标识的消息路由到相同分区，并限制分区仅被一个消费者消费。部分中间件支持全局顺序或局部顺序控制，同时需处理异常重试机制防止乱序。

消息队列通过多环节保障机制防止消息丢失：生产者使用确认机制（如ACK）确保消息成功发送至Broker；Broker采用持久化存储（如磁盘写入）和副本同步防止数据丢失；消费者处理成功后手动提交确认，失败时触发重试；消息重试机制和死信队列处理异常情况；整体通过事务机制或幂等设计保证端到端一致性。

为确保Redis与数据库双写一致性，常用方法包括：先更新数据库再删缓存（Cache-Aside）、延迟双删（更新前后均删缓存并延迟二次删除）、基于消息队列异步同步、监听数据库binlog触发缓存更新，以及设置缓存过期时间兜底。需结合业务场景选择策略，配合重试机制确保最终一致性。

CAP理论是分布式系统的核心原则，指出一致性（C）、可用性（A）、分区容错性（P）三者无法同时满足。一致性要求所有节点数据实时一致，可用性强调每个请求都能获得响应，分区容错性指系统在网络分区时仍能运行。实际中网络分区难以避免，通常需在C与A之间权衡，例如CP系统优先保障一致性与容错，AP系统优先保障可用性与容错。

分布式事务用于跨系统操作时保证数据一致性，常见解决方案包括：两阶段提交（2PC，强一致性但性能低）、TCC补偿事务（业务层补偿）、基于消息队列的最终一致性（异步高可用）、Saga模式（拆分事务+逆向补偿）。各方案根据场景权衡一致性与效率。

分布式锁通过在共享存储系统中维护互斥状态，确保多个节点间资源访问的排他性。常见实现包括：1. 基于数据库（如唯一约束、乐观锁）；2. Redis（SETNX命令或RedLock算法）；3. ZooKeeper（临时有序节点+Watcher监听）；4. Etcd（基于Raft协议的事务与租约机制）。不同方案在性能、一致性和复杂度上各有取舍。分布式锁的本质是通过共享存储系统的原子操作实现互斥，需根据业务场景在性能、可靠性、复杂度之间权衡。

消息队列的推模式适合实时性高、消费者处理能力强的场景（如即时通知），由服务端主动推送减少延迟。拉模式适用于消费者需控制速率、批量处理或资源受限的情况（如日志分析），客户端按需拉取避免过载。推模式依赖服务端负载均衡，拉模式更灵活但可能增加延迟。

消息队列通过以下机制避免重复消费：1. 生产者端添加唯一消息ID实现发送幂等性；2. 消息队列服务端支持Exactly-Once语义（如Kafka事务消息）；3. 消费者端采用去重机制（如数据库唯一索引、Redis原子操作记录已消费ID）；4. 业务逻辑设计幂等处理（如状态检查、乐观锁）；5. 正确维护消费位移，确保异常后能从正确位置恢复。