精华内容
下载资源
问答
  • 当服务超时发生时,研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能,这也什么服务超时相对于服务出错和服务调用量异常更难调查的原因。这篇文章将通过一个真实的线上事故,系统性...

    a1889a9eaf20635320f4ac6e55b0477a.png

    上面这张监控图,对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中,服务超时应该属于监控报警最多的一类问题。

    尤其在微服务架构下,一次请求可能要经过一条很长的链路,跨多个服务调用后才能返回结果。当服务超时发生时,研发同学往往要抽丝剥茧般去分析自身系统的性能以及依赖服务的性能,这也是为什么服务超时相对于服务出错和服务调用量异常更难调查的原因。

    这篇文章将通过一个真实的线上事故,系统性地介绍下:在微服务架构下,该如何正确理解并设置RPC接口的超时时间,让大家在开发服务端接口时有更全局的视野。内容将分成以下4个部分:
    • 从一次RPC接口超时引发的线上事故说起

    • 超时的实现原理是什么?

    • 设置超时时间到底是为了解决什么问题?

    • 应该如何合理的设置超时时间?

    01 从一次线上事故说起

    事故发生在电商APP的首页推荐模块,某天中午突然收到用户反馈:APP首页除了banner图和导航区域,下方的推荐模块变成空白页了(推荐模块占到首页2/3的空间,是根据用户兴趣由算法实时推荐的商品list)。上面的业务场景可以借助下面的调用链来理解

    780286e85ae271154d622daed2060047.png

    • APP端发起一个HTTP请求到业务网关

    • 业务网关RPC调用推荐服务,获取推荐商品list
    • 如果第2步调用失败,则服务降级,改成RPC调用商品排序服务,获取热销商品list进行托底
    • 如果第3步调用失败,则再次降级,直接获取Redis缓存中的热销商品list

    粗看起来,两个依赖服务的降级策略都考虑进去了,理论上就算推荐服务或者商品排序服务全部挂掉,服务端都应该可以返回数据给APP端。但是APP端的推荐模块确实出现空白了,降级策略可能并未生效,下面详细说下定位过程。

    1、问题定位过程

    第1步:APP端通过抓包发现:HTTP请求存在接口超时(超时时间设置的是5秒)。

    第2步:业务网关通过日志发现:调用推荐服务的RPC接口出现了大面积超时(超时时间设置的是3秒),错误信息如下:

    f742205362bcd5fd326ca9f98618601b.png

    第3步:推荐服务通过日志发现:dubbo的线程池耗尽,错误信息如下:

    c9eb6ef02533f1216cbd28a4ea793645.png

    通过以上3步,基本就定位到了问题出现在推荐服务,后来进一步调查得出:是因为推荐服务依赖的redis集群不可用导致了超时,进而导致线程池耗尽。详细原因这里不作展开,跟本文要讨论的主题相关性不大。

    2、降级策略未生效的原因分析

    下面再接着分析下:当推荐服务调用失败时,为什么业务网关的降级策略没有生效呢?理论上来说,不应该降级去调用商品排序服务进行托底吗?

    最终跟踪分析找到了根本原因:APP端调用业务网关的超时时间是5秒,业务网关调用推荐服务的超时时间是3秒,同时还设置了3次超时重试,这样当推荐服务调用失败进行第2次重试时,HTTP请求就已经超时了,因此业务网关的所有降级策略都不会生效。下面是更加直观的示意图:

    51bb401a0ab95ec4ed4d6101750ecf3c.png

    3、解决方案
    • 将业务网关调用推荐服务的超时时间改成了800ms(推荐服务的TP99大约为540ms),超时重试次数改成了2次
    • 将业务网关调用商品排序服务的超时时间改成了600ms(商品排序服务的TP99大约为400ms),超时重试次数也改成了2次

    关于超时时间和重试次数的设置,需要考虑整个调用链中所有依赖服务的耗时、各个服务是否是核心服务等很多因素。这里先不作展开,后文会详细介绍具体方法。

    02 超时的实现原理是什么?

    只有了解了RPC框架的超时实现原理,才能更好地去设置它。不论是dubbo、SpringCloud或者大厂自研的微服务框架(比如京东的JSF),超时的实现原理基本类似。下面以dubbo 2.8.4版本的源码为例来看下具体实现。

    熟悉dubbo的同学都知道,可在两个地方配置超时时间:分别是provider(服务端,服务提供方)和consumer(消费端,服务调用方)。服务端的超时配置是消费端的缺省配置,也就是说只要服务端设置了超时时间,则所有消费端都无需设置,可通过注册中心传递给消费端,这样:一方面简化了配置,另一方面因为服务端更清楚自己的接口性能,所以交给服务端进行设置也算合理

    dubbo支持非常细粒度的超时设置,包括:方法级别、接口级别和全局。如果各个级别同时配置了,优先级为:消费端方法级 > 服务端方法级 > 消费端接口级 > 服务端接口级 > 消费端全局 > 服务端全局。

    通过源码,我们先看下服务端的超时处理逻辑
     1public class TimeoutFilter implements Filter {
    2
    3    public TimeoutFilter() {
    4    }
    5
    6    public Result invoke(...) throws RpcException {
    7        // 执行真正的逻辑调用,并统计耗时
    8        long start = System.currentTimeMillis();
    9        Result result = invoker.invoke(invocation);
    10        long elapsed = System.currentTimeMillis() - start;
    11
    12        // 判断是否超时
    13        if (invoker.getUrl() != null && elapsed > timeout) {
    14            // 打印warn日志
    15            logger.warn("invoke time out...");
    16        }
    17
    18        return result;
    19    }
    20}
    可以看到,服务端即使超时,也只是打印了一个warn日志。因此,服务端的超时设置并不会影响实际的调用过程,就算超时也会执行完整个处理逻辑。再来看下消费端的超时处理逻辑
     1public class FailoverClusterInvoker {
    2
    3    public Result doInvoke(...)  {
    4        ...
    5        // 循环调用设定的重试次数
    6        for (int i = 0; i  7            ...
    8            try {
    9                Result result = invoker.invoke(invocation);
    10                return result;
    11            } catch (RpcException e) {
    12                // 如果是业务异常,终止重试
    13                if (e.isBiz()) {
    14                    throw e;
    15                }
    16
    17                le = e;
    18            } catch (Throwable e) {
    19                le = new RpcException(...);
    20            } finally {
    21                ...
    22            }
    23        }
    24
    25        throw new RpcException("...");
    26    }
    27}

    FailoverCluster是集群容错的缺省模式,当调用失败后会切换成调用其他服务器。再看下doInvoke方法,当调用失败时,会先判断是否是业务异常,如果是则终止重试,否则会一直重试直到达到重试次数。

    继续跟踪invoker的invoke方法,可以看到在请求发出后通过Future的get方法获取结果,源码如下:

     1public Object get(int timeout) {
    2        if (timeout <= 0) {
    3            timeout = 1000;
    4        }
    5
    6        if (!isDone()) {
    7            long start = System.currentTimeMillis();
    8            this.lock.lock();
    9
    10            try {
    11                // 循环判断
    12                while(!isDone()) {
    13                    // 放弃锁,进入等待状态
    14                    done.await((long)timeout, TimeUnit.MILLISECONDS);
    15
    16                    // 判断是否已经返回结果或者已经超时
    17                    long elapsed = System.currentTimeMillis() - start;
    18                    if (isDone() || elapsed > (long)timeout) {
    19                        break;
    20                    }
    21                }
    22            } catch (InterruptedException var8) {
    23                throw new RuntimeException(var8);
    24            } finally {
    25                this.lock.unlock();
    26            }
    27
    28            if (!isDone()) {
    29                // 如果未返回结果,则抛出超时异常
    30                throw new TimeoutException(...);
    31            }
    32        }
    33
    34        return returnFromResponse();
    35    }

    进入方法后开始计时,如果在设定的超时时间内没有获得返回结果,则抛出TimeoutException。因此,消费端的超时逻辑同时受到超时时间和超时次数两个参数的控制,像网络异常、响应超时等都会一直重试,直到达到重试次数

    03 设置超时时间是为了解决什么问题?

    RPC框架的超时重试机制到底是为了解决什么问题呢?微服务架构这个宏观角度来说,它是为了确保服务链路的稳定性,提供了一种框架级的容错能力。微观上如何理解呢?可以从下面几个具体case来看:1、consumer调用provider,如果不设置超时时间,则consumer的响应时间肯定会大于provider的响应时间。当provider性能变差时,consumer的性能也会受到影响,因为它必须无限期地等待provider的返回。假如整个调用链路经过了A、B、C、D多个服务,只要D的性能变差,就会自下而上影响到A、B、C,最终造成整个链路超时甚至瘫痪,因此设置超时时间是非常有必要的。2、假设consumer是核心的商品服务,provider是非核心的评论服务,当评价服务出现性能问题时,商品服务可以接受不返回评价信息,从而保证能继续对外提供服务。这样情况下,就必须设置一个超时时间,当评价服务超过这个阈值时,商品服务不用继续等待。3、provider很有可能是因为某个瞬间的网络抖动或者机器高负载引起的超时,如果超时后直接放弃,某些场景会造成业务损失(比如库存接口超时会导致下单失败)。因此对于这种临时性的服务抖动,如果在超时后重试一下是可以挽救的,所以有必要通过重试机制来解决。但是引入超时重试机制后,并非一切完美了。它同样会带来副作用,这些是开发RPC接口必须要考虑,同时也是最容易忽视的问题:1、重复请求:有可能provider执行完了,但是因为网络抖动consumer认为超时了,这种情况下重试机制就会导致重复请求,从而带来脏数据问题,因此服务端必须考虑接口的幂等性。2、降低consumer的负载能力:如果provider并不是临时性的抖动,而是确实存在性能问题,这样重试多次也是没法成功的,反而会使得consumer的平均响应时间变长。比如正常情况下provider的平均响应时间是1s,consumer将超时时间设置成1.5s,重试次数设置为2次,这样单次请求将耗时3s,consumer的整体负载就会被拉下来,如果consumer是一个高QPS的服务,还有可能引起连锁反应造成雪崩。3、爆炸式的重试风暴:假如一条调用链路过了4个服务,最底层的服务D出现超时,这样上游服务都将发起重试,假设重试次数都设置的3次,那么B将面临正常情况下3倍的负载量,C是9倍,D是27倍,整个服务集群可能因此雪崩。

    6ac6f7919d4a68ae5695067b54614861.png

    04 应该如何合理的设置超时时间?

    理解了RPC框架的超时实现原理和可能引入的副作用后,可以按照下面的方法进行超时设置:

    • 设置调用方的超时时间之前,先了解清楚依赖服务的TP99响应时间是多少(如果依赖服务性能波动大,也可以看TP95),调用方的超时时间可以在此基础上加50%

    • 如果RPC框架支持多粒度的超时设置,则:全局超时时间应该要略大于接口级别最长的耗时时间,每个接口的超时时间应该要略大于方法级别最长的耗时时间,每个方法的超时时间应该要略大于实际的方法执行时间
    • 区分是可重试服务还是不可重试服务,如果接口没实现幂等则不允许设置重试次数。注意:读接口是天然幂等的,写接口则可以使用业务单据ID或者在调用方生成唯一ID传递给服务端,通过此ID进行防重避免引入脏数据
    • 如果RPC框架支持服务端的超时设置,同样基于前面3条规则依次进行设置,这样能避免客户端不设置的情况下配置是合理的,减少隐患
    • 如果从业务角度来看,服务可用性要求不用那么高(比如偏内部的应用系统),则可以不用设置超时重试次数,直接人工重试即可,这样能减少接口实现的复杂度,反而更利于后期维护
    • 重试次数设置越大,服务可用性越高,业务损失也能进一步降低,但是性能隐患也会更大,这个需要综合考虑设置成几次(一般是2次,最多3次)
    • 如果调用方是高QPS服务,则必须考虑服务方超时情况下的降级和熔断策略。(比如超过10%的请求出错,则停止重试机制直接熔断,改成调用其他服务、异步MQ机制、或者使用调用方的缓存数据)

    最后,再简单总结下:

    RPC接口的超时设置看似简单,实际上有很大学问。不仅涉及到很多技术层面的问题(比如接口幂等、服务降级和熔断、性能评估和优化),同时还需要从业务角度评估必要性。知其然知其所以然,希望这些知识能让你在开发RPC接口时,有更全局的视野。

    推荐阅读

    「DUBBO系列」超时机制实现原理

    「DUBBO系列」服务降级实现原理

    「DUBBO系列」并发控制实现原理

    「DUBBO系列」集群容错之Failover

    IT人的职场进阶 

    前亚马逊工程师,现58转转技术总监,持续分享个人的成长经历,希望为你的职场发展带来些新思路,欢迎扫码关注

    6f59110c865e6ab64278a35ce21d996d.png

    JAVA前线 

    互联网技术人思考与分享,欢迎扫码关注

    ebaff92990902dd0a83a601ae1d339c6.png

    展开全文
  • 很多人用HTML模板做一些网页开发,并且需要...针对这个问题很多人都查了半天都查不到什么原因,语法什么都没错。 那么你就应该检查一个是否这个BUTTON在一个FORM中。然后点击FORM其实发送的空值,所以页面刷新了!

    很多人用HTML模板做一些网页开发,并且需要用AJAX来跟后台做交互,但是用JS或者JQUERY设置好监听之后,点击会发现本页面又刷新了。

    针对这个问题很多人都查了半天都查不到什么原因,语法什么都没错。

    那么你就应该检查一个是否这个BUTTON在一个FORM中。然后点击FORM其实是发送的是空值,所以页面刷新了!

    展开全文
  • kafka重复消费问题

    万次阅读 2018-10-22 10:33:14
    今天查看Elasticsearch索引的时候发现有一个索引莫名的多了20w+的数据,顿时心里一阵惊讶,然后赶紧打开订阅服务的日志(消费者),眼前的一幕让我惊呆了,我的消费服务的控制台一直在不断的刷着消费日志(刚开始我...

    开篇提示:kafka重复消费的根本原因就是“数据消费了,但是offset没更新!而我们要探究一般什么情况下会导致offset没更新?

    今天查看Elasticsearch索引的时候发现有一个索引莫名的多了20w+的数据,顿时心里一阵惊讶,然后赶紧打开订阅服务的日志(消费者),眼前的一幕让我惊呆了,我的消费服务的控制台一直在不断的刷着消费日志(刚开始我并没有意识到这是重复消费造成的),我还傻傻的以为是因为今天有人在刷单,所以导致日志狂刷,毕竟之前也遇到过有人用自动交易软件疯狂刷单的,所以当时也没在意;等过了几分钟,又去瞅了一眼控制台仍然在疯狂的刷着日志,妈呀!顿时隐隐感觉不对劲,赶紧看了一眼es索引,我滴天一下子多了几万的数据,突然在想是不是程序出问题了(因为头一天晚上发了一个版本),然后就开始死盯这日志看,发现了一个奇葩的问题:tmd怎么日志打印的数据都是重复的呀!这才恍然大悟,不用想了绝逼是kakfa重复消费了,好吧!能有什么办法了,开始疯狂的寻找解决的办法......

    既然之前没有问题,那就是我昨天发版所导致的,那么我昨天究竟改了什么配置呢?对照了之前的版本比较了一下,发现这个参数enable-auto-commit被改成了true,即自动提交,理论上在数据并发不大,以及数据处理不耗时的情况下设置自动提交是没有什么问题的,但是我的情况恰恰相反,可能突然会并发很大(毕竟交易流水不好说的),所以可能在规定的时间(session.time.out默认30s)内没有消费完,就会可能导致re-blance重平衡,导致一部分offset自动提交失败,然后重平衡后重复消费(这种很常见);或者关闭kafka时,如果在close之前,调用consumer.unsubscribe()则可能有部分offset没提交,下次重启会重复消费

    try {
    consumer.unsubscribe();
    } catch (Exception e) {
    }

    try {
    consumer.close();
    } catch (Exception e) {
    }

     

    所以一般情况下我们设置offset自动提交为false!

    解决方法:

    1.设置

    spring.kafka.consumer.enable-auto-commit=false
    spring.kafka.consumer.auto-offset-reset=latest 

    2.就是修改offset为最新的偏移量呗!我们都知道offset是存在zookeeper中的,所以我就不赘述了!

    我的解决方法:

    我并没有去修改offset偏移量,毕竟生产环境还是不直接改这个了;

    我重新指定了一个消费组(group.id=order_consumer_group),然后指定auto-offset-reset=latest这样我就只需要重启我的服务了,而不需要动kafka和zookeeper了!

     

    #consumer
    spring.kafka.consumer.group-id=order_consumer_group
    spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
    spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer
    spring.kafka.consumer.enable-auto-commit=false
    spring.kafka.consumer.auto-offset-reset=latest

    注:如果你想要消费者从头开始消费某个topic的全量数据,可以重新指定一个全新的group.id=new_group,然后指定auto-offset-reset=earliest即可

     

    补充:

    在kafka0.9.0版本的时候,开始启用了新的consumer config,这个新的consumer config采用bootstrap.servers替代之前版本的zookeeper.connect,主要是要渐渐弱化zk的依赖,把zk依赖隐藏到broker背后。
    group coordinator
    使用bootstrap.servers替代之前版本的zookeeper.connect,相关的有如下两个改动:

    1.在 Server 端增加了 GroupCoordinator 这个角色
    2.将 topic 的 offset 信息由之前存储在 zookeeper(/consumers/<group.id>/offsets/<topic>/<partitionId>,zk写操作性能不高) 上改为存储到一个特殊的 topic 中(__consumer_offsets)

    从0.8.2版本开始Kafka开始支持将consumer的位移信息保存在Kafka内部的topic中(从0.9.0版本开始默认将offset存储到系统topic中)
    Coordinator一般指的是运行在broker上的group Coordinator,用于管理Consumer Group中各个成员,每个KafkaServer都有一个GroupCoordinator实例,管理多个消费者组,主要用于offset位移管理和Consumer Rebalance。
    rebalance时机
    在如下条件下,partition要在consumer中重新分配:

    条件1:有新的consumer加入
    条件2:旧的consumer挂了
    条件3:coordinator挂了,集群选举出新的coordinator
    条件4:topic的partition新加
    条件5:consumer调用unsubscrible(),取消topic的订阅

    __consumer_offsets
    Consumer通过发送OffsetCommitRequest请求到指定broker(偏移量管理者)提交偏移量。这个请求中包含一系列分区以及在这些分区中的消费位置(偏移量)。偏移量管理者会追加键值(key-value)形式的消息到一个指定的topic(__consumer_offsets)。key是由consumerGroup-topic-partition组成的,而value是偏移量。

     

    参考:https://segmentfault.com/a/1190000011441747

    展开全文
  • <div><p>运行第三章3.3.4节开始训练的命令后,开始一直卡在INFO:tensorflow:global_step/sec=...请问是什么原因?</p><p>该提问来源于开源项目:hzy46/Deep-Learning-21-Examples</p></div>
  • 问题描述:编译流程图时,逻辑复杂,嵌套很深,很多函数都有成功失败返回值,...这两个问题困扰了我编码很多年了,一直没搞明白为什么会这样。   日志解决办法:出现上述问题,实际上因为我犯了一个致命的错误,

    问题描述:编译流程图时,逻辑复杂,嵌套很深,很多函数都有成功失败返回值,造成每层函数都出现大量的成功失败判断,并且不知道打印日志是该在函数外,还是在函数内打印,感觉每次发现失败的时候都应该打印日志,但是又觉得有打印有重复,同时,打印的日志很容易将做什么和失败原因割裂开。这两个问题困扰了我编码很多年了,一直没搞明白为什么会这样。

     

    日志解决办法:出现上述问题,实际上是因为我犯了一个致命的错误,就是对发现错误进行了重复处理。因为打印日志实际上是对错误的处理,而返回失败也是对错误的处理,只要避免发生错误重复处理,我们离找到解决办法就只有一步之遥了。

    直观现象就是,只要我们的函数有返回错误,则不应该打印日志(即函数如果正确地对错误进行了处理,则函数一定是没返回值的)。打印日志发生的地方一定是我们能终结错误的地方。按照这个规则,我们的错误应该一层一层的往外返回(不往外返回就会触发错误重复处理),一般情况下,只有返回到系统边界的时候才能正确处理错误,比如界面层这个边界,把错误信息告诉用户(比如打印日志或弹出消息框等),错误才能正常终止。这时,也容易确定用户正在做什么,将做什么和异常中的失败原因结合起来很容易就能打印出友好的日志。有时触发一个事件可能通过工具栏按钮或右键菜单,如果不搞一个控制层直接在界面中处理的话,可能会出现重复代码,所以,有时错误返回到控制层就结束了,界面层仅仅是简单地调用一下控制层而已(设计分层问题,和我们要解决的问题关系不大)。

    当然,错误不一定就要返回到边界才能终止,更通用的说法是错误返回到能处理它的地方终止就行,比如打印调试日志的函数出现错误了,只需要把这个错误捕获并忽略掉就行了,因为没有更好的其他方式处理这种错误,就算一直返回出去也没法处理,并且这种错误也无关紧要,所以一般打印调试日志的函数都是没有返回值的。

     

    判断解决办法:这涉及到对错误进行处理的两种方式,老式的返回值方式(C语言风格)和新式的抛异常方式(Java风格)。

    返回值方式有三大缺点,一是到处都得进行显式判断,并把返回值往外层层传递。二是错误信息不太容易往外传,Win32的最后错误代码方式相当于只能传递错误类型,并不能灵活传递具体的错误信息,不友好。三是返回值用来传递成功失败信息了,正确想返回的东西只能放在参数中,造成函数使用起来复杂不直观。

    个人觉得,抛异常方式还是比返回值方式先进一些,虽然道理差不多,抛异常方式无非是将返回值放到异常对象中往外传递而已,因为是对象,故通过对象类型就确定了错误类型,而对象中的成员又可以容易携带其他信息,比如具体的错误消息等。

    而抛异常方式正好可以解决返回值方式的问题,首先异常会默认往外层传递,不需要程序员显式转手传递,程序员只需要按期望的正常流程处理,发现不正常的时候抛异常就行。其次,错误信息很容易往外传递。其三,函数的返回值可以真正用来返回正常情况下的返回值,使用起来简单直观。最后,抛异常方式可以强制调用者处理错误。

    这样看来,别人说尽量用抛异常的方式处理错误还是有道理的。

    现在,终于明白了为什么Win32函数基本上都有返回值,因为大部分情况下函数都需要用返回值告诉调用者函数是成功还是失败了。而Java中,函数是成功还是失败一般都通过抛异常来告诉调用者,故相当的函数都没有返回值(不会返回布尔值)。

    一般从C/C++系转Java的开发者,思想上很难接受抛异常的错误处理方式,故写出来的java代码仍然习惯于用返回值来告诉调用者结果,这种观念得改,学会适应,至少得入乡随俗

    不过采用返回值还是抛异常还是相当有争议的(比如性能),不能说抛异常就没缺点,大家是仁者见仁智者见智。

    展开全文
  • 他发现一个比较奇怪的问题,两个双胞胎只有身份证号码的最后一位不一样,当使用条件格式对重复值进行突出显示颜色的时候,这两个身份证号被判定为重复(如下图,鲁班与刘备的身份证号码,只有最后一位不一样),excel错...
  • 中,如果不关心a[]的哪一个分量会被写入,这段代码就没有问题,i也的确会增加1,对吗? 3.11 人们总是说i=i++的行为未定义的。可我刚刚在一个ANSI编译器上尝试过,其结果正如我所期望的。 3.12 我不想学习那些...
  • controller重复调用

    2021-01-12 16:04:38
    什么可能的原因吗?控制器async的异步函数,函数内调用了一个异步请求,并将结果assign到模板中,display模板,但是一直调用两次。 模板用的nunjucks,只要模板内容比较多,就会...
  • 《你必须知道的495C语言问题

    热门讨论 2010-03-20 16:41:18
    中,如果不关心a[]的哪一个分量会被写入,这段代码就没有问题,i也的确会增加1,对吗? 38  3.11 人们总是说i=i++的行为未定义的。可我刚刚在一个ANSI编译器上尝试过,其结果正如我所期望的。 38  3.12 我不...
  • 中,如果不关心a[]的哪一个分量会被写入,这段代码就没有问题,i也的确会增加1,对吗? 38  3.11 人们总是说i=i++的行为未定义的。可我刚刚在一个ANSI编译器上尝试过,其结果正如我所期望的。 38  3.12 我不...
  • 什么叫完美世界,比如一个方法执行时间永远0、网速无限快、并发没有冲突、用户可以没有情绪地在界面上重复20次输入相同的东西等,其实这说好听了完美世界,用正常人的话说叫心智不健全的世界观。很多人写代码,...
  • 按理说跑着一个程序,不该另外出现一个一模一样的进程重复一起运行和发送啊,但数据确实是重复发送出去了,服务器那边也收到了两条一模一样的数据,因为发送频率同一时刻,所以那边校验都没起上作用,有用的话第...
  • 是一个随机生成的不重复的数字串 "number": , // issue number , 根据创建 issue 的顺序从1开始累加 "title": , // issue 的标题 "labels": [], // issue 的所有 label,...
  • 今天遇到一个很蛋疼的问题,就是题目所说的症状,一直不知道什么原因。 话说项目中的listview有的数据有网络图片,有的没有,再加载了图片之后滑动向下,然后再返回前面数据的时候惊奇的发现本来没有图的数据列竟然有...
  • 一个、两个、三个都没问题。一切由你掌控。神奇的文字描边image文字描边从未如此简单!高效的状态图image不同于原生的Drawable,SuperTextView对于Drawable提供了更多精细化的控制操作。你能够轻松的指定Drawable...
  • 一个简历应该包括哪些要点; 准备简历的时候一定不能犯的错误有哪些; 需要准备一封随机应变的简历; 简历的学问。 实录提要: 如果一直做的重复工作,量比较突出,技能算不上突出,简历该怎么写? 应届毕业生没有...
  • 一个人精力太有限了,uPattern是一个模式实现单元,没有足够的时间也没有那么多精力去实现所有的模式,于是在这份源代码里,您发现您可以使用一个用户组来登录,本来这不允许的啊,如果您想找到原因,原来...
  • 关于VideoView播放视频问题

    千次阅读 2017-04-17 17:23:43
    最近项目需要重复循环播放一个列表中的多个视频,又搞得头都大了,现在勉强有点眉目了,和大家分享下。 1.问题:播放视频的时候路径正确的但是一直在屏幕“显示无法播放此视频”? 回答:这里大概率因为视频...
  • 我们需要什么样的电脑环境

    千次阅读 2012-06-15 16:58:41
    我也一直在考虑一个问题我们到底需要一个什么样的环境?不需要多华丽,关键实用,方便。一次次的重复而又繁琐的配置让我有些不耐烦。一直无法割舍archliunx的根本原因不再有他性能多好、多么轻量级。关键
  • Constant expression required问题解决

    千次阅读 2020-02-20 10:08:51
    系统一直提示Constant expression required,这什么呢? 原因是这样的:switch…case语句的case后面的值必须为常量,因为switch在编译的时候需要确保case里面的值必须不能相同。直接写getXXX这样的方法可能...
  • 发现了一个命令行突变的问题,其实早在之前使用linux操作的时候也曾碰到过,但是一直都没有理会,而且咨询过相关专业的linux开发人员,也说没什么问题,所以就一直没有去寻找原因。这次因为部署Oracle环境,在linux...
  •  今天在安装部署linux下的Oracle环境时,发现了一个命令行突变的问题,其实早在之前使用linux操作的时候也曾碰到过,但是一直都 没有理会,而且咨询过相关专业的linux开发人员,也说没什么问题,所以就一直...
  • 从刚接触前端开发起,跨域这词就一直以很高的频率在身边重复出现,一直到现在,已经调试过N跨域相关的问题了,16年时也整理过篇相关文章,但是感觉还是差了点什么,于是现在重新梳理了一下。 个人见识有限,...
  • dubbo端口被占用

    千次阅读 2018-08-01 10:57:26
    启动项目的时候一直提示端口被占用,换什么端口就提示什么端口被占用,结果tomcat在重复启动(原因未知),通过重新配置一个纯净版本的tomcat,问题得到了解决...
  • 你有一个观点,这套理论很难被开发者应用起来,其实不然,你提出的这种方式确实复杂了一些(个人感觉有点回到了写Java的时代),但让开发大规模用起来也不难,就是用...

空空如也

空空如也

1 2 3 4 5
收藏数 81
精华内容 32
关键字:

一直重复一个问题是什么原因