mf97532的博客

上了微服务之后，很多原本很简单的问题现在都变复杂了，例如全局 ID 这事！最近工作中刚好用到这块内容，于是调研了市面上几种常见的全局 ID 生成策略，稍微做了一下对比，供小伙伴们参考。当数据库分库分表之后，原本的主键自增就不方便继续使用了，需要找到一个新的合适的方案。接下来我们一起来捋一捋。

细心的同学会发现，微服务架构中有配置中心和注册中心，Dubbo中也有配置中心和注册中心，而本文讲的Seata也有配置中心和注册中心。其实，并没有区别，各是各的。微服务的配置中心和注册中心你要配置，Dubbo的你也要配置，Seata的配置中心和注册中心你还要配置，尽管它们可能是同一个实例，但那也得各配各的。由于这里导入配置的时候没有-t指定命名空间，即导入到默认命名空间，所以配置里面namespace为空，如果-t指定了特定的命名空间，则server和client端的namespace也要与之对应。

认证和授权这两个概念经常容易被混淆，甚至被互换使用。在RabbitMQ中这是错的，它们是两个独立的概念。可以简单的这样理解，认证就是“识别这个用户是谁”，而授权就是“决定哪些用户不能这么做”。

在支付场景中，支付成功后利用RabbitMQ通知交易服务，更新业务订单状态为已支付。但是大家思考一下，如果这里MQ通知失败，支付服务中支付流水显示支付成功，而交易服务中的订单状态却显示未支付，数据出现了不一致。此时前端发送请求查询支付状态时，肯定是查询交易服务状态，会发现业务订单未支付，而用户自己知道已经支付成功，这就导致用户体验不一致。因此，这里必须尽可能确保MQ消息的可靠性，即：消息应该至少被消费者处理1次该如何确保MQ消息的可靠性？如果真的发送失败，有没有其它的兜底方案？

RabbitMQ是基于Erlang语言开发的开源消息通信中间件，官网地址：接下来，我们就学习它的基本概念和基础用法。多个消费者绑定到一个队列，同一条消息只会被一个消费者处理通过设置prefetch来控制消费者预取的消息数量交换机的作用是什么？接收publisher发送的消息将消息按照规则路由到与之绑定的队列不能缓存消息，路由失败，消息丢失FanoutExchange的会将消息路由到每个绑定的队列描述下Direct交换机与Fanout交换机的差异？

面试官：TCC解决方案是什么？如何解决TCC幂等问题？

CAP定理，又叫布鲁尔定理。指的是：在一个分布式系统中，最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。