如何保证消息消费的幂等性
面试题
如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？
面试官心理分析
其实这是很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑会不会重复消费？能不能避
免重复消费？或者重复消费了也别造成系统异常可以吗？这个是 MQ 领域的基本问题，其实本质上还是问你使用消息
队列如何保证幂等性，这个是你架构里要考虑的一个问题。
面试题剖析
回答这个问题，首先你别听到重复消息这个事儿，就一无所知吧，你先大概说一说可能会有哪些重复消费的问题。
首先，比如 RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题，正常。因为这问题通常不是 MQ 自
己保证的，是由我们开发来保证的。挑一个 Kafka 来举个例子，说说怎么重复消费吧。
Kafka 实际上有个 offset 的概念，就是每个消息写进去，都有一个 offset，代表消息的序号，然后 consumer 消费了
数据之后，每隔一段时间（定时定期），会把自己消费过的消息的 offset 提交一下，表示“我已经消费过了，下次我要
是重启啥的，你就让我继续从上次消费到的 offset 来继续消费吧”。
但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启了，如果碰到点着急的，直
接 kill 进程了，再重启。这会导致 consumer 有些消息处理了，但是没来得及提交 offset，尴尬了。重启之后，少数
消息会再次消费一次。
举个栗子。
有这么个场景。数据 1/2/3 依次进入 kafka，kafka 会给这三条数据每条分配一个 offset，代表这条数据的序号，我们
就假设分配的 offset 依次是 152/153/154。消费者从 kafka 去消费的时候，也是按照这个顺序去消费。假如当消费者
消费了 offset=153 的这条数据，刚准备去提交 offset 到 zookeeper，此时消费者进程被重启了。那么此时消费过的数
据 1/2 的 offset 并没有提交，kafka 也就不知道你已经消费了 offset=153 这条数据。那么重启之后，消费者会找 kafka
说，嘿，哥儿们，你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。由于之前的 offset 没有提交
成功，那么数据 1/2 会再次传过来，如果此时消费者没有去重的话，那么就会导致重复消费。
如果消费者干的事儿是拿一条数据就往数据库里写一条，会导致说，你可能就把
数据 1/2 在数据库里插入了 2 次，那么数据就错啦。
其实重复消费不可怕，可怕的是你没考虑到重复消费之后，怎么保证幂等性。
举个例子吧。假设你有个系统，消费一条消息就往数据库里插入一条数据，要是
你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到
第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保
留了一条数据，从而保证了数据的正确性。
一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性。
幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对
应的数据是不会改变的，不能出错。
所以第二个问题来了，怎么保证消息队列消费的幂等性？
其实还是得结合业务来思考，我这里给几个思路：
•
比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就
别插入了，update 一下好吧。
•
比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。
•
比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每
条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，
然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之
前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果
消费过了，那你就别处理了，保证别重复处理相同的消息即可。
•
比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一
键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。
当然，如何保证 MQ 的消费是幂等性的，需要结合具体的业务来看。
报表开发面试问题
报表开发面试问题面试题模块介绍：一、Java 基础JDK 和JRE 有什么区别？== 和equals 的区别是什么？两个对象的hashCode()相同，则equals()也一定为true，对吗？final 在java 中有什么作用？java 中的Math.round(-1.5) 等于多少？String 属于基础的数据类型吗？java 中操作字符串都有哪些类？它们之间有什么区别？String str="i"与String str=new String(“i”)一样吗？如何将字符串反转？String 类的常用方法都有那些？抽象类必须要有抽象方法吗？普通类和抽象类有哪些区别？抽象类能使用final 修饰吗？接口和抽象类有什么区别？java 中IO 流分为几种？BIO、NIO、AIO 有什么区别？Files的常用方法都有哪些？二、容器java 容器都有哪些？Collection 和Collections 有什么区别？List、Set、Map 之间的区别是什么？HashMap 和Hashtable 有什么区别？如何决定使用HashMap 还是TreeMap？说一下HashMap 的实现原理？说一下HashSet 的实现原理？ArrayList 和LinkedList 的区别是什么？如何实现数组和List 之间的转换？ArrayList 和Vector 的区别是什么？Array 和ArrayList 有何区别？在Queue 中poll()和remove()有什么区别？哪些集合类是线程安全的？迭代器Iterator 是什么？Iterator 怎么使用？有什么特点？Iterator 和ListIterator 有什么区别？怎么确保一个集合不能被修改？三、多线程并行和并发有什么区别？线程和进程的区别？守护线程是什么？创建线程有哪几种方式？说一下runnable 和callable 有什么区别？线程有哪些状态？sleep() 和wait() 有什么区别？notify()和notifyAll()有什么区别？线程的run()和start()有什么区别？创建线程池有哪几种方式？线程池都有哪些状态？线程池中submit()和execute()方法有什么区别？在java 程序中怎么保证多线程的运行安全？多线程锁的升级原理是什么？什么是死锁？怎么防止死锁？ThreadLocal 是什么？有哪些使用场景？说一下synchronized 底层实现原理？synchronized 和volatile 的区别是什么？synchronized 和Lock 有什么区别？synchronized 和ReentrantLock 区别是什么？说一下atomic 的原理？四、反射什么是反射？什么是java 序列化？什么情况下需要序列化？动态代理是什么？有哪些应用？怎么实现动态代理？五、对象拷贝为什么要使用克隆？如何实现对象克隆？深拷贝和浅拷贝区别是什么？六、Java Webjsp 和servlet 有什么区别？jsp 有哪些内置对象？作用分别是什么？说一下jsp 的4 种作用域？session 和cookie 有什么区别？说一下session 的工作原理？如果客户端禁止cookie 能实现session 还能用吗？spring mvc 和struts 的区别是什么？如何避免sql 注入？什么是XSS 攻击，如何避免？什么是CSRF 攻击，如何避免？七、异常hrow 和throws 的区别？final、finally、finalize 有什么区别？try-catch-finally 中哪个部分可以省略？try-catch-finally 中，如果catch 中return 了，finally 还会执行吗？常见的异常类有哪些？八、网络http 响应码301 和302 代表的是什么？有什么区别？forward 和redirect 的区别？简述tcp 和udp的区别？tcp 为什么要三次握手，两次不行吗？为什么？说一下tcp 粘包是怎么产生的？OSI 的七层模型都有哪些？get 和post 请求有哪些区别？如何实现跨域？说一下JSONP 实现原理？九、设计模式说一下你熟悉的设计模式？简单工厂和抽象工厂有什么区别？十、Spring/Spring MVC什么是spring?Spring的俩大核心概念Spring框架的设计目标，设计理念，和核心是什么Spring由哪些模块组成？Spring 框架中都用到了哪些设计模式？使用Spring 有哪些方式？spring 支持几种bean 的作用域？spring 自动装配bean 有哪些方式？spring 事务实现方式有哪些？什么是Spring MVC？简单介绍下你对Spring MVC的理解？Spring MVC的主要组件？什么是Spring MVC框架的控制器？MVC是什么？MVC设计模式的好处有哪些Spring MVC常用的注解有哪些？Spring MVC与Struts2区别Spring MVC怎么样设定重定向和转发的？Spring MVC的异常处理？什么是Spring MVC框架的控制器？说一下spring mvc 运行流程？spring mvc 有哪些组件？@RequestMapping 的作用是什么@Autowired 的作用是什么？十一、Spring Boot/Spring Cloud什么是spring boot？为什么要用spring boot？spring boot 核心配置文件是什么？spring boot 配置文件有哪几种类型？它们有什么区别？spring boot 有哪些方式可以实现热部署？jpa 和hibernate 有什么区别？什么是spring cloud？spring cloud 断路器的作用是什么？spring cloud 的核心组件有哪些？十二、Hibernate为什么要使用hibernate？什么是ORM 框架？hibernate 中如何在控制台查看打印的sql 语句？hibernate 有几种查询方式？hibernate 实体类可以被定义为final 吗？在hibernate 中使用Integer 和int 做映射有什么区别？hibernate 是如何工作的？get()和load()的区别？说一下hibernate 的缓存机制？hibernate 对象有哪些状态？在hibernate 中getCurrentSession 和openSession 的区别是什么？hibernate 实体类必须要有无参构造函数吗？为什么？十三、MybatisMyBatis是什么？Mybatis优缺点Hibernate 和MyBatis 的区别为什么说Mybatis是半自动ORM映射工具？它与全自动的区别在哪里？传统JDBC开发存在什么问题？JDBC编程有哪些不足之处，MyBatis是如何解决的？MyBatis和Hibernate的适用场景?MyBatis编程步骤是什么样的？请说说MyBatis的工作原理MyBatis的功能架构是怎样的MyBatis的框架架构设计是怎么样的什么是DBMSMybatis都有哪些Executor执行器？它们之间的区别是什么？Mybatis中如何指定使用哪一种Executor执行器？Mybatis是否支持延迟加载？如果支持，它的实现原理是什么？Mybatis如何执行批量操作当实体类中的属性名和表中的字段名不一样，怎么办Mapper 编写有哪几种方式？什么是MyBatis的接口绑定？有哪些实现方式？使用MyBatis的mapper接口调用时有哪些要求？Mybatis是如何将sql执行结果封装为目标对象并返回的？都有哪些映射形式？简述Mybatis的Xml映射文件和Mybatis内部数据结构之间的映射关系？Xml映射文件中，除了常见的select|insert|updae|delete标签之外，还有哪些标签？Mybatis是否可以映射Enum枚举类？简述Mybatis的插件运行原理，以及如何编写一个插件。
面试题：如何保证消息不丢失？处理重复消息？消息有序性？消息堆积处理？
⾯试题：如何保证消息不丢失？处理重复消息？消息有序性？消息堆积处理？核⼼点有很多，为了更贴合实际场景，我从常见的⾯试问题⼊⼿：如何保证消息不丢失？如何处理重复消息？如何保证消息的有序性？如何处理消息堆积？当然在剖析这⼏个问题之前需要简单的介绍下什么是消息队列，消息队列常见的⼀些基本术语和概念。
接下来进⼊正⽂。
什么是消息队列来看看维基百科怎么说的，顺带学学英语这波不亏：In computer science, message queues and mailboxes are software-engineeringcomponents typically used for inter-process communication (IPC), or for inter-threadcommunication within the same process. They use a queue for messaging – thepassing of control or of content. Group communication systems provide similarkinds of functionality.翻译⼀下：在计算机科学领域，消息队列和邮箱都是软件⼯程组件，通常⽤于进程间或同⼀进程内的线程通信。
它们通过队列来传递消息-传递控制信息或内容，群组通信系统提供类似的功能。
简单的概括下上⾯的定义：消息队列就是⼀个使⽤队列来通信的组件。
上⾯的定义没有错，但就现在⽽⾔我们⽇常所说的消息队列常常指代的是消息中间件，它的存在不仅仅只是为了通信这个问题。
为什么需要消息队列从本质上来说是因为互联⽹的快速发展，业务不断扩张，促使技术架构需要不断的演进。
从以前的单体架构到现在的微服务架构，成百上千的服务之间相互调⽤和依赖。
从互联⽹初期⼀个服务器上有 100 个在线⽤户已经很了不得，到现在坐拥10亿⽇活的微信。
java幂等性的解决方案
java幂等性的解决⽅案⼀、幂等性概念在编程中.⼀个幂等操作的特点是其任意多次执⾏所产⽣的影响均与⼀次执⾏的影响相同。
幂等函数，或幂等⽅法，是指可以使⽤相同参数重复执⾏，并能获得相同结果的函数。
这些函数不会影响系统状态，也不⽤担⼼重复执⾏会对系统造成改变。
例如，“getUsername()和setTrue()”函数就是⼀个幂等函数. 更复杂的操作幂等保证是利⽤唯⼀交易号(流⽔号)实现.我的理解：幂等就是⼀个操作，不论执⾏多少次，产⽣的效果和返回的结果都是⼀样的。
⼆、幂等性场景1、查询操作：查询⼀次和查询多次，在数据不变的情况下，查询结果是⼀样的。
select是天然的幂等操作；2、删除操作：删除操作也是幂等的，删除⼀次和多次删除都是把数据删除。
(注意可能返回结果不⼀样，删除的数据不存在，返回0，删除的数据多条，返回结果多个) ；3、唯⼀索引：防⽌新增脏数据。
⽐如：⽀付宝的资⾦账户，⽀付宝也有⽤户账户，每个⽤户只能有⼀个资⾦账户，怎么防⽌给⽤户创建资⾦账户多个，那么给资⾦账户表中的⽤户ID加唯⼀索引，所以⼀个⽤户新增成功⼀个资⾦账户记录。
要点：唯⼀索引或唯⼀组合索引来防⽌新增数据存在脏数据（当表存在唯⼀索引，并发时新增报错时，再查询⼀次就可以了，数据应该已经存在了，返回结果即可）；4、token机制：防⽌页⾯重复提交。
原理上通过session token来实现的(也可以通过redis来实现)。
当客户端请求页⾯时，服务器会⽣成⼀个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（⼀般通过构造hidden表单）。
下次客户端提交请求时，Token会随着表单⼀起提交到服务器端。
服务器端第⼀次验证相同过后，会将session中的Token值更新下，若⽤户重复提交，第⼆次的验证判断将失败，因为⽤户提交的表单中的Token没变，但服务器端session中Token已经改变了。
mq消息丢失的解决方案
mq消息丢失的解决方案mq消息丢失可有点头疼呢，不过有不少办法来解决哦。
一、生产者端。
1. 事务机制（如果支持的话）就好比你去银行转账，要确保这个操作完整无缺。
在mq里呢，生产者开启事务，先发送消息到mq，然后执行本地事务，比如更新数据库啥的。
如果本地事务成功了，就提交mq的消息发送；要是本地事务失败了，就回滚mq消息发送。
这样就保证了消息不会因为本地事务失败而莫名其妙地丢失。
不过这个有个小缺点，就是会影响性能，因为开启事务嘛，就像你做事要多走几个流程，肯定会慢一点。
2. 消息确认机制（确认回调）这就像是你寄快递，得知道快递有没有被快递站接收。
生产者发送消息后，mq服务器收到消息会给生产者一个确认回执。
如果生产者没收到这个回执，就认为消息可能丢失了，然后可以重新发送消息。
像有些mq框架（比如RabbitMQ）就有这种机制。
你可以在代码里设置好这个确认回调函数，当消息成功发送到mq的交换机或者队列的时候，回调函数就会被触发，这样你就心里有数，消息没丢啦。
3. 消息持久化。
想象你要保存一份很重要的文件，你得把它存到一个安全可靠的地方。
对于mq消息来说，把消息设置为持久化。
在生产者端，发送消息的时候要标记这个消息是需要持久化存储的。
这样就算mq服务器突然宕机重启，消息也不会丢，因为它已经被安全地存储起来了。
但是呢，持久化操作也会稍微影响性能，就像你把文件存到加密的保险柜里，肯定比随手放桌上要慢一点。
二、mq服务器端。
1. 集群部署。
这就像是你有好几个小伙伴一起干活。
mq服务器搞成集群模式，多个节点相互备份。
如果一个节点挂了，其他节点还能继续工作，消息也不会丢失。
比如说RabbitMQ的集群模式，不同的节点之间会互相复制消息，保证消息的可靠性。
不过集群部署也有一些配置上的麻烦事，就像你要让几个小伙伴配合得很好，得好好商量分工一样。
2. 定期备份数据。
这就像你定期给电脑里重要的文件做备份一样。
mq服务器要定期把消息数据备份到其他存储介质上，比如磁盘阵列或者云存储。
幂等性的实现方案
幂等性的实现⽅案我们实际系统中有很多操作，是不管做多少次，都应该产⽣⼀样的效果或返回⼀样的结果的。
幂等性的概念幂等（Idempotent）是⼀个数学与计算机学的概念，常见于抽象代数中。
f(n) = 1^n // ⽆论n等于多少，f(n)永远值等于1在编程中，⼀个幂等操作的特点是其任意多次执⾏所产⽣的影响均与⼀次执⾏的影响相同。
幂等函数或幂等⽅法是指可以使⽤相同参数重复执⾏，并能获得相同结果的函数/⽅法。
这些函数/⽅法不会影响系统状态，因此不⽤担⼼重复执⾏会对系统造成改变。
例如：1.前端重复提交选中的数据，后台也只会产⽣对应这个数据的⼀个反应结果。
2.⽤户发起⼀笔付款请求，就应该只扣⽤户⼀次钱，即使遇到⽹络重发或系统bug重发请求，也应该之扣⼀次钱。
3.发送验证短息也应该只发⼀次，同样的验证短信不应该发送多次。
4.创建业务订单，⼀个业务请求只能创建⼀个业务订单，创建多个就会出⼤问题。
这些等等很多的业务逻辑都需要幂等的特性来⽀持。
简单来理解就是，幂等就是⼀个操作，这个操作不管执⾏多少次，产⽣的效果和返回的结果都是⼀样的。
⽐如说有⼀个getOne()函数，⽆论执⾏这个函数多少次，它返回的都是1，这时就可以说它是⼀个幂等函数。
幂等性的技术⽅案1.查询操作查询⼀次和查询多次，在数据不变的情况下，查询结果都是⼀样的，select是天然的幂等操作。
2.删除操作删除操作也是幂等的，删除⼀次和删除多次都是把数据删除。
3.建⽴唯⼀索引，防⽌新增脏数据当表存在唯⼀索引，并发时新增重复记录就会报错，那么这时候就查询已存在的记录并返回即可。
4.Token机制，防⽌页⾯重复提交页⾯数据只能够提交⼀次，但是由于出现重复点击或者⽹络重发或Nginx重发等情况导致数据被重复提交的情况下，可以采⽤Token+Redis（Redis是单线程的，处理需要排队）的解决⽅案。
处理的流程是，在数据提交前要向服务器申请带有有效时间的Token，然后Token放到Redis或JVM内存中，当数据正式提交到后台要校验Token并删除Token。
互联网大厂设计面试题目(3篇)
第1篇一、系统设计题1. 题目：设计一个电商平台的商品搜索系统。
描述：电商平台的商品搜索系统需要支持海量商品的快速检索，同时保证查询结果的准确性和相关性。
请设计一个商品搜索系统，并说明其设计思路。
要求：（1）阐述商品搜索系统的整体架构，包括前端、后端、数据库等；（2）设计商品索引结构，并说明其设计原理；（3）设计查询算法，包括查询结果的排序和分页；（4）考虑系统的高可用性和扩展性，说明如何应对海量数据和并发请求；（5）设计系统性能监控和调优方案。
2. 题目：设计一个分布式存储系统。
描述：设计一个分布式存储系统，要求支持海量数据的存储和高效访问。
请阐述设计思路，并说明如何实现以下功能：（1）数据分片和分布式存储；（2）数据一致性和容错性；（3）数据备份和恢复；（4）数据读写分离；（5）系统性能监控和调优。
3. 题目：设计一个社交平台的推荐系统。
描述：设计一个社交平台的推荐系统，要求根据用户兴趣和社交关系推荐相关内容。
请阐述设计思路，并说明如何实现以下功能：（1）用户画像和兴趣建模；（2）推荐算法设计，包括协同过滤、内容推荐等；（3）推荐结果排序和过滤；（4）系统性能优化和扩展性设计；（5）数据清洗和预处理。
4. 题目：设计一个分布式消息队列系统。
描述：设计一个分布式消息队列系统，要求支持高吞吐量和低延迟的消息传输。
请阐述设计思路，并说明如何实现以下功能：（1）消息的生产和消费；（2）消息的可靠传输和顺序保证；（3）消息的持久化和备份；（4）系统的高可用性和扩展性设计；（5）消息队列的监控和性能优化。
二、算法题1. 题目：给定一个整数数组，找出数组中的最大子序和。
描述：给定一个整数数组，找出数组中的最大子序和。
子序和定义为连续子数组中所有元素的和。
示例：输入：[−2,1,−3,4,−1,2,1,−5,4]，输出：6（连续子数组[4,−1,2,1]的最大子序和为6）。
要求：（1）使用动态规划的方法实现；（2）分析算法的时间复杂度和空间复杂度；（3）优化算法，提高执行效率。
rocketmqtemplate最佳实践 -回复
rocketmqtemplate最佳实践-回复RocketMQ 是阿里巴巴开源的一款分布式消息中间件，具备高性能、高可靠、高扩展性的特点，被广泛应用于各种分布式场景中。
在使用RocketMQ 进行消息发送和消费时，Spring 提供了一个封装好的RocketMQTemplate 工具类，非常方便实用。
本文将结合实际案例，一步一步解析RocketMQTemplate 的最佳实践，帮助读者快速上手并有效使用。
一、RocketMQTemplate 的简介RocketMQTemplate 是Spring Framework 针对RocketMQ 消息中间件封装的模板类，提供了丰富的API用于发送和接收消息。
通过在Spring 配置文件中配置Bean，我们可以直接在代码中注入RocketMQTemplate 对象，进行消息发送和接收的操作。
二、配置RocketMQTemplate使用RocketMQTemplate 首先需要在Spring 的配置文件中进行相应的配置。
以下是一个简单的配置示例：xml<bean id="defaultMQProducer"class="org.apache.rocketmq.client.producer.DefaultMQProducer"> <property name="producerGroup"value="your_producer_group" /><property name="namesrvAddr" value="your_namesrv_addr" /><! 其他属性设置></bean><bean id="rocketMQTemplate"class="org.springframework.boot.autoconfigure.jms.JmsAutoConfi guration"><property name="defaultProducer" ref="defaultMQProducer" /><! 其他配置项></bean>其中，defaultMQProducer 是RocketMQ 的生产者对象，作为RocketMQTemplate 的依赖注入。
可靠消息最终一致性【本地消息表、RocketMQ事务消息方案】
可靠消息最终⼀致性【本地消息表、RocketMQ事务消息⽅案】⼀、可靠消息最终⼀致性事务概述事务发起⽅（消息⽣产⽅）将消息发给消息中间件，事务参与⽅从消息中间件接收消息，事务参与⽅（消息消费⽅）和消息中间件之间都是通过⽹络通信，由于⽹络通信的不确定性会导致分布式事务问题。
因此可靠消息最终⼀致性⽅案要解决以下⼏个问题：【1】本地事务与消息发送的原⼦性问题：事务发起⽅在本地事务执⾏成功后消息必须发出去，否则就丢弃消息。
即实现本地事务和消息发送的原⼦性，要么都成功，要么都失败。
本地事务与消息发送的原⼦性问题是实现可靠消息最终⼀致性⽅案的关键问题。
先来尝试下这种操作，先发送消息，再操作数据库：这种情况下⽆法保证数据库操作与发送消息的⼀致性，因为可能发送消息成功，据库操作失败。
1 begin transaction；2//1.发送MQ3//2.数据库操作4 commit transation;第⼆种⽅案，先进⾏数据库操作，再发送消息：这种情况下貌似没有问题，如果发送 MQ消息失败，就会抛出异常，导致数据库事务回滚。
但如果是超时异常，数据库回滚，但 MQ其实已经正常发送了，同样会导致不⼀致。
1 begin transaction；2//1.数据库操作3//2.发送MQ4 commit transation;【2】事务参与⽅接收消息的可靠性：事务参与⽅必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息。
【3】消息重复消费的问题：由于步骤2的存在，若某⼀个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。
要解决消息重复消费的问题就要实现事务参与⽅的⽅法幂等性。
⼆、解决⽅案【本地消息表⽅案】1 begin transaction；2//1.新增⽤户3//2.存储积分消息⽇志4 commit transation;【2】定时任务扫描⽇志：如何保证将消息发送给消息队列呢？经过第⼀步消息已经写到消息⽇志表中，可以启动独⽴的线程，定时对消息⽇志表中的消息进⾏扫描并发送⾄消息中间件，在消息中间件反馈发送成功后删除该消息⽇志，否则等待定时任务下⼀周期重试。
如何实现接口幂等
如何实现接口幂等一、背景在软件开发的过程中，接口的幂等性是一个关键的设计原则，它能够确保同一操作无论执行多少次，系统的状态都保持一致。
作为一名学生，在软件工程的实践课程中，我负责研究和实现接口的幂等性技术，以下是我的工作总结。
二、幂等概念理解在开始技术实现之前，我首先深入研究了幂等性的概念。
幂等性指的是对于同一输入，无论执行多少次，系统的状态都保持不变。
在接口设计中，这意味着无论客户端发送多少次相同的请求，服务器端的处理结果都应该是相同的，并且不会引发副作用。
三、技术实现策略1. 唯一标识识别：为了实现接口的幂等性，我首先为每个请求生成一个唯一的标识符（如Token）。
这样，即使客户端多次发送相同的请求，服务器也能够识别出这是重复的请求，并避免重复处理。
2. 状态机控制：我采用了状态机的思想，确保接口在不同状态下对相同请求的处理结果是一致的。
通过状态机的转换，可以避免由于接口状态变化导致的处理结果不一致。
3. 数据库事务处理：在处理涉及到数据库操作的接口时，我使用了数据库事务来保证操作的原子性。
这样，即使在多次请求的情况下，数据库的状态也能够保持一致。
4、幂等性检查: 在接收到请求时，服务器可以检查请求的参数或者内容，判断是否已经处理过该请求。
如果已经处理过，则可以直接返回之前的结果，而不是再次处理。
5、幂等性标记: 对于一些无法避免的非幂等操作，可以在请求中添加一个幂等性标记，告诉服务器该请求是幂等的。
服务器可以根据这个标记来确保操作的幂等性。
四、系统集成实践在实际的项目中，我将幂等性技术集成到了接口的设计和实现中。
通过编写测试用例和进行实际的环境测试，我验证了幂等性技术的有效性和稳定性。
在实际运行中，系统能够正确识别和处理重复的请求，保证了接口的稳定性和可靠性。
五、问题与挑战在实现幂等性技术的过程中，我遇到了一些问题和挑战。
例如，如何生成全局唯一的请求标识符、如何处理并发请求中的幂等性保证、以及如何平衡系统性能和幂等性保证等。
rabbitmq basicack机制
rabbitmq basicack机制RabbitMQ是一种被广泛使用的消息队列中间件，具有高可靠性和可扩展性。
BasicAck机制是RabbitMQ中重要的确认机制之一，用于确保消息已被正确处理并从队列中删除。
本文将详细介绍RabbitMQ BasicAck机制的原理、使用方法和相关注意事项。
一、BasicAck机制的原理BasicAck（Basic Acknowledge）机制是RabbitMQ中消费者与消息队列之间的一种消息确认机制。
在默认情况下，当消费者接收到消息后，消息会被认为是自动确认的，即消费者处理完消息后，消息会立即从队列中删除。
然而，这种自动确认机制存在不确定性，可能导致消息丢失或重复消费的问题。
为了解决上述问题，RabbitMQ引入了BasicAck机制。
消费者处理完消息后，会通过显式发送BasicAck信号来告知RabbitMQ该消息已被正确处理。
RabbitMQ根据收到的BasicAck信号来判断消息是否成功处理，若成功处理，则将消息从队列中删除，若未收到BasicAck信号或消息处理失败，则将消息重新发送给其他消费者或将消息放回队列以供重新处理。
二、BasicAck机制的使用方法在RabbitMQ中，要使用BasicAck机制，需要注意以下几点：1. 消息消费模式：RabbitMQ提供了两种消息消费模式：自动确认模式（auto_ack=true）和手动确认模式（auto_ack=false）。
在手动确认模式下，消费者需要显式地调用BasicAck方法进行消息确认。
2. BasicAck方法的调用方式：BasicAck方法的调用可以在消费者处理消息后的任意时刻进行，只要消费者确保消息处理完成并准备好发送确认信号即可。
调用BasicAck方法时，需要指定一个Delivery Tag参数，该参数用于标识消息的唯一性。
3. BasicAck方法的注意事项：在调用BasicAck方法时，需要注意以下几点：- BasicAck方法是非阻塞的，不会等待消息处理完再返回；- BasicAck方法只接受一个参数，即Delivery Tag；- BasicAck方法针对的是当前信道中的消息，只能确认当前信道中的消息。