在服务端开发中，有许多反直觉的问题，这些问题乍看之下似乎违反常识，让开发人员措手不及。理解这些“反直觉”的陷阱并找到应对之道，是构建稳定高效系统的关键。本文将带你逐步解析这些反直觉的情况，并给出应对策略，帮助你在开发过程中减少“踩坑”几率。
1. 主从同步+读写分离的延迟问题
概述
数据库主从同步和读写分离通常被用来提升系统性能，但在这种架构下，主库的写操作并不会实时同步到从库。当读请求路由到从库时，可能无法读取到最新写入的数据，这带来了一种“刚写入却读不到”的现象。
实际场景
在电商网站中，用户提交订单后系统记录在主库，但由于主从同步的延迟，从库未及时更新。此时用户刷新页面，订单状态显示“无”，让用户误以为订单未成功，进而导致用户重复下单。
应对策略
- 读写一致性策略：对重要的操作强制走主库查询，避免延迟影响用户体验。
- 缓存方案：写入数据的同时，将数据缓存起来，让后续的查询可以直接从缓存中获取，减小主从延迟带来的影响。例如，订单系统写入主库后，将订单信息写入缓存，使页面查询时优先从缓存中读取最新数据，避免显示“无订单”。
- 版本控制机制：可以在写入时带上版本信息，读取数据时通过比较版本来判断数据是否最新，选择读取主库或缓存。
2. 请求到达顺序与实际发送顺序不一致
概述
在网络传输中，网络延迟和抖动会导致请求的到达顺序与客户端发送顺序不一致。例如，一个设备可能会发出一系列状态更新，但服务端收到的顺序可能并不一致。
实际场景
比如，物联网设备每10秒上传一次状态。如果网络抖动，最新的状态可能延迟到达，而旧的状态先被接收。如果服务端直接使用到达的顺序更新状态，会错误地显示过时的设备状态。
应对策略
- 客户端时间戳：在每次请求中携带发送时间戳，服务端根据时间戳来判断状态的更新顺序，而不是依赖请求的到达顺序。
- 消息ID：使用客户端生成的唯一消息ID进行状态更新，这样可以保证状态更新的唯一性和有序性，避免旧数据覆盖新数据的情况。
3. 分布式缓存中的缓存不一致问题
概述
分布式缓存系统中，为保证高可用和负载均衡，缓存数据往往会分布在多个节点上。更新数据时，可能部分节点成功、部分节点未更新，导致不同客户端读取到不一致的缓存数据。
实际场景
在多台缓存服务器上存储商品库存信息，当库存发生变化时，如果部分节点更新失败，用户可能会看到错误的库存情况。比如有的用户下单成功，有的用户却看到“缺货”，影响用户体验。
应对策略
- 一致性哈希：让同一数据在同一节点上进行读写，减少跨节点的数据不一致问题。
- 缓存失效机制：当更新数据时设置缓存失效策略，让缓存失效并重新加载主库数据，保证数据准确性。
- 分布式锁：在缓存更新操作上添加分布式锁，确保所有缓存节点完成更新后再允许读取。
4. 幂等性问题：网络重试带来的重复请求
概述
幂等性指的是多次执行同一操作不会改变结果。然而在网络不稳定时，客户端或中间设备可能会重发请求。服务端若未设计为幂等，可能导致数据重复处理或不一致。
实际场景
在银行转账系统中，用户点击转账按钮，若网络不佳，客户端可能重发请求。服务端如果未设计幂等性，可能导致账户资金被多次扣款，带来严重错误。
应对策略
- 唯一请求ID：在每次请求中附加唯一ID，服务端记录已处理的ID，避免重复处理。
- 数据库事务控制：在数据库级别实现操作幂等性，通过唯一性约束确保敏感操作（如扣款）不可重复执行。
5. 幻读现象：数据库事务隔离带来的数据不一致
概述
数据库的事务隔离级别决定了并发读写的效果，较低的隔离级别可能导致“幻读”现象，即一个事务在读数据时，另一个事务新增或修改数据，从而导致两次读取的结果不一致。
实际场景
在电商后台系统中，运营人员统计符合某个条件的订单数量。期间有新订单被插入或修改，导致统计数量与实际数量不一致，影响决策准确性。
应对策略
- 选择更高的隔离级别：使用Repeatable Read或Serializable隔离级别，防止读过程中数据被其他事务修改。
- 悲观锁与乐观锁：使用锁来锁住读取的数据，避免并发事务插入或修改，确保读取的一致性。
6. 分布式系统的时间不一致问题
概述
在分布式系统中，虽然可以通过NTP（网络时间协议）进行时间同步，但不同节点的时间仍然可能存在一定误差。依赖物理时间戳来判定顺序，会出现时间不一致的问题。
实际场景
在多节点的日志系统中，若各节点日志以本地时间记录，则可能会产生顺序混乱的情况，特别是排查错误时，误差时间较大的节点会导致事件顺序错乱。
应对策略
- 逻辑时钟：采用逻辑时钟（如Lamport时钟）或Vector时钟，在不同节点发生的事件中以逻辑顺序记录。
- 容忍误差的时间比较：在判定时间顺序时，允许一定的时间误差，减少对物理时间的一致性依赖。
7. 异步操作中的“背压”效应
概述
异步系统中，消息的生产速度可能会超过消费速度，导致“背压”效应，消息大量堆积，系统响应变慢，甚至出现拒绝服务现象。
实际场景
在高峰期间，电商系统的订单流量激增，订单服务的消息队列被挤满，导致延迟增大，处理效率下降，部分订单未及时处理，影响用户体验。
应对策略
- 限流与负载均衡：在高并发场景中限制消息生产速率，并使用负载均衡分配消息，提高系统处理效率。
- 动态扩展消费实例：增加消费实例数量，提高消费速度，减轻队列压力。
- 优先级调度：为关键消息设置较高优先级，确保关键操作优先执行，避免积压。
8. 分布式锁的失效或竞争问题
概述
分布式锁是用来控制分布式系统中共享资源的并发访问，但锁的失效、过期时间设置不当或网络延迟会导致多个实例同时获得锁，出现并发竞争问题。
实际场景
在秒杀系统中，多个请求同时访问库存数据，通过Redis实现的分布式锁可能因延迟失效，导致库存出现超卖现象，带来数据不一致问题。
应对策略
- 合理设置锁的过期时间：使锁的过期时间大于操作的最大时间，确保操作完成后再释放锁。
- 基于租约的锁机制：采用租约机制，即使锁到期也不会被其他实例抢占，保障锁的独占性。
