精华内容
下载资源
问答
  • 文章目录什么是生产端的可靠性投递生产端可靠性投递的解决方案: 什么是生产端的可靠性投递 生产端要做到可靠性投递,需要以下几点: 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点(Broker)的确认...

    什么是生产端的可靠性投递

    生产端要做到可靠性投递,需要以下几点:

    1. 保障消息的成功发出
    2. 保障MQ节点的成功接收
    3. 发送端收到MQ节点(Broker)的确认应答
    4. 完善消息的补偿机制:也就是上面三个步骤失败了的补偿机制。

    生产端可靠性投递的解决方案:


    • 消息落库,对消息状态进行打标

    在消息发送的时候,把消息持久化到数据库中,然后消息有个状态:比如说,刚发送的时候可能说消息叫做发送中,收到回送响应后把消息状态进行变更,比如说打标为已发送。
    那么对于没有响应的消息,可以进行轮询操作,抓取没有成功的消息进行重新发送,做一个最大努力尝试的次数即可。

    在这里插入图片描述

    • step1:进行数据的入库,包括对业务的入库和对消息的入库,比如说订单服务,包括对订单业务数据的存储(保存订单消息或者创建订单)以及对订单消息的存储。如果这两个持久化操作抛出异常,快速失败即可。
    • step2:producer发送消息给broker。
    • step3:broker应答结果给producer。Confirm Listener异步的去监听Broker回送的这条响应。
    • step4:更新数据库的消息状态,表示确认消息发送成功。
    • step5:使用分布式定时任务去抓取数据库中不成功的消息(一般来讲使用分布式的任务,防止重复抓取)。
    • step6:消息重发,设置重发次数。
    • step7:消息重发次数过多,表明消息投递失败。这时候可以给出一个补偿系统去获取这些消息失败的原因(当然也可以人工去操作)。

    这种方式有个缺点:
    在数据持久化的时候, 需要经过两次磁盘写操作(业务消息入库和消息信息入库)。并且后续需要update。(一般来说不需要事务,事务会造成严重的性能瓶颈)。在高并发场景下,这种解决方案不合适。


    • 消息的延迟投递,做消息的二次确认、回调检查

    这种方式是比较好的可靠性投递机制。这种方式主要是为了减少数据库持久化的操作

    在这里插入图片描述

    • step1:upstream service也就是上游服务(生产端),首先会将业务数据持久化(一般来说不加事务),落库完了之后把消息发到broker。
    • step2:第二条消息是延迟消息投递检查,设置一个消息发送的延迟时间,比如设置5min,延迟5min后发送消息。这里的延迟消息虽然和第一次放松的消息在业务上说的是一个事情,但是投递的队列不是一个队列。
    • step3:downstream service也就是下游服务(消费端),收到消息并处理。
    • step4:下游服务消息处理完成之后,向broker发送一个confirm的消息,这个confirm消息也是一个消息队列。也就是处理成功的消息会被编辑成为一个新的消息投递到broker。
    • step5:callback service也就是回调服务充当了之前的Message DB的角色,回调服务去监听下游服务发送的消息,然后回调服务做消息的持久化服务。
    • step 6:回调服务监听延迟消息的队列,5min后延迟消息发送到该队列,回调服务监听到了该消息,并在Message DB数据库中进行检查,发现DB里收到了这个数据,不需要组任何事情。如果发现没有查到这个message,那么进行一个RPC消息,通知上游再次发送这个消息。

    这里是异步做了消息的持久化操作,这个回调服务就相当于一个补偿服务,在主流程中减少了一次数据持久化操作,由回调服务实现。

    消费端幂等性保障

    rabbitmq消费端一般不需要去做可靠性保障,因为一般来说broker使用ack能够保障消息被消费(但是不能保障消息只被消费一次)。

    在海量的订单产生的业务高峰期,如何避免消息的重复消费问题呢?
    消费端实现幂等性,就意味着我们的消息永远不会消费多次,即使收到了多条一样的消息。

    业内主要的幂等性实现方案:

    1. 唯一ID+指纹码 机制,利用数据库主键去重

    生成了唯一ID还不够(一般是用户ID),非得加上指纹码的原因在于,为了应对用户在一瞬间的频繁操作,这个指纹码可能是我们的一些规则或者时间戳加别的服务给到的唯一信息码,它并不一定是我们系统生成的,基本都是由我们的业务规则拼接而来,但是一定要保证唯一性。
    然后就利用查询语句进行判断这个id+指纹码是否存在数据库中,比如使用select count(1) from t_order where id= 唯一ID+指纹码。如果count(1)结果是0,说明还没有被消费过;否则已经被消费过了。

    这种方式的好处是:容易实现。
    坏处是:高并发下有数据库写入的性能瓶颈
    解决方案是为了应对数据库写入的性能瓶颈,可以跟进ID进行分库分表的算法路由。

    1. 利用Redis原子性实现

    Redis实现幂等性需要考虑以下问题:
    第一:是否要进行数据落库,如果进行落库的化,如何做到数据库和Redis缓存之间的原子性?
    比如可能出现下面的场景,第一次消息过来的时候,Redis写入成功,在数据库上写入失败了;第二次消息过来的时候Redis显示已经处理过,但是数据库写入不成功。
    Redis和数据库加事务不能解决上面的问题,因为Redis和数据库不是一个数据源,不可能在一个事务里,没有办法做到原子性。

    第二:如果不进行落库,都存储在缓存中,怎么去设置定时同步的策略呢?
    因为消息处理结果不可能一直都放在缓存里,肯定是要把数据持久化的,如何去设置这个定时同步策略呢?
    比如还会有下面的场景出现,在同步之前缓存挂掉了,怎么来做到这个缓存的可靠性保障呢?

    这些都是需要Redis来考虑的关键问题,以后会详细补充。

    展开全文
  • RabbitMQ应用问题消息的可靠性保障(消息补偿机制)和幂等性问题(乐观锁解决方案)思路 一丶可靠性保障 消息补偿 需求是:想百分百确保消息发送成功 方案图示: 二丶消息的幂等性保障 ​ 幂等性指一次和多...

    RabbitMQ应用问题消息的可靠性保障(消息补偿机制)和幂等性问题(乐观锁解决方案)思路

    一丶可靠性保障

    • 消息补偿

      需求是:想百分百确保消息发送成功

    • 方案图示:
      在这里插入图片描述

    二丶消息的幂等性保障

    ​ 幂等性指一次和多次请求某一个资源,对于资源本身应该具有同样的结果。也就是说,其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
    ​ 在MQ中指,消费多条相同的消息,得到与消费该消息一次相同的结果。

    ​ 如图使用数据库的乐观锁 可以防止这一情况:

    用数据库的乐观锁 可以防止这一情况:

    在这里插入图片描述

    展开全文
  • 这种方式也是希望消费端在消费的时候,可以进行批量化的消费,针对于某一个原子业务的操作去处理,但是不保障可靠性,需要进行补偿机制 1)、进行业务数据入库 2)、相同SessionId的消息进行批量处理,存储在...

    九、RabbitMQ扩展

    1、RabbitMQ延迟队列插件

    1)、下载插件

    下载地址:https://www.rabbitmq.com/community-plugins.html

    在这里插入图片描述

    选择相应的版本点击下载

    下载的是.zip的安装包,下载完之后需要手动解压并上传到Linux服务器中

    2)、安装插件

    拷贝插件到Docker:

    [root@localhost plugins]# ls
    rabbitmq_delayed_message_exchange-20171215-3.6.x.ez
    [root@localhost plugins]# docker ps
    CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                    
                                                                        NAMES
    bc514a2c15c1        rabbitmq:3.6.15-management   "docker-entrypoint.s…"   29 hours ago        Up 29 hours         4369/tcp, 5671/tcp, 0.0.0
    .0:5672->5672/tcp, 15671/tcp, 25672/tcp, 0.0.0.0:15672->15672/tcp   rabbitmq
    [root@localhost plugins]# docker cp rabbitmq_delayed_message_exchange-20171215-3.6.x.ez rabbitmq:/plugins
    

    3)、启动插件

    进入docker内部:

    docker exec -it rabbitmq bash
    

    开启插件:

    rabbitmq-plugins enable rabbitmq_delayed_message_exchange
    

    查询安装的所有插件:

    rabbitmq-plugins list
    

    重启RabbitMQ,使插件生效:

    docker restart rabbitmq
    

    在这里插入图片描述

    4)、代码实现

    配置类:

    @Configuration
    public class DelayedConfig {
        public static final String QUEUE_NAME = "delayed.queue";
        public static final String EXCHANGE_NAME = "delayedExchange";
    
        @Bean
        public Queue queue() {
            return new Queue(DelayedConfig.QUEUE_NAME);
        }
    
        //配置默认的交换机
        @Bean
        CustomExchange customExchange() {
            Map<String, Object> args = new HashMap<>();
            args.put("x-delayed-type", "direct");
            //参数二为类型:必须是x-delayed-message
            return new CustomExchange(DelayedConfig.EXCHANGE_NAME, "x-delayed-message", true, false, args);
        }
    
        //绑定队列到交换器
        @Bean
        Binding binding(Queue queue, CustomExchange exchange) {
            return BindingBuilder.bind(queue).to(exchange).with(DelayedConfig.QUEUE_NAME).noargs();
        }
    }
    

    生产端:

    @Component
    public class DelayedSender {
        @Autowired
        private AmqpTemplate rabbitTemplate;
    
        public void send(String msg) {
            SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
            System.out.println("发送时间:" + sf.format(new Date()));
            rabbitTemplate.convertAndSend(DelayedConfig.EXCHANGE_NAME, DelayedConfig.QUEUE_NAME, msg, new MessagePostProcessor() {
                @Override
                public Message postProcessMessage(Message message) throws AmqpException {
                    message.getMessageProperties().setHeader("x-delay", 3000);
                    return message;
                }
            });
        }
    }
    

    消费端:

    @Component
    @RabbitListener(queues = DelayedConfig.QUEUE_NAME)
    public class DelayedReceiver {
        @RabbitHandler
        public void process(String msg) {
            SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
            System.out.println("接收时间:" + sdf.format(new Date()));
            System.out.println("消息内容:" + msg);
        }
    }
    

    测试类:

    @RunWith(SpringRunner.class)
    @SpringBootTest
    public class SpringbootRabbitmqDelayedMessageApplicationTests {
    
        @Autowired
        private DelayedSender sender;
    
        @Test
        public void send() throws InterruptedException {
            sender.send("first delayed-message");
            Thread.sleep(5 * 1000); //等待接收程序执行之后,再退出测试
        }
    
    }
    

    2、消息如何保障100%的投递成功?

    1)、什么是生产端的可靠性投递?

    • 保障消息的成功发出
    • 保障MQ节点的成功接收
    • 发送端收到MQ节点确认应答
    • 完善的消息进行补偿机制

    2)、生产端——可靠性投递

    方案一:消息持久化到数据库,对消息状态进行打标

    在这里插入图片描述
    1)、进行业务数据和消息记录的入库,消息的状态为未发送

    2)、发送消息

    3)、broker confirm,生产端的Confirm Listener负责监听

    4)、收到broker confirm后,更新数据库中消息记录的状态为已发送

    5)、采用分布式定时任务抓取消息记录的数据

    6)、如果消息的状态是未发送,重新发送消息

    7)、如果重试发送的次数超过临界值,将消息状态更新为投递失败,通过补偿系统查询最终失败的消息

    缺陷:在高并发场景下,对消息进行记录会有频繁的数据库持久化操作,数据库的压力过大

    方案二:消息的延迟投递,做二次确认,回调检查

    在这里插入图片描述

    1)、进行业务数据入库,之后发送第一条消息

    2)、发送第二条消息,延迟消息投递检查

    3)、消费端监听指定队列收到第一条消息进行处理

    4)、消费端处理完,发送第一条消息处理完的confirm消息

    5)、Callback服务监听指定队列收到confirm的消息,将消息的记录入库

    6)、Callback服务监听指定队列收到延迟消息投递检查,检查数据库中第一条消息是否已经处理完成,如果第一条消息处理完的confirm消息没有收到,Callback服务向上游服务发送RPC请求,让上游服务重新发送消息

    3、如何保证消费端幂等性,避免消息的重复消费问题?

    方案一:唯一ID+指纹码机制,利用数据库主键去重

    SELECT COUNT(1) FROM T_ORDER WHERE ID=唯一ID+指纹码
    

    优点:实现简单

    缺陷:高并发下有数据库写入的性能瓶颈

    解决方案:根据ID进行分库分表进行算法路由

    在这里插入图片描述

    本地ID生成服务为统一ID生成服务的兜底策略

    方案二:利用Redis的原子性实现

    4、批量消息发送

    批量消息是指我们把消息放到一个集合里统一进行提交,这种方案设计思路是期望消息在一个会话里,比如投掷到threadlocal里的集合,然后拥有相同会话ID,并且带有这次提交消息的SIZE等相关属性,最重要的一点是要把这一批消息进行合并。对于Channel而言,就是发送一次消息。这种方式也是希望消费端在消费的时候,可以进行批量化的消费,针对于某一个原子业务的操作去处理,但是不保障可靠性,需要进行补偿机制

    在这里插入图片描述

    1)、进行业务数据入库

    2)、相同SessionId的消息进行批量处理,存储在ThreadLocal中,在ThreadLocal中MessageHoder负责装消息,消息记录的入库,只记录SessionId

    其他操作同确认模式

    5、顺序消息

    类似于批量消息的实现机制

    需要保障以下几点:

    • 发送的顺序消息,必须保障消息投递到同一个队列,且这个消费者只能有一个(独占模式)
    • 需要统一提交(可能是合并成一个大消息,也可能是拆分为多个消息),并且所有消息的会话ID一致
    • 添加消息属性:顺序标记的序号、和本次顺序消息的SIZE属性,进行落库操作
    • 并行进行发送给自身的延迟消息(带上关键属性:会话ID、SIZE)进行后续处理消费(使用延迟消息保证这一批消息都接收完毕)
    • 当收到延迟消息后,根据会话ID、SIZE抽取数据库数据进行处理
    • 定时轮询补偿机制,对于异常情况

    在这里插入图片描述

    生产端:

    1)、进行业务数据入库

    2)、相同SessionId的消息组成一批带有顺序的消息(不做批量处理,消息是多条的),可以做消息入库保证消息的可靠性投递

    其他操作同确认模式

    消费端:

    1)、进行消息记录的入库

    2)、发送给自身的延迟消息只包含会话ID、SIZE

    3)、收到延迟投递的消息,从数据库中根据会话ID、SIZE查找到对应的消息

    4)、执行实际的业务逻辑处理

    5)、定时任务进行补偿

    展开全文
  • 研究了由源节点、目的节点和多个中继节点组成的认知解码转发(DF)中继网络中物理层安全与可靠性折中方案。该方案保障最大安全主链路信道容量为目标,提出了存在窃听攻击情况下的最佳中继选择方案。以传统直接传输...
  • 将在研究如何应用异步式逻辑保障片上网络互连数据传输的可靠性和服务质量,提出了一个异步式片上网络的架构。通过实验证明,异步式逻辑将极大提高集成电路在应对电源不稳定性、导线间串扰、电磁干扰(EMI)、时钟偏斜和...
  • 保障电池系统的可靠运行,对电池监测产品自身的可靠性进行研究。鉴于测量原理及其工作环境的特殊性,通过对实际产品的研制、认证、应用过程进行分析与改进,详细描述了电池监测产品采样前端的过压、共模干扰、串模...
  • 生产端可靠性投递常见解决方案 消息落库,对消息状态进行打标; &amp;amp;amp;nbsp;&amp;amp;amp;nbsp;&amp;amp;amp;nbsp;&amp;amp;amp;nbsp; &amp;amp;amp;nbsp; 将消息存入数据库,记录...

    消息如何保证100%的投递成功?

    什么是生产端的可靠性投递?

    • 保障消息的成功发出;
    • 保障MQ节点的成功接收;
    • 发送端收到MQ节点(Broker)确认应答;
    • 完善消息补偿机制;

    生产端可靠性投递常见解决方案

    • 消息落库,对消息状态进行打标

           将消息存入数据库,记录消息的状态。可以通过轮询不断获取消息的状态,从而保证消息的成功投递。如下图示所示,这样做有一个很严重的问题就是要多次操作数据库,对于一些高并发、对性能要求较高的业务,这种方式是不太合适的。因为频繁操作数据库会带来严重的性能问题。

    在这里插入图片描述

    • 消息的延迟投递,做二次确认,回调检查

    生产端会发送两次消息:
          第一次:生产端首先会将业务数据存入DB,之后会向MQ发送一个消息,消费端收到消息后发送确认消息(这里的确认消息不是指ack,而是重新编辑发送一条新消息),回调服务监听到确认消息后将消息存入DB;
           第二次:在第一条消息发送出去后一段时间,生产端会再发送一条check消息,回调服务监听到check消息后会检查第一条消息的执行情况,如果消息未能按照预期结果执行的话,回调服务会给生产端发送一条指令让生产端重新发送消息;
           如下图所示,这种方法可以有效的避免对数据库的频繁操作,从而提高性能;同时业务DB和消息DB之间解耦;

    在这里插入图片描述

    消费端幂等性保障:

    唯一ID+指纹码机制,利用数据库主键去重
    • 好处:实现简单;
    • 坏处:高并发下有数据库写入的性能瓶颈;
    • 解决方案:利用ID进行分库分表进行算法路由;
    展开全文
  • 产品可靠性设计方法,从表面上看都是技术问题,但实质上包含技术和管理两个方面,没有技术不行,有了技术,如何把技术贯彻到位也会有好多细节该注意。所以本文的可靠性提升方法中也包含进去一些设计管理方法的内容...
  • MQ 消息的可靠性投递

    2020-05-25 15:10:19
    生产端-消息可靠性投递方案1、说明2、消息落库方案3、延迟投递方案 1、说明   所谓消息可靠性投递,就是解决 “如何保障消息 100%的投递成功?” 的问题。   什么是生产端的可靠性投递? 保障消息的成功...
  • 可靠性、高通用性、高扩展性、大容量.云存储以传统数据中心无法比拟的优势特性.正在成为企业实现提高效率、降低成本的重要选择。HDFS是当前应用最广泛的云存储技术之一.本文详细分析HDFS云存储技术的可靠性
  • 论软件的可靠性设计

    2020-12-29 10:19:42
    论软件的可靠性设计 摘要 2019年11月,我所在的软件公司承接了某保险集团下健康险服务实施管理系统的开发工作,本人有幸参与该项目,并担任系统架构师职务,主要负责软件架构设计和可靠性设计的工作。该项目是...
  • 微服务可靠性设计

    千次阅读 2017-04-18 10:51:26
    转载说明:这篇文章针对微服务的可靠性设计讲的比较全面,我只摘出了其中几个关键点转载,原文参考链接。在故障隔离,容错,降级,熔断机制,流量控制几个方面详细讲解了微服务的可靠性,不错的参考。背景微服务化...
  • 一.什么是生产端可靠性投递;
  • RabbitMQ高级特性-消息可靠性投递

    千次阅读 2018-12-26 06:43:04
    可靠性投递的解决方案 消息落库, 对消息状态进行标记 将消息落入数据库中, 对消息状态进行标记, 消息状态发生变更时, 更新标记信息 对失败消息进行轮询重发, 设置轮询次数 消息入库 消息...
  • 可靠性测试竟如此容易

    千次阅读 2019-09-06 14:06:52
    分布式系统具有廉价高效的特点,利用性能相对一般的PC横向扩展,提升服务器性能,通过软件来保障系统的高可靠性。 由于分布式系统存在API接口通信、微服务架构、节点规模大等特点,增加了系统的复杂性和出错的概率...
  • RabbitMQ消息中间件极速入门与实战 课程 RabbitMQ学习——高级特性 RabbitMQ消息中间件技术精讲(三)—— 深入...什么是生产端的可靠性投递 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点(Br...
  • 前言 本章主要为大家讲解RabbitMQ的高级特性和实际场景应用,包括 消息如何保障 100% 的投递成功 ?...1.1 什么是生产端的可靠性投递? 生产端的可靠性投递 保障消息的成功发出 保障MQ节点...
  • 无线网络中面向延迟敏感业务的统计性安全保障方案,杜清河,李婉瑜,在无线网络中,传统的物理层安全技术旨在同时保证绝对的安全性和可靠性。然而对于延迟敏感型业务来说,其数据具有时效性,往往并
  • 可靠性设计原则1000条

    千次阅读 2011-11-23 22:37:47
    A1 在确定设备整体方案时,除了考虑技术性、经济性、体积、重量、耗电等外,可靠性是首先要考虑的重要因素。在满足体积、重量及耗电等于数条件下,必须确立以可靠性、技术先进性及经济性为准则的最佳构成整体方案。 ...
  • 5.4 设备可靠性设计 7 5.5 备份恢复系统 7 6、 系统应用安全 7 6.1 身份认证系统 7 6.2 用户权限管理 7 6.3 信息访问控制 8 6.4 系统日志与审计 8 6.5 数据完整性 8 7、 安全管理体系 8 8、 其他 9
  • Flume 是怎么保障可靠性的?

    千次阅读 热门讨论 2021-06-26 18:57:14
    通过唯一一个 Sink 作为接收器来接收后续需要的数据,有时候会出现当前 Sink 故障或者数据收集请求量较大的情况,这时候单一的 Sink 配置可能就无法保证 Flume 开发的可靠性。 为此, Flume 提供了 Flume Sink ...
  • 4.8 可靠性指标

    千次阅读 2018-09-30 10:23:20
    可靠性(availability),或者说可用性,是描述系统可以提供服务能力的重要指标。高可靠的分布式系统往往需要各种复杂的机制来进行保障。通常情况下,服务的可用性可以用服务承诺(Service Level Agreement,SLA SLA...
  • 什么是可靠性投递? 方案方案二 等幂性 什么是等幂性 什么是可靠性投递? 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点确认应答 完善消息的补偿机制 方案一 消息入库 发送消息到队列 ...
  • kafka数据可靠性深度解读

    万次阅读 多人点赞 2017-05-02 19:19:32
    3 高可靠性存储分析 Kafka的高可靠性保障来源于其健壮的副本(replication)策略。通过调节其副本相关参数,可以使得Kafka在性能和可靠性之间运转的游刃有余。Kafka从0.8.x版本开始提供partition级别的复制,...
  • RabbitMQ消息可靠性分析

    千次阅读 多人点赞 2018-01-24 10:15:56
    Introduction 有很多人问过我这么一类问题:RabbitMQ如何确保消息可靠?很多时候,笔者的回答都是:说来话长的事情何来长话短说。...可靠性是一个相对的概念,在条件合理的范围内系统所能确保的多少...
  • 网络的可靠性是设计出来的

    千次阅读 2017-08-03 10:42:55
    根据国家标准GB-6583的规定,产品可靠性是指:设备在规定的条件下、在规定的时间内完成规定的功能的能力。对于网络系统的可靠性,除了耐久性外,还有容错性和可维护性方面的内容。 1、耐久性。是指设备运行的无...
  • 代码实例及学习参考...开源、性能优秀、稳定较高 与SpringAMQP完美的整合、API丰富 集群模式丰富、表达式配置、HA模式、镜像队列模式 保证数据不丢失的情况下,做到高可用 AMQP全称:Advanced Message Queuing ...
  • 试论软件的可靠性及其保证

    万次阅读 2013-11-27 11:23:00
    试论软件的可靠性及其保证 来源:ChinaItLab  用软件系统规模越做越大越复杂,其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高,在一些关键的应用领域,如航空、航天等,其可靠性要求尤为重要,在...
  • Kafka如何保证数据可靠性

    千次阅读 2019-11-26 13:55:36
    Kafka的数据可靠性保证 副本数据同步策略 ISR机制 ack应答机制 故障处理:HW、LEO 1. 副本数据同步策略 两种副本数据同步策略(Kafka选择第二种) 方案 优点 缺点 半数以上完成同步,就发送ack 延迟低 ...
  • RabbitMQ高级特性-幂等性保障

    千次阅读 2018-12-26 06:46:39
    消费端-幂等性保障 幂等性 : 多次执行, 结果保持一致 主流的幂等性操作 唯一ID + 指纹码机制, 利用数据库主键去重 好处 : 实现简单 坏处 : 高并发下有数据库写入的性能瓶颈 解决方案 : 根据ID进行...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 56,762
精华内容 22,704
关键字:

产品可靠性保障方案