分布式服务接口请求顺序性保证
2023-04-18 14:04:54 时间
1 问题
服务A调用服务B,先插入再删除。俩请求过去了,落在不同机器上,可能插入请求因为某些原因执行慢一些,导致删除请求先执行了,此时因为没数据所以啥效果也没有;结果这个时候插入请求过来了,好,数据插入进去。
本该先插入再删除,这条数据应该没了,结果现在先删除再插入,数据还存在。
建议从业务逻辑上最好设计的这个系统不需要这种顺序性的保证,一旦引入顺序性保障,会导致系统复杂度上升,而且会带来效率低下,热点数据压力过大等问题。
2 方案
2.1 一致性hash+内存队列
将比如某个订单id对应的请求都给分发到某机器,在那个机器上因为可能还是多线程并发执行,你得立即将某个订单id对应的请求扔一个内存队列,强制排队,确保顺序性。
但这样后续问题很多,比如某订单对应请求特别多,造成某台机器成热点怎么办?解决这些问题又要开启后续一连串的复杂技术方案。
2.2 分布式锁
使用基于zk的分布式锁,实现接口调用的强顺序性。
服务A发送的三个有序请求请求1、2、3,依次发到MQ,然后服务B的多个实例从MQ消费。假如分别是三个实例拿到1、2、3三个请求,则当请求执行时需从zk获取锁,才能执行。所以此时A还要指明这三个请求的执行顺序,即seq=1、2、3,服务B才知道执行顺序。
这时三个请求都来获取锁:
- 如请求3先获取到锁,然后看Redis这个list是否有比自己小的序号,有(1、2)则释放锁
- 然后若请求1拿到锁,也去Redis判断是不是有比自己小的序号,无,就能执行请求1,然后从Redis的list里删掉该序号
依次同理获取锁 =》判断是否有更小的序号 =》删除Redis里的序号,来保证接口顺序性。
相关文章
- 直接在代码里面对list集合进行分页
- .NET Framework 4.5新特性详解
- 大数据的简要介绍
- 大数据的由来
- 高斯混合模型的自然梯度变量推理
- timing-wheel 仿Kafka实现的时间轮算法
- 使用Navicat软件连接自建数据库(Linux系统)
- 那一天,我被Redis主从架构支配的恐惧
- Redis 深入了解键的过期时间
- C#使用委托调用实现用户端等待闪屏
- 基于流计算 Oceanus 和 Elasticsearch Service 构建百亿级实时监控系统
- GRAND | 转录调控网络预测数据库
- JFreeChart API中文文档
- 临床相关突变查询数据库
- TIGER | 人类胰岛基因变化查询数据库
- 视频边缘计算网关EasyNVR在视频整体监控解决方案中的应用分析
- Apache Arrow - 大数据在数据湖后的下一个风向标
- 常见的电商数据指标体系
- AKShare-艺人数据-艺人流量价值
- MySQL中多表联合查询与子查询的这些区别,你可能不知道!