dreambyday

我们考虑要不要做幂等的位置一般是MQ消费者、RPC、HTTP接口。消费者消费消息可以看做源源不断的请求调用消费者接口。因此本文将幂等位置统称为接口，探讨接口如何提供幂等能力。一次和多次执行的结果相同。但并非所有业务场景都需要保证幂等性。因为保证幂等性需要额外的开销天然幂等场景：比如查询、删除、更新不幂等场景：插入、自增/减（update xxx set a = a+1）如果一个接口涉及到了不幂等场景，那么就要考虑做幂等了。

分布式场景下，一张表可能分散到多个数据结点上。主键自增的方案难以保证在多张表主键唯一，在分布式场景下无法适用。因此需要一些分布式ID的解决方案。分布式ID需要有几个特点：全局唯一（必要）：在多个库的主键放在一起也不会重复有序（必要）：避免频繁触发索引重建信息安全：ID连续，可以根据订单编号计算一天的单量，造成信息泄露包含时间戳：能够快速根据ID得知生成时间下面几种方案按推荐顺序排序，越推荐使用越靠前。优点缺点uuid实现简单连续性差，作为主键每次新增数据都会触发索引重建。

多台机器的服务组成一个系统，运行不同的服务通过缩短单个任务的执行时间提高效率**微服务：**一个系统拆成多个服务，每个服务都可以独立运行（不需要多台机器，可以部署在单机器）**集中式：**整个系统部署在一台机器上。