教育网站建设,莱芜找工作网站,报社网站开发做什么,大型门户网站建设企业1. 如何防⽌消息丢失
在生产者层面#xff0c;我们有个ack参数确认机制
设置成-1#xff0c;也就是副本全部同步了leader才发送ack#xff0c;这样确保leader和副本挂掉只剩一个还能
保证消息不丢失 消费者#xff1a;
把⾃动提交改成⼿动提交 2. 如何防⽌重复消费
在…1. 如何防⽌消息丢失
在生产者层面我们有个ack参数确认机制
设置成-1也就是副本全部同步了leader才发送ack这样确保leader和副本挂掉只剩一个还能
保证消息不丢失 消费者
把⾃动提交改成⼿动提交 2. 如何防⽌重复消费
在防⽌消息丢失的⽅案中如果⽣产者发送完消息后因为⽹络抖动没有收到ack但实际上broker已经收到了。此时⽣产者会进⾏重试于是broker就会收到多条相同的消息⽽造成消费者的重复消费。 怎么解决
⽣产者关闭重试会造成丢消息不建议 消费者解决⾮幂等性消费问题 所谓的幂等性多次访问的结果是⼀样的。对于rest的请求get幂等、post⾮幂 等、put幂等、delete幂等 解决⽅案 1.在数据库中创建联合主键防⽌相同的主键 创建出多条记录 假设我们有一个电商平台其中有一个订单系统需要处理用户的订单。在这个业务场景下我们可以使用联合主键来避免重复消费。
假设订单系统中的订单数据存储在数据库表中表结构包含以下字段订单ID、用户ID、商品ID、订单状态等。
订单系统通过消息队列将订单数据发送给其他系统进行处理比如库存系统和物流系统。当订单系统发送一个订单消息给库存系统时可能由于网络抖动或其他原因导致消息发送失败此时订单系统会进行重试。
然而由于某些原因如网络延迟、重试机制设计等重试过程中可能会导致重复发送相同的订单消息到库存系统。如果没有相应的方式来防止重复消费库存系统可能会处理同一订单多次导致库存错误或其他问题。
为了解决这个问题我们可以在订单数据表中创建一个联合主键由订单ID、用户ID和商品ID组成。这样当订单系统接收到一个新订单时首先检查数据库中是否已存在具有相同联合主键的记录。
如果存在重复记录订单系统可以判断该订单消息已经被处理过并选择跳过重复消息的处理。如果不存在重复记录则将该订单数据插入数据库并发送消息给库存系统进行处理。
通过使用联合主键我们可以确保在订单系统中防止重复消费的问题。即使在订单系统进行重试时库存系统只会处理首次收到的订单消息避免了重复消费产生的问题
2.使⽤分布式锁以业务id为锁。保证只有⼀条记录能够创建成功
假设我们有一个在线活动报名系统用户可以通过该系统报名参加各种活动。在这个业务场景中我们可以使用分布式锁来保证同一个用户只能成功报名一次活动。
假设活动报名系统中的报名记录存储在数据库表中表结构包含以下字段报名ID、用户ID、活动ID、报名状态等。
当用户尝试报名一个活动时系统需要进行以下操作
检查该用户是否已经报名了该活动。如果用户已经报名了该活动则返回相应的提示阻止用户重复报名。如果用户未报名该活动则将报名信息插入数据库并完成报名流程。
在这个场景下我们可以使用分布式锁来保证同一个用户只能成功报名一次活动。以用户ID作为锁的key当用户尝试报名活动时先尝试获取该用户的锁。
如果获取到了锁表示该用户尚未报名该活动可以继续执行报名操作并将用户ID作为锁的值存储在分布式锁中。
如果未能获取到锁表示该用户已经报名了该活动可以给用户返回相应的提示阻止用户重复报名。 3. 如何做到消息的顺序消费
⽣产者保证消息按顺序消费且消息不丢失——使⽤同步的发送ack设置成⾮0的值。消费者主题只能设置⼀个分区消费组中只能有⼀个消费者
kafka的顺序消费使⽤场景不多因为牺牲掉了性能但是⽐如rocketmq在这⼀块有专⻔的功能已设计好。 4. 如何解决消息积压问题 4.1 消息积压问题的出现 消息的消费者的消费速度远赶不上⽣产者的⽣产消息的速度导致kafka中有⼤量的数据没有被消费。随着没有被消费的数据堆积越多消费者寻址的性能会越来越差最后导致整个kafka对外提供的服务的性能很差从⽽造成其他服务也访问速度变慢造成服务雪崩。 4.2 消息积压的解决⽅案 在这个消费者中使⽤多线程充分利⽤机器的性能进⾏消费消息。 通过业务的架构设计提升业务层⾯消费的性能。 创建多个消费组多个消费者部署到其他机器上⼀起消费提⾼消费者的消费速度 创建⼀个消费者该消费者在kafka另建⼀个主题配上多个分区多个分区再配上多个 消费者。该消费者将poll下来的消息不进⾏消费直接转发到新建的主题上。此时新 的主题的多个分区的多个消费者就开始⼀起消费了。——不常⽤
5. 实现延时队列的效果
5.1 应用场景
订单创建后超过30分钟没有⽀付则需要取消订单这种场景可以通过延时队列来实现
5.2 具体方案 kafka中创建创建相应的主题 消费者消费该主题的消息轮询 消费者消费消息时判断消息的创建时间和当前时间是否超过30分钟前提是订单没⽀付 如果是去数据库中修改订单状态为已取消。 如果否记录当前消息的offset并不再继续消费之后的消息。等待1分钟后再次向kafka拉取该offset及之后的消息继续进⾏判断以此反复。
