分布式系统常见问题

一.概述

分布式系统存在网络，时钟，以及许多不可预测的故障。分布式事务，一致性与共识问题，迄今为止仍没有得到很好的解决方案。要想完美地解决分布式系统中的问题不太可能，但是实践中应对特定问题仍有许多可靠的解决方案。本文不会谈及诸如BASE, CAP, ACID 等空泛的理论，只基于实践中遇到的问题提出可行的解决方案。

二.常见问题

1.读自己的写

现象： 用户在发布页发布了帖子，然后访问自己的主页查看帖子列表，并没有马上看到自己刚刚发布的帖子，等待1~2s后才看到

分析：后端db采取主从结构，复制任务在负载较高的情况下会有延迟。用户读取帖子列表查询的是从节点，所以无法及时看到刚刚发布的帖子。一般情况下延迟1~2s是可以接受的，但是为了更好的体验，可以做一些改进。

解决方案：

• 如果用户读取的是自己的主页，就访问主节点。如果访问是他人的主页，就访问从节点。只需要在db层路由即可。
• 客户端还可以记住最近更新时的时间戳，并附带在读请求中，据此信息，系统可以确保对该用户提供读服务时都应该至少包含了该时间戳的更新。如果不够新，要么交由另一个副本来处理，要么等待直到副本接收到了最近的更新

2.单调读

现象：用户查看某个帖子下面的评论，一会儿看到5条评论，一会儿看到6条评论。

分析：后端db采取主从结构，复制任务在负载较高的情况下会有延迟。用户读取评论列表查询的是从节点，但是两次读的是不同的从节点，当某个从节点具有明显延迟就会出现数据反复的现象。

解决方案：

• 确保同一个用户每次都是读取同一个副本，可以在db层进行路由。这是一种典型的sticky 请求路由。

    replica = hash(user_id) % number_of_replica

3.负载倾斜与热点问题

现象：某个分区的数据明显比其他分区多，并且访问频率高，负载压力大。

分析：在某些特殊的业务场景下，比如官方或者名人账号有百万粉丝，当这些账号发布消息事件时，人们会对该消息进行评论，如果评论数据存储使用事件id进行hash，就会造成某个分区的负载产生倾斜。

解决：

•   在关键词，比如消息事件id，的开头或者结尾添加一个随机数。只需一个两位数的十进制随机数就可以将关键字的写做操作分布到100个不同的关键字上，从而分片到不同的分区上。这些特殊逻辑只应用在一些特殊账号上。

4.fencing令牌

现象：在采用分布式锁的情况下，数据库中的事务重复执行。

分析：在分布式锁环境中，客户端A执行事务超时，分布式锁被释放。客户端B执行事务插入数据。客户端A恢复后继续执行事务，重复插入数据。

解决方案：

• 这不是分布式事务的范畴。可以采用fencing令牌来解决。我们假设每次锁服务授予锁或租约时，同时还会返回一个fencing令牌，该令牌每授予一次就会递增。然后，要求客户端每次向存储系统发生写请求时，都必须包含所持有的fencing令牌。当使用zookeeper 作为锁服务时，可以用事务标识zxid，或节点版本cversion来充当fencing令牌，这两个都可以满足单调递增的要求。

5.Lamport时间戳

现象：客户端从两个分区获取两条不同的数据，比如事件a, b；a的序号小于b，但事实上b比a先发生。

分析：常见的有以下几种非因果序列发生器，产生的序列号与因果关系并不严格一致。

• 每个节点单独产生自己的一组序列号。
• 把墙上时间戳信息（物理时钟）附加在每个操作上。
• 预先分配好序列号的区间范围，比如节点A负责区间1~1000的序列号，节点B负责1001~2000。

解决方案：

• 使用Lamport时间戳。Lamport时间戳是一个kv对（计数器，节点ID）。核心流程：每个节点以及每个客户端都跟踪迄今为止所见到的最大计数器，并在每个请求中附带该最大计数器值。当节点收到请求（或者回复）时，如果发现请求内嵌的最大计数器大于节点自身的计数器，则它立即把自己的计数器修改为该最大值。

6.端到端的重复消除问题

现象：消息重复是非常普遍的，比如

• 生产者发送消息到消费者，消费者消费成功后宕机，但是却没有更新消费位置，消费者重启后就会重新消费。
• 常见的rpc调用，调用方因为网络问题没有收到被调用方的响应，选择重试。
• 2PC 分布式事务中，因为网络问题，也可能出现重复事务的问题。
• 用户在页面重复提交POST请求。

分析：端到端的重复问题是非常普遍的，在TCP 网络中也需要处理重复数据包的问题。有以下两种解决办法：

• 最有效的办法之一是使操作满足幂等性，即无论执行一次还是多次，确保具有相同的结果。比如以下语句无论执行多少次效果都是一致的。

   update table set v = v2 where v = v1

• 可以为操作生成一个唯一的标识符如（UUID），服务端对此UUID 进行去重校验。

• 在典型的电商下单接口中采用了以上两种方法的结合：使用唯一标识符来进行去重，如果写入异常返回之前的订单。

create table order(
  # ...
  dedup_key varchar(60) not null comment 'key to pretend order duplication',
  client_id,
  # ...
  unique uniq_dedup_key(dedup_key, client_id)
);


@Transactional
Order createOrder(Integer userId, String prodCode, Decimal amount, String dedupKey) {
  try {
    String orderId = createOrder(userId, prodCode, amount, deupKey); // insert a new order
    Order order = getOrderById(orderId); // read order from db
    order.setDuplicated(false); // 标记是否有重复下单
    return order;
  } catch(UniqueKeyViolationException e) {
    // if duplicated order has existed, return previous order
    Order order = getOrderByDedupKey(dedupKey, clientId);
    order.setDuplicated(true);
    return order;
  } catch (Exception e) {
    // hanlde other errors and rollback transaction ...
  }
}

7.唯一性约束

现象：在集群高并发的环境下，用户A创建用户marquezzzz，用户B同时创建了用户marquezzzz，两者的用户名相同，这违背了唯一性约束。

分析：创建用户名的逻辑是，先去db中查询是否有对应的用户名（步骤1），如果没有就创建，如果存在就更新用户的其他信息（步骤2）。用户A执行了步骤1， 用户B执行了步骤1和2，然后用户A执行了步骤2，这样生成了两个同名的用户。

解决方案：

• 串行化请求，将创建用户的请求串行化，比如发送到队列中，这样可以确保全局唯一性。
• 在db层进行唯一性约束，比如使用唯一索引，考虑到庞大的数据量，性能会下降。如果做了分表，唯一索引的方法也不太可行。
• 使用分布式锁，比如redis, zookeeper，redis伪代码如下：

boolean r = redisClient.setnx("userName", currentThread, 10s); // 使用 setnx 原子命令
if (!r) {
    return false;
}

// 步骤1 查找db确保没有重名

// 步骤2 插入用户

redisClient.delete("userName");

8.时钟问题

现象：在许多app中，客户端会上报事件，但是事件的发生时间不准确

分析：app客户端时钟可能不准确，或者用户手动调整过系统时钟。

解决方案：

为了调整不正确的设备时钟，一种方法是记录三个时间戳：

1. 根据设备的时钟，记录事件发生的时间, device_event_time
2. 根据设备的时钟，记录将事件发生到服务器的时间, device_send_time
3. 根据服务器时钟，记录服务器收到事件的时间, server_receive_time

事件真实发生时间 = device_event_time + (server_receive_time - device_send_time)

三.参考

《数据密集型应用系统设计》

https://cloud.tencent.com/developer/article/1121727