CAP、BASE、接口的幂等性、消息中间件是什么

1.CAP 理论

CAP 理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）

这三项中的两项。拿一个网上的图来看看。

2.BASE 理论

BASE 是 Basically Available (基本可用) Soft state(软状态) Eventually consistent(最终一致性)这几个单

词的缩写,

是从 CAP 理论发展而来的,其核心思想是:即使无法做到强一致性,但每个应用都可以根据自身特点,采

取适当的方式来使系统达到最终一致性.

3.接口的幂等性问题

幂等的意思是重复操作,接口的幂等性也就是接口被重复调用了,在前端不进行限制的情况下,同一个

接口可能重复调用多次,为了避免类似重复下单的问题,可以通过以下几种方式来解决幂等性问题:

全局唯一 ID,根据业务操作和内容生成全局唯一的 ID,然后在执行操作前先判断是否已经存在该 ID,如

果不存在则将该 ID 进行持久化(存在数据库或者 redis 中),如果已经存在则证明该接口已经被调用过

了.比如下单时可以生产一个流水号来作为该订单的唯一标识.

可以使用 select+insert 来进行判断,因为一般订单的 ID 都是唯一索引,在高并发场景下不推荐.

可以使用乐观锁解决,在表中可以添加一个 version 字段.

token 机制,将 token 放在 redis 中.

4.消息中间件如何解决消息丢失问题

可以在消息发送者这里发送一个 id,接收端收到消息后将该 ID 存储于 DB 中,然后可以通过判断 DB 是

否存在该 ID 来确定消息是否成功发送.

当然现在的消息中间件都比较强大,已经考虑并完善了这块内容,所以你可以直接借助消息中间件提

供的方法来解决.

比如 rabbitMQ,提供了事务机制,你可以在消息发送前提交事务,如果发送失败会自动回滚.

// 开启事务

channel.txSelect

try {

// 这里发送消息

} catch (Exception e) {

channel.txRollback

// 这里再次重发这条消息

}

// 提交事务

channel.txCommit

但这样会比较耗性能,所以更推荐的做法是使用 rabbitmq 提供的 confirm 机制.confirm 机制是异步的,

在消费者收到生产者发送的消息后会回调 ack,如果消费者接收失败会回调 nack 接口.

要想真正做到万无一失,我们不仅需要对 Message 进行持久化,还需要对 Exchange,Queue 也进行持久

化,而 rabbitMQ 提供了这些持久化机制,因此使用一款好的消息中间件就可以很好的解决消息丢失问

题.

当然除了 rabbitMQ,kafka 也有相应的解决方案,就不细说了(主要是不会).